[python-sybase] Fwd: Problem with Sybase.py and MS SqlServer

Paul Rensing paul.rensing at att.net
20 Mar 2003 16:58:53 -0500


Hello,

I have been using the Python Sybase driver and FreeTDS to talk to MS
Sqlserver 2000. I recently had to upgrade Sybase.py (to 0.36pre6) and
FreeTDS, but unfortunately this has caused some instability in my code.
I have managed to work around it, but it is kind of a hack, so I am
hoping we can fix it properly.

Below is a reposting of the final message in the thread on the FreeTDS
list. I would be happy to forward all of them.

Basically, the problem seems to be that Sqlserver sends spurious
packets. FreeTDS passes those up the chain because it does not know any
better, and Sybase.py gets confused. 

I am happy to try various things, but I don't know a lot about the TDS
protocol and CT library.

Any suggestions? Thanks,

	Paul Rensing

	
-----Forwarded Message-----

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

> From: Paul Rensing [mailto:paul.rensing@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.


_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
-- 
Paul Rensing <paul.rensing@att.net>