[plt-scheme] schemeql

From: Francisco Solsona (solsona at acm.org)
Date: Mon Mar 24 13:40:56 EST 2003

steck at ccs.neu.edu (Paul Steckler) writes:

> Anton van Straaten wrote:
>> I now have SchemeQL lying in a quivering heap on the floor in front of me,
>> begging for mercy.

Cool... :-) 

> The horror, the horror.
>> The "Invalid string or buffer length" exception was being caused by the
>> following function in Schemeql's odbc.ss:
>>   (define is-column-unsigned?
>>     (lambda (hstmt index)
>>       (sister-interaction
>>        (if (>= (sister-ver) 3.0)
>> 	   (sr:col-attribute hstmt index 'sql-desc-unsigned)
>> 	   (sr:col-attributes hstmt index 'sql-column-unsigned))
>>        'unknown #f #f hstmt)))
> Without an ODBC manual here, I can't guess the significance 
> of this problem.

There is a funny interaction between the ODBC driver manager
(e.g. iODBC, unixODBC), and the actual ODBC driver (e.g. myODBC,
psqlODBC).  According to ODBC 3.5 Developers Guide (by Roger
E. Sanders), SQLColAttribute (SrPersist's col-attribute) is compatible
with ODBC 3.0 and 3.5.

However, as many have noticed, calling col-attribute in a 3.51 (or any
> 3.0) driver breaks.  I'm not sure why, because I haven't used any
driver greater than 3.0.  I see two possible solutions:

   (a) to catch, inside SchemeQL, any exception regarding the use of
   col-attribute, ignore it, and then try col-attributes (note the
   final `s', which is the ODBC 2.0 name for the exact same function!)

   (b) to find the place in SrPersist where this procedure is
   implemented, and see if something is wrong, or catch this buggy
   exceptions there.

In any event, making the call to col-attribute(s) is important to
retrieve the column size (of every column) and then create appropriate
buffers to receive the results, so it is *not* an option to remove
this call.

According to this reference I have, inverting the condition above is
not the Right Thing(TM) to do either.  It would mean that your ODBC
driver is 2.0 compliant, not 3.51, or such... but is it?

The (c) option I omit above is to shut all ODBC creators, and
maintainers for making it so hard to use it in the presence of
different versions, and do it all over again. :-)

Good news.  Ten weeks from Friday will be a pretty good day.

Posted on the users mailing list.