From: Harri P. <har...@tr...> - 2002-09-11 02:38:46
|
On Tuesday 10 September 2002 11:13, hopfgartner wrote: > On Tue, 10 Sep 2002 10:46:22 +0200 > > Harri Pasanen <har...@tr...> wrote: > > I saw exactly the same thing. If you feel adventurous > > you can apply the > > quick and dirty patch I have attached to effectively > > remove the threading > > support which I suspect you are not using anyway. > > > > Note that the patch is in no way cleaned to be final, it > > just works for me. > > > > Just copy the Sybase.py from > > /usr/lib/python2.2/site-packages/Sybase.py > > to your test script directory, and run: > > > > patch < Sybase.py.test-patch > > > > Then your script has a chance of passing this hurdle... > > > > -Harri > > The message changed, the result is the same: > > Traceback (most recent call last): > File "sqlDumpTbl.py", line 143, in ? > dump.dump() > File "sqlDump.py", line 64, in dump > obj_text =3D self.get_obj_definition(sp[0]) > File "sqlDumpTbl.py", line 31, in get_obj_definition > self.sql_cursor.execute('SELECT name FROM sysobjects > WHERE id =3D ' + > File "/usr/lib/python2.1/site-packages/Sybase.py", line > 323, in execute > self.nextset() > File "/usr/lib/python2.1/site-packages/Sybase.py", line > 422, in nextset > self._raise_error(Error, 'ct_cancel') > File "/usr/lib/python2.1/site-packages/Sybase.py", line > 259, in _raise_error > raise exc(text) > Sybase.Error: ct_cancel > > The strange thing is, that the first query has alredy > succeded at this point. The failure happens always at the > second query. > I experienced similar things. Probably if you change the query order, it= will=20 still be so that the first one works. So the problem is that the connec= tion=20 / cursors keep some state that throws it off balance. I managed to work around this by closing the cursor and reallocating a ne= w one=20 for the next query. And having opened the connection with 'auto_commit=3D= 1'=20 also helped. =20 -Harri |