| | | | | Browse by category |
After an exception is thrown from a DBTools.h++ error handler, DBTools.h++ operations which access the database server do not work and various errors are generated. It may appear that the database connection has been corrupted in some way.
Cause
This is a known problem we have seen on Sybase CT-lib, DB-Lib, and MS SQL Server, with respect to DBTools.h++ versions 1x and 2x.
These database vendors use a callback mechanism for their error model, where DBTools.h++ registers a function with the vendor library to get called in case of an error. From this function, DBTools.h++ calls your error handler to notify you of the error.
When an exception is thrown from your error handler, each function on the call stack must be popped off until a matching 'catch' block is found. However, the vendor libraries themselves are still on the stack, and since they are written in C, are not exception safe (see the accompanying figure which illustrates this.) When they are popped off, this can result in any number of problems. Usually the database connection is corrupted.
Action
DBTools release 3.x and above versions allows exceptions to be used with Sybase and MS SQL Server databases; the error model now caches vendor errors, to be retrieved for the user's error handler function after the program has returned from the vendor library calls.
For earlier versions of the DBTools.h++ libraries (1x and 2x), there is no known workaround to this problem at this time, other than simply not throwing exceptions. Errors must either be processed in the error handler directly or the main body of the application must check for errors using isValid() methods and taking the appropriate action at that time. It is a limitation in the design of Sybase CT-Lib and MS SQL Server and not easily fixed. At this time there is not a workaround that will allow the use of exceptions with these two database vendors.
Why won't the InfoBrowser contents update in response to selection changes in ClassView or FileView?
