[freetds] Update query breaks the normal course of events (also other probl ems)
sasha.polyanovskyi at oa.com.au
Wed Jan 19 02:05:37 EST 2005
Here is my problem (I am running latest stable version of freetds db-lib
(0.62.4) and MSSQL 2000).
>From the point of me executing an "update" or an "insert" statement, things
go wrong (I do execution of sql statements in quick succession).
1) "select count(*) ..." returns 1 result -- normally. However, after an
"update" statement, the same very "select" sometimes returns no results. In
fact, it may not be the first "select" after an "update", but a third one or
a fifth one, etc. (totally non-deterministic).
2) I do an "insert" statement that should violate a primary key rule. It
succeeds (dbsqlexec returns SUCCESS). Then I start doing the above-mentioned
"select" statements. After a while my select statement generates an error
from the server -- the error that should have been returned with the
"insert" statement. As if there is a delay from the server...
Does anyone have any explanation or encountered anything like this?
Error from my first example concerns me much more...
Another question: my second example suggests that dbsqlexec() is a
non-blocking call. Is there a way to block program execution untill
everything is received from the SQL server (i.e. until I get all the
Some of the other problems I encounter (any helpful suggestions would be
1) Once in a while I get "Operating System Error 0: OpenClient". It usually
(maybe I could even say "always") is preceeded by "DB-Library Error 20006:
Write to SQL Server failed". As I mentioned, I send quite a lot of SQL
queries frequently, but I do wait for the response from each query before
attempting the next one... What does this error mean anyway? (It is returned
by my error_handler function)
2) When I get this "OpenClient" error because I physically unplug database
server from the network ("DB-Library Error 20004: Read from SQL server
failed"), my process (built on db-lib) starts hard-looping (even after I do
put the network cable back in). According to "gdb" it sits in a db-lib
Anyway, anyone who feels like replying to any this, please do so.
More information about the FreeTDS