FreeTDS Development Group

["Polyanovskyi, Sasha" <sasha.polyanovskyi AT oa.com.au>]

Hello, people
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).

E.g.

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
responses)?

Some of the other problems I encounter (any helpful suggestions would be
welcome): 
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
function "tds_process_default_tokens"...

Anyway, anyone who feels like replying to any this, please do so.

*panic* :-)