|
Hi all, I have just migrated a DLL that uses the DBTools API from ASA 8.0.3. to SA 11.0.1. It is implemented as a SQL Anywhere external call library. Among others, it has a function to verify the validity of a transaction log. It does so by using the DbTranslateLog() API. As stated in the docs, the DBTools API is generally compatible w.r.t. to different versions when the according version number is set correctly in the DBTools structures. But running the DLL against a SA 12 transaction log does not work - it gives a version mismatch error. However, the same error is displayed when running v11 DBTRAN against a v12 transaction log. AFAIK, there are a few utilities that must be used in the same version (including build number, methinks) as the database engine, particularly DBUNLAOD and DBXTRACT. DBTRAN might be one of them, too. Question: Is the general DBTools compatibility limited for those API calls that require to be the same version as the database/log they work on? In other words: Do I have to build different DLLs for different (major/minor) versions then? (If so, that ought to be documented somewhere...) EDITED: Note that this is not a problem to solve but just something I try to understand. As it is our own development, it's no problem to build version-specific DLLS. |
|
Since no real answer has arrived yet: Studying the DBTools header files for SQL Anywhere 11 and 12, it seems that several structures have changed significantly. As such, I have the impression that the DbTools API is primarily compatible within the same base version (i.e. between major versions like 11.0.0 vs. 11.0.1). It seems not to be generally compatible between, say version 11 and 12. And this would make sense IMHO, as an application is usually linked statically against a particular versioned DLL, i.e. against dbtools11.dll vs. dbtools12.dll. As said, no real answer - just my observations:) Feel free to confirm or correct these assumptions. |
|
Note: This is more a verbose comment than an answer - I just wanted to use formatting... Just to confirm the version mismatch: When using the DLL linked against the DBTools V11 API with the V12 engine and database, the actual error message running DBTranslateLog() is (German locale):
translated:
Calling DBToolsVersion() returns 11000 as expected. Therefore I have still the strong impression that there is no overall version compatibility w.r.t. to the DBTools API. Any more insights are still welcome:) |
Has your database been rebuilt to be a v11 database? The v11 dbtools will not be able to process an 8.0.3 database.
Yes, I have rebuild the database both for SA 11.0.1 and SA 12 and tested with logs of the according migrated dbs. The DBTools effect is similar to DBTRAN (which is understandable as DBTRAN uses DBTools itself, AFAIK): DBTRAN v8 and DBTRAN v11 can't translate a v12 log (which is understandable). In contrast, DBTRAN v12 can translate a v11 log.
I have just replaced the v11 lib file (in my case dbtlstm.lib from the x86 dir) with the v12 version, and now it works (as dbtool12.dll is loaded instead of dbtool11.dll). Seems logically that the lib file defines which DLL is loaded. - For a "load the DLL version of the engine" system, I guess the DLLs would have to use generic names (just Dbtool.DLL) instead of the version-specific ones. But that might prevent several versions being in use at the same time...