External ODBC link no longer works after upgrading v9 -> v10

[Richard Davies]

For Actinic v9, I have a MySQL 5.1 database (on Windows) and a table which contains my product lines. I then use the external linking facility to obtain this data via ODBC, and everything was working how I expected it to.

However after upgrading to v10, I suddenly noticed a repetition of a number of products - it was like the internal actinic database had been retaining some 'dead' info and resurrected it after the upgrade. So I decided to delete everything and just link to the external source again to grab a set of fresh untainted data. That's when I noticed that actinic wasn't linking to my external data.

Even starting out with a fresh site, a new database and a empty table (with a primary key of course) it still spouts the same error:

ODBC -- Connection to 'my database' failed.

Which is somewhat spurious as it had to connect to the DataSource to present me with a list of tables to choose from.

For your info v9 connects to this newly created database/table without issue.

A showstopper at the moment as v10 doesn't have a catalog!

[malbro]

For Actinic v9, I have a MySQL 5.1 database (on Windows) and a table which contains my product lines. I then use the external linking facility to obtain this data via ODBC, and everything was working how I expected it to.

However after upgrading to v10, I suddenly noticed a repetition of a number of products - it was like the internal actinic database had been retaining some 'dead' info and resurrected it after the upgrade. So I decided to delete everything and just link to the external source again to grab a set of fresh untainted data. That's when I noticed that actinic wasn't linking to my external data.

Even starting out with a fresh site, a new database and a empty table (with a primary key of course) it still spouts the same error:

ODBC -- Connection to 'my database' failed.

Which is somewhat spurious as it had to connect to the DataSource to present me with a list of tables to choose from.

For your info v9 connects to this newly created database/table without issue.

A showstopper at the moment as v10 doesn't have a catalog!

The odbc to V10 catalog does work as I have been using it with PHP code to access the catalog however the name has changed from ActinicCatalog9 to ActinicCatalog10, could this be the problem?

[Richard Davies]

Well I've now had time to take a look into what is going on. This is the relevant part of the SQL trace log from when I try to externally link with Actinic v10:

Catalog 2d0-a78 ENTER SQLSetConnectOption
HDBC 0x036B8520
SQLINTEGER 103 <SQL_LOGIN_TIMEOUT>
SQLPOINTER 20

Catalog 2d0-a78 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS)
HDBC 0x036B8520
SQLINTEGER 103 <SQL_LOGIN_TIMEOUT>
SQLPOINTER 20

Catalog 2d0-a78 ENTER SQLSetConnectAttrW
SQLHDBC 0x036B8520
SQLINTEGER 30002 <unknown>
SQLPOINTER [Unknown attribute 30002]
SQLINTEGER -3

Catalog 2d0-a78 EXIT SQLSetConnectAttrW with return code 0 (SQL_SUCCESS)
SQLHDBC 0x036B8520
SQLINTEGER 30002 <unknown>
SQLPOINTER [Unknown attribute 30002]
SQLINTEGER -3

Catalog 2d0-a78 ENTER SQLDriverConnectW
HDBC 0x036B8520
HWND 0x0004044A
WCHAR * 0x73398634 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x73398634
SWORD -3
SWORD * 0x00000000
UWORD 1 <SQL_DRIVER_COMPLETE>

Catalog 2d0-a78 EXIT SQLDriverConnectW with return code -1 (SQL_ERROR)
HDBC 0x036B8520
HWND 0x0004044A
WCHAR * 0x73398634 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x73398634
SWORD -3
SWORD * 0x00000000
UWORD 1 <SQL_DRIVER_COMPLETE>

DIAG [S1000] [Microsoft][ODBC Driver Manager] General error: invalid window handle (0)

Catalog 2d0-a78 ENTER SQLErrorW
HENV 0x03695ED0
HDBC 0x036B8520
HSTMT 0x00000000
WCHAR * 0x0018D21C
SDWORD * 0x0018D1E8
WCHAR * 0x0EF02BE8
SWORD 4095
SWORD * 0x0018D1DC

Catalog 2d0-a78 EXIT SQLErrorW with return code 0 (SQL_SUCCESS)
HENV 0x03695ED0
HDBC 0x036B8520
HSTMT 0x00000000
WCHAR * 0x0018D21C [ 5] "S1000"
SDWORD * 0x0018D1E8 (0)
WCHAR * 0x0EF02BE8 [ 69] "[Microsoft][ODBC Driver Manager] General error: invalid window handle"
SWORD 4095
SWORD * 0x0018D1DC (69)

OK, it still isn't conclusive but with the log reporting that a string literal's null-termination is broken, and a window handle being invalid (if that actually is true) leads me prima facie to suspect a 32/64 bit compilation cock-up. I say this because both v9 and external testing of the database obtains correct values from the ODBC API, however I know how easy it is to use a local c/c++ type definition such as int instead of the database provided #define, and bosh, when compiling on a different architecture byte lengths are suddenly all wrong.

Anyway, there are a few things that I want to try first, I might actually disassemble it to prove the point (or otherwise) but I don't really want to be spending my time doing this.

Kind regards,