Subject | Re: ODBC for IB6 |
---|---|
Author | Jim Starkey |
Post date | 2000-06-23T14:38:24Z |
At 05:46 PM 6/23/00 +0400, you wrote:
in error, and a suggestion for a fix. Maybe, just maybe, this open
source stuff has something going for it.
As you have probably already deduced, the Attachment object has
already gone through some effort to determine the proper database
dialect. I put in the literal while I fought that fire and just
plane forget the change it.
The dialect problem was this: When the concept was first invented,
a developer decided that the dialect of the original database creation
should be reported, not the max dialect understood by the database
(the developer is no longer with the company). Apparently, nobody
stopped to consider how a tool could determine what dialects are
supported by a database (this is now fixed).
Anyway, I have made the change as per your suggestion (I actually
added a couple of methods to fetch the dialect) and have checked
in the change.
Thanks for the report!
Jim Starkey
>Hello, Jim!What a pleasant surprise to get a bug report, and pointer to the line
>
>Our people are trying to use your OdbcJdbc library, and found
>that you hardcoded dialect 3 into Jdbc (รณ++) code. This prevents
>to connect from IB6 client to V5.x servers and dialect 1 databases.
>
>for example, in IncStatement.cpp, line 187
>
>isc_dsql_prepare (statusVector, &connection->transactionHandle,
>&statementHandle,
> 0, (char*) sqlString, SQL_DIALECT_V6, outputSqlda);
> ^^^^^^^^^^^^^^
>
>Here must be Attachment->dialect?
>
in error, and a suggestion for a fix. Maybe, just maybe, this open
source stuff has something going for it.
As you have probably already deduced, the Attachment object has
already gone through some effort to determine the proper database
dialect. I put in the literal while I fought that fire and just
plane forget the change it.
The dialect problem was this: When the concept was first invented,
a developer decided that the dialect of the original database creation
should be reported, not the max dialect understood by the database
(the developer is no longer with the company). Apparently, nobody
stopped to consider how a tool could determine what dialects are
supported by a database (this is now fixed).
Anyway, I have made the change as per your suggestion (I actually
added a couple of methods to fetch the dialect) and have checked
in the change.
Thanks for the report!
Jim Starkey