FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Polyanovskyi, Sasha
> Sent: Wednesday, January 19, 2005 2:06 AM
> 
> (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).

Hello Sasha, 

The problems you describe are serious, or would be if they're in the
library.  Since 0.62.4 was released a long time ago and is in widespread
use, we should probably start by looking at your application logic.  

The rapidity of your exchanges with the server is immaterial.  TDS is a
half-duplex protocol; by the time you've received the server's response,
it's already prepared for your next query.  

You imply you're using db-lib.  Can you reproduce any of the described
behaviors with bsqldb?  

> 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...

After sending a query -- any query, not only SELECT statements -- it's
not enough merely to check the return code of dbsqlexec().  That return
code means only that the server received your query, not what it did
with it.  It's important to call dbresults(), too, because only then
will db-lib read the server's response.  That response need not be data;
it may be an error message.  

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

I hope this question is now answered.  ;-)

The rest of the behaviors you describe are consistent with failing to
call dbresults() after every dbsqlexec().  OTOH, if you *can* reproduce
any of them with bsqldb, I'd be very interested in fixing it.  

HTH.  

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.