[Update, 2023-10-12: This bug has long been fixed, somewhere around VAST 9.0. I just didn’t think of this article. Fixed length Char fields work fine in VAST with DB2 and Glorp. no need to read this old article, unless you are interested in the history of nasty bugs or in differences between the JET Database Engine /MS Access and DB2 😉 ]
[Update, 2012-04-26: Instantiations is currently working on a fix for this problem. I’ve been mailing back and forth with the responsible developer about this and other problems that I’ve had with GLORP on VAST, so I hope we’ll soon see a newer version of GLORP ported over to VA ST with quite a few bugs fixed. This bug is existent in VA ST 8.5.1 but may be solved in later versions when you read this some tim win the future.]
Today is my trouble-seeker day. One of the things I am currently trying to do is make a GLORP application transferable between MS Access and DB2. Glorp does a good job in hiding a lot of DB complexity from the developer, but there are edges where it needs help. Or, put differently, you can be very sloppy when working with Access.
Problems I could solve quite easily were:
* You need a #numberToNumber converter for ScaledDecimals in DB2, or you get an SQLCode 413
* You have to truncate your Strings before inserting into Varchar-fields, or you get an SQLCode (forgot which one) from DB2 where Access simply cuts off the rest
* The Boolean converter in VAST’s GLORP version is broken and a fix I made for AccessPlatfrom a few months ago had to be pushed up to Database Platform.
But now I have a problem that I cannot solve without getting deeper into trouble or change my mapping logic. This sounds probably very strange and easy to solve, but it isn’t.
One of my class hierarchies uses a CHAR(1) field as an indicator for the concrete subclass a row maps to. And there’s nothing really wrong with what GLORP does. It has a Dictionary with a few Strings of Size 1 with the respective discriminators. The problem lies in the fact that someone at IBM tried to be extra clever many moons ago and implemented something in AbtIbmCliFixedCharField that will return the database field as a Character instance if the size of the String is 1.
This is of course easy to fix, but I guess I would break the database code of 65% of all VAST projects out there if I changed AbtIbmCliFixedCharField. On the other hand, changing Glorp at this place would only be correct if restricted to DB2, but there is no access to the DatabaseAccessor at the particular place in GLORP. So I see no easy way to fix this. The only thing you can do for now is:
Don’t use GLORP Type Resolvers with CHAR(1) fields in DB2 on VA Smalltalk
[Update] Just to confirm that there is no issue with CHAR(2) at all. All works very well with longer fields. So this is really just an issue of Single Characters and the behavior of AbtIbmCliFixedCharField [/Update]
Joachims Small World 