Skip to Content.
Sympa Menu

freetds - RE: [freetds] Update query breaks the normal course of events

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Polyanovskyi, Sasha" <sasha.polyanovskyi AT oa.com.au>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Update query breaks the normal course of events
  • Date: Thu, 20 Jan 2005 14:21:09 +1100

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
>



  • RE: [freetds] Update query breaks the normal course of events, Polyanovskyi, Sasha, 01/19/2005

Archive powered by MHonArc 2.6.24.

Top of Page