From: Paul R. <pau...@at...> - 2003-03-21 16:59:04
|
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" <Low...@be...> To: 'FreeTDS Development Group' <fr...@li...> Subject: RE: [freetds] Help: MSSql/FreeTDS/Python now unstable Date: 18 Mar 2003 13:32:12 -0500 > From: Paul Rensing [mailto:pau...@at...] > 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 Fr...@li... http://lists.ibiblio.org/mailman/listinfo/freetds -- Paul Rensing <pau...@at...> |