8.5.2 enhancement to optionally answer database CHARACTER(1) columns as a String instead of Character

55 views
Skip to first unread message

Wayne Johnston

unread,
Sep 20, 2012, 4:24:12 PM9/20/12
to va-sma...@googlegroups.com
I didn't know Instantiations was making that change, but I was glad to see that.

However, is there a reason this was implemented just for DB2?  (#keepSingleCharStringsAsString: etc. is only in AbtIbmCliDatabaseConnection, not the superclass AbtOdbcDatabaseConnection, so it won't work for SQL Server, for instance).

jtu...@objektfabrik.de

unread,
Sep 20, 2012, 4:48:56 PM9/20/12
to va-sma...@googlegroups.com
Hi Wayne,

here's why it was added: http://joachimtuchel.wordpress.com/2012/03/05/dont-use-glorp-type-resolvers-with-char1-fields-in-db2-on-va-smalltalk/

There you can also see why Instantiations added a setting instead of changing the default behavior. If I remember correctly, the special behavior was only present in DB2 nut not in any other DB interface. Since I found the bug through the fact that all was fine on Access but broken on DB2, I'd dare to say that SQL Server and Access never had the problem... Do you know any better or are you just asking because the docs say "we changed this for DB2"?

Joachim


Am Donnerstag, 20. September 2012 22:24:12 UTC+2 schrieb Wayne Johnston:

Wayne Johnston

unread,
Sep 21, 2012, 9:32:42 AM9/21/12
to va-sma...@googlegroups.com
You are right.  I forgot that the irrationality was limited to DB2, so there was nothing to fix anywhere else.  And note to self - it was indeed only CHARACTER(1) columns and not VARCHAR(1) columns.  

The slight problem is our general code that works with DB2 or SQL Server (meaning ODBC).  When we connect, we will send #keepSingleCharStringsAsString: (true) to the connection.  But that will blow up if it happens to not be a DB2 connection.  So we need a #isKindOf: or #canUnderstand: there.  What might be best is us implementing a do-nothing #keepSingleCharStringsAsString: in AbtOdbcDatabaseConnection.  Instantiations could do that too, but then someone might ask them to implement the irrationality if false was the parameter...  ;-)

jtu...@objektfabrik.de

unread,
Sep 21, 2012, 9:59:35 AM9/21/12
to va-sma...@googlegroups.com
Hi Wayne,

you somewhere create the DB2 connection, right? I mean, you create an instance that you use to connect to. That's the place where you may find a practical place for such a difference rather than the place where you connect to "some generic DB connection". The final resort might be to use some DB connection factory object that handles this difference.

To be honest, I am not sure why you see a problem at all: the way it worked up to now has been as it is for almost 20 years now....

I remember discussing this change with Bob and we also talked about some setting that could be made in the ini file or at least through some class method. I have not yet had the time to download or install 8.5.2, so I can't check if it was implemented, but I somewhat seem to remember I liked the idea and somehow thought it's going to be there. Maybe it is, can you check for senders of the setter?

Joachim

Wayne Johnston

unread,
Sep 21, 2012, 10:16:39 AM9/21/12
to va-sma...@googlegroups.com
No, I don't see any callers other than my own.

Our code calls various methods but would expand in-line to be like this:

| connection connectionSpec dbManagerClass |
dbManagerClass := self iniSettingsSayDB2
ifTrue: [AbtIbmCliDatabaseManager]
ifFalse: [AbtOdbcDatabaseManager].
connectionSpec := AbtDatabaseConnectionSpec
forDbmClass: dbManagerClass
dataSourceName: self dataSourceName.
connection := connectionSpec
connectUsingAlias: self connectionName
logonSpec: self logonSpec
ifError: errorBlock.
connection isAbtError ifTrue: [^conn].
connection keepSingleCharStringsAsString: true.


So one way to fix the slight problem I'm reporting is to add a "self iniSettingsSayDB2" before the last line.

Bob Brodd

unread,
Sep 21, 2012, 4:45:16 PM9/21/12
to va-sma...@googlegroups.com
Hi Wayne,

As Joachim noted, this behavior only effects DB2 CLI character fields, so it only makes sense to set it for  DB2 CLI connections.  I  chose the default behavior of having  it continue to return a Character to avoid having to respond to a endless 'string' of error reports :-)  That is why no senders are found in the base image.  Fwiw, I think your solution of  testing 'self iniSettingsSayDB2' after you create the connection but before you set the setting makes perfectly good sense.  

Bob
Reply all
Reply to author
Forward
Message has been deleted
0 new messages