At 09:11 PM 2/1/98 -0500, Walden Leverich wrote:

>If the Client Access ODBC driver requires you to rebind before every
>statement execution than there is a bug in the driver. The SQLBindCol
>section of the ODBC reference rather clearly states: "The binding remains in
>effect until it is replaced by a new binding, the column is unbound, or the
>statement is freed."
>Now there are issues that you need to account for in the way VB handles
>strings -- VB feels that it ca freely move strings to another location
>whenever it wants to -- but if you have accounted for these issues the ODBC
>driver should allow a bind to work across executions. If it isn't, I'd
>report it to IBM as a bug.

Yep, it seems to be a driver problem all right. It's been running for months 
with the EHNODBC3 driver, doing just as you say. I can't run the old driver 
under Win95 in my environment though, so I was forced to convert to the CWB 
driver. Unfortunately reality is such that it was necessary to make it work as 
is. This application is feeding orders to our production line. Even so, 
communication is way faster with the new driver than it was before, and that's 
with doing a prepare before each command. If IBM get's this straightened out, 
this baby will fly. I'm afraid I just don't have the resources to mess with the 
APAR process though. Not enough hours in the day.


Pete Hall

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "".
| To unsubscribe from this list send email to
| Questions should be directed to the list owner/operator:

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page