Hi,
Thanks for your answers. I have changed my GeoServer of Version 1.5.4 on
Version 1.6.5 and now the filter works.
I have tryed the PropertyIsLike filter and i think, that it is slower than
the PropertyIsEqualTo filter. both supply however the same result.
Greeting Thomas
-----Ursprüngliche Nachricht-----
Von: Rahkonen Jukka [mailto:Jukka.Rahkonen@anonymised.com]
Gesendet: Montag, 13. Oktober 2008 19:22
An: Andrea Aime
Cc: Janßen, Thomas; geoserver-users@lists.sourceforge.net
Betreff: Re: [Geoserver-users] SLD PropertyIsEqualTo
Andrea Aime wrote:
Rahkonen Jukka ha scritto:
Hi,
I know very little about SLD, but I wonder if it has something in
common with WFS filters? If it does, then isn't PropertyIsLike filter
more suitable for string comparisons?
It may be, but the filter as written by Thomas is correct.
In the old GeoServer there was no indication, context, for the sql
encoding, and this resulted into troubles.
Basically, given att = 00123 the encoder would say, ok, I have the
'00123' coming from the xml, but what exactly is this?
Let's try to convert to a date... fails, so no, not a date.
Ok, let's try with a number then... oh, yeah, this really looks like a
number, then the sql will be 'att = 123'.
Nowadays we try to leverage the comparison context, so the encoder
knows that 00123 is compared with a string attribute and tries to
encode it as a string... at least that's the theory, if Thomas is
reproducing this issue on a recent GeoServer then the bug has raised
his head again in some way.
I know this for sure 
We have leading zeros in all our major query
attributes, and with old Geoserver 1.5.0 production system we had to create
a separate query column into all our database tables so that they had a
letter on the first place. With 1.6 and now 1.7 series leading zeros have
not been any problem. I know that with Oracle backend using PropertyIsLike
is leading to query "where id='000111222'" which is correct. I am not sure
if using PropertyIsEqualTo is giving "where id=000111222" which will work
but is slow, or to correct one with quetes. Geoserver 1.5.0 was sending
"where id=111222" and that failed totally, naturally.
-Jukka-
-Jukka-