FreeTDS Development Group

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

Interesting thing. I am now calling dbresults() for non-select queries, too,
and everything works. I cannot even get the db-lib into infinite loop after
I manually disconnect the MSSQL server machine (though I'll keep checking if
it ever occurs again)
:-).
Thanks!




> -----Original Message-----
> From: Lowden, James K [mailto:LowdenJK AT bernstein.com] 
> Sent: Thursday, January 20, 2005 3:14 AM
> To: FreeTDS Development Group
> Subject: RE: [freetds] Update query breaks the normal course 
> of events (alsoother probl ems)
> 
> 
> > 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.
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org 
> http://lists.ibiblio.org/mailman/listinfo/freetds
>