Ditmar Van Belle
2013-12-30 03:54:11 UTC
Howdy folks!
First post, so hang in there for a while. I've obtained a dblib.dll (don't ask me where) which I'm using through FreePascal to communicate with this company MSSQL 2005. For a moment I was in heaven... until I ran into this: an INSERT INTO statement that unexpectedly returned two resultsets, due to a stored procedure attached to a trigger on the table. (the procedure is not mine so there's not much I can do to prevent it from outputting the resultsets).
Why would that be a problem, you ask? Well, first off: if I don't read them, next statement receives an error 20019 (y'all know what that means). Perhaps worse: the insert will not COMMIT until this statement can be sucessfully completed. There is another complexity with the freepascal implementation involved, but I might be able to work around that. In short, the FreePascal library has an SqlExec function to execute statements such as Insert, Update, Delete -- those that do not provide output (well... usually). And then there's Open, to read resultsets (eg. procedures and queries).
Several days of headache ensued until I rebuilt my multithreaded daemon into a single-threaded GUI version so that I could actually debug the son of a b**, and to adapt the FreePascal library to make SqlExec read all, if any, results and discard them properly. As far as I can see, however, such mechanic is already in place. So commenced plan D, the "step-by-step" debug...
Turns out in fact, that the dbsqlexec statement never returns! And yes, this was also the case in the multithreaded version-- the daemon was able to continue most of its work but the table involved just remained locked at server level and the Insert never actually happened. Pretty nasty eh?
What else can I say...? Ah well, this behaviour is observed with both NTwDBlib and DBLib (FreeTDS)... Anybody any bright ideas? In the meantime I'll try to retrace where this DLL came from, as to verify which source code it was built from. Incorporating C sources in a Pascal program might get a little tricky, so in-depth debugging is somewhat out of the question :-(
Thank you,
-Ditmar
First post, so hang in there for a while. I've obtained a dblib.dll (don't ask me where) which I'm using through FreePascal to communicate with this company MSSQL 2005. For a moment I was in heaven... until I ran into this: an INSERT INTO statement that unexpectedly returned two resultsets, due to a stored procedure attached to a trigger on the table. (the procedure is not mine so there's not much I can do to prevent it from outputting the resultsets).
Why would that be a problem, you ask? Well, first off: if I don't read them, next statement receives an error 20019 (y'all know what that means). Perhaps worse: the insert will not COMMIT until this statement can be sucessfully completed. There is another complexity with the freepascal implementation involved, but I might be able to work around that. In short, the FreePascal library has an SqlExec function to execute statements such as Insert, Update, Delete -- those that do not provide output (well... usually). And then there's Open, to read resultsets (eg. procedures and queries).
Several days of headache ensued until I rebuilt my multithreaded daemon into a single-threaded GUI version so that I could actually debug the son of a b**, and to adapt the FreePascal library to make SqlExec read all, if any, results and discard them properly. As far as I can see, however, such mechanic is already in place. So commenced plan D, the "step-by-step" debug...
Turns out in fact, that the dbsqlexec statement never returns! And yes, this was also the case in the multithreaded version-- the daemon was able to continue most of its work but the table involved just remained locked at server level and the Insert never actually happened. Pretty nasty eh?
What else can I say...? Ah well, this behaviour is observed with both NTwDBlib and DBLib (FreeTDS)... Anybody any bright ideas? In the meantime I'll try to retrace where this DLL came from, as to verify which source code it was built from. Incorporating C sources in a Pascal program might get a little tricky, so in-depth debugging is somewhat out of the question :-(
Thank you,
-Ditmar