Hi again,
my fix is of course nonsense.
1) Like seems to show very different results on different databases for fixed length char fields
2) As Alan already said, the above-mentioned method would also be used for updates and inserts, and the characters % and _ are valid characters to save in a fixed var field.
So what I'll try is to treat the field as if it was a varchar. Let's see how far I get with this.
BUT :
====
The handling of LIKE subclauses is somewhat broken in GLORP because of the padding. Reasons:
1) It cuts off characters that might be important for searching. Example: I have a char(6) column and want to search for '%test_%'. The database will only be asked for '%test_' because the characters after index 6 are cut off, and therefor would not answer rows containing 'test_1' --> The results of GLORPs like query is WRONG!
2) SQL allows for functioins in a Like clause like ESCAPE. These would be cut off. In the best case, they'd be cut off completely, so that the DB can at least answer something, but cutting off cut also lead to syntax errors. This is admittedly not likely to be a very common problem.
So I guess the handling of LIKE should not use the "normal" way of converting the Function argument and should not pad at all. This is of course only possible if GLORP introduces some way of using different conversion routines for INSERT/UPDATE and SELECT in conjunction with LIKE...
But then, maybe this is not worth the effort...
Joachim