Skip to Content.
Sympa Menu

freetds - RE: [freetds] Help: MSSql/FreeTDS/Python now unstable

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Help: MSSql/FreeTDS/Python now unstable
  • Date: Tue, 18 Mar 2003 13:32:12 -0500

> From: Paul Rensing [mailto:paul.rensing AT att.net]
> Sent: March 18, 2003 11:56 AM
>
> The Python Sybase driver uses the CT interface. I turned on
> debugging of
> the Python driver in the place where it usually fails. I have attached
> the output of the tracing.
>
> The problem seems to be that, for the SQL query, occasionally it gets
> back from ct_results() a status of CS_STATUS_RESULT, instead of the
> usual CS_ROW_RESULT. After that it is very confused. If I immediately
> repeat the same query, it works just fine.
>
> I am still wondering if this could be a timing issue on the
> server end.

Microsoft servers issue spurious status result packets, far more than they
need to. FreeTDS can't know which ones are real and which are noise, so it
passes them all up the stack. I don't know that it's a timing issue,
exactly; I haven't found rhyme or reason.

The Python folks wouldn't have bumped into this using Sybase's libraries
because they likely wouldn't have tried to connect to a Microsoft server
(and, even if they did, it would be TDS 4.2 and, as you say, the behavior is
sporadic).

FreeTDS is violating the ct-lib specification IMO, because it's returning
CS_STATUS_RESULT for a query that's not a stored procedure. The problem
is, we don't know it's not a stored procedure (because we don't parse the
outbound SQL), so we don't know the returned status packet should be
squelched from the ct-lib interface.

If I'm right about all this, I'm afraid Python's just going to have to deal.
:/

Nice detective work, if I may say so.

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





Archive powered by MHonArc 2.6.24.

Top of Page