Menu
▾
▴
python-sybase-misc
|
From: Peter H. <hop...@ro...> - 2002-09-10 13:13:16
|
Hi, I'm trying to use the Sybase module from a Debian Linux 3.0 system (Python 2.1.3, FreeTDS 0.53). I've set up some Python code in order to create ASCII file containing the database scheme, functions and stored procedures. The code runs fine when connecting through ODBC from a Windows computer. It crashes when connecting from the Linux client, as soon as the 2nd query is run. Has there already been some work done on it, both from the FreeTDS side (version 0.60rc1 came out these days, should I install it?) and the Sybase module side. Can I help in debugging the problem? As soon as I have again the chance to connect to the SQL Server (it's at a customers place) I will paste you the exact message (something about threads and relesing a lock that has not been set). Let me know if I can help, Peter |
|
From: Kevin J. <ja...@pe...> - 2002-09-10 14:08:39
|
On 9 Sep 2002, Peter Hopfgartner wrote: > I'm trying to use the Sybase module from a Debian Linux 3.0 system > (Python 2.1.3, FreeTDS 0.53). > > I've set up some Python code in order to create ASCII file containing > the database scheme, functions and stored procedures. The code runs fine > when connecting through ODBC from a Windows computer. It crashes when > connecting from the Linux client, as soon as the 2nd query is run. > > Has there already been some work done on it, both from the FreeTDS side > (version 0.60rc1 came out these days, should I install it?) and the > Sybase module side. Can I help in debugging the problem? All I can suggest is that you use the _very_ lastest FreeTDS library. The last released version had some rather nasty bugs in it. > As soon as I have again the chance to connect to the SQL Server (it's > at a customers place) I will paste you the exact message (something > about threads and relesing a lock that has not been set). Ah! I've run into this myself. I'll dig up my patches that re-work the Sybase module locking code that fixes it (though I'm not sure if I'm just working around errors in the FreeTDS LibCT implementation or unsafe assumptions that David Cole made about Sybase's implementation). -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: ja...@th... Fax: (216) 986-0714 WWW: http://www.theopalgroup.com |
|
From: Dave C. <dj...@ob...> - 2002-09-10 17:31:46
|
>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes: Kevin> On 9 Sep 2002, Peter Hopfgartner wrote: >> I'm trying to use the Sybase module from a Debian Linux 3.0 system >> (Python 2.1.3, FreeTDS 0.53). >> >> I've set up some Python code in order to create ASCII file >> containing the database scheme, functions and stored >> procedures. The code runs fine when connecting through ODBC from a >> Windows computer. It crashes when connecting from the Linux client, >> as soon as the 2nd query is run. >> >> Has there already been some work done on it, both from the FreeTDS >> side (version 0.60rc1 came out these days, should I install it?) >> and the Sybase module side. Can I help in debugging the problem? Kevin> All I can suggest is that you use the _very_ lastest FreeTDS Kevin> library. The last released version had some rather nasty bugs Kevin> in it. >> As soon as I have again the chance to connect to the SQL Server >> (it's at a customers place) I will paste you the exact message >> (something about threads and relesing a lock that has not been >> set). Kevin> Ah! I've run into this myself. I'll dig up my patches that Kevin> re-work the Sybase module locking code that fixes it (though Kevin> I'm not sure if I'm just working around errors in the FreeTDS Kevin> LibCT implementation or unsafe assumptions that David Cole made Kevin> about Sybase's implementation). I am very keen to get the module working with FreeTDS. I think the future of the module is largely tied to the success of FreeTDS. - Dave -- http://www.object-craft.com.au |
|
From: Harri P. <har...@tr...> - 2002-09-11 00:15:44
|
On Tuesday 10 September 2002 02:31, Dave Cole wrote: > >>>>> "Kevin" =3D=3D Kevin Jacobs <ja...@pe...> wri= tes: > > Kevin> On 9 Sep 2002, Peter Hopfgartner wrote: > >> I'm trying to use the Sybase module from a Debian Linux 3.0 system > >> (Python 2.1.3, FreeTDS 0.53). > >> > >> I've set up some Python code in order to create ASCII file > >> containing the database scheme, functions and stored > >> procedures. The code runs fine when connecting through ODBC from a > >> Windows computer. It crashes when connecting from the Linux client, > >> as soon as the 2nd query is run. > >> > >> Has there already been some work done on it, both from the FreeTDS > >> side (version 0.60rc1 came out these days, should I install it?) > >> and the Sybase module side. Can I help in debugging the problem? > > Kevin> All I can suggest is that you use the _very_ lastest FreeTDS > Kevin> library. The last released version had some rather nasty bugs > Kevin> in it. > > >> As soon as I have again the chance to connect to the SQL Server > >> (it's at a customers place) I will paste you the exact message > >> (something about threads and relesing a lock that has not been > >> set). > > Kevin> Ah! I've run into this myself. I'll dig up my patches that > Kevin> re-work the Sybase module locking code that fixes it (though > Kevin> I'm not sure if I'm just working around errors in the FreeTDS > Kevin> LibCT implementation or unsafe assumptions that David Cole made > Kevin> about Sybase's implementation). > > I am very keen to get the module working with FreeTDS. I think the > future of the module is largely tied to the success of FreeTDS. > I also played with the Sybase module + FreeTDS combo, using FreeTDS curre= nt=20 snapshot. I ran into some problems where the equivalent code that ran against a Syb= ase=20 db would halt with some error message when running against MS-SQL server.= =20 Some things I was able to sort out just by closing and reallocating a cu= rsor=20 prior to continuing. Note that I've had similar problems with Sybase mod= ule=20 against Sybase DB, where I need to read all the result sets from a cursor= =20 before I can successfully run a stored procedure. With Sybase+FreeTDS I then had the next problem with some threading asser= ts=20 failing. As I'm not using threads in my script, I boldly removed all=20 threading and locking support from Sybase.py, and everything I was doing=20 starting working. Now the only remaining problem I have is that some sto= red=20 procedure calls are segfaulting. I heard a rumour the FreeTDS does not have support for on the wire proced= ure=20 calls / parameter binding. If that is true, so it may not be at the leve= l=20 off Sybase libs for some time. -Harri |
|
From: hopfgartner <hop...@ro...> - 2002-09-11 01:18:17
|
>
> Kevin> All I can suggest is that you use the _very_
> lastest FreeTDS
> Kevin> library. The last released version had some
> rather nasty bugs
> Kevin> in it.
>
Ok, I've got the cvs-sources, build them, rebuild the
sybase-python package and run my scripts again.
> >> As soon as I have again the chance to connect to the
> SQL Server
> >> (it's at a customers place) I will paste you the exact
> message
> >> (something about threads and relesing a lock that has
> not been
> >> set).
Here we go:
Traceback (most recent call last):
File "sqlDumpTbl.py", line 143, in ?
dump.dump()
File "sqlDump.py", line 64, in dump
obj_text = 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 = ' +
File "/usr/lib/python2.1/site-packages/Sybase.py", line
346, in execute
self._unlock()
File "/usr/lib/python2.1/site-packages/Sybase.py", line
259, in _unlock
self._owner._lock.release()
File "/usr/lib/python2.1/threading.py", line 101, in
release
assert self.__owner is me, "release() of un-acquire()d
lock"
AssertionError: release() of un-acquire()d lock
>
> Kevin> Ah! I've run into this myself. I'll dig up my
> patches that
> Kevin> re-work the Sybase module locking code that fixes
> it (though
> Kevin> I'm not sure if I'm just working around errors in
> the FreeTDS
> Kevin> LibCT implementation or unsafe assumptions that
> David Cole made
> Kevin> about Sybase's implementation).
>
> I am very keen to get the module working with FreeTDS. I
> think the
> future of the module is largely tied to the success of
> FreeTDS.
>
> - Dave
I agree perfectly with you. Let me know if I can help.
>
> --
> http://www.object-craft.com.au
>
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ob...
>
https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
Peter
|
|
From: Harri P. <har...@tr...> - 2002-09-11 01:46:16
Attachments:
Sybase.py.test-patch
|
On Tuesday 10 September 2002 10:18, hopfgartner wrote:
>
> Here we go:
>
> 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
> 346, in execute
> self._unlock()
> File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 259, in _unlock
> self._owner._lock.release()
> File "/usr/lib/python2.1/threading.py", line 101, in
> release
> assert self.__owner is me, "release() of un-acquire()d
> lock"
> AssertionError: release() of un-acquire()d lock
>
I saw exactly the same thing. If you feel adventurous you can apply the=
=20
quick and dirty patch I have attached to effectively remove the threading=
=20
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 m=
e.
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 |
|
From: hopfgartner <hop...@ro...> - 2002-09-11 02:13:30
|
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 = 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 = ' +
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.
Peter
|
|
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
|
|
From: Kevin J. <ja...@pe...> - 2002-09-11 04:40:09
Attachments:
diff
|
On Tue, 10 Sep 2002, Harri Pasanen wrote: > I experienced similar things. Probably if you change the query order, it will > still be so that the first one works. So the problem is that the connection > / cursors keep some state that throws it off balance. > > I managed to work around this by closing the cursor and reallocating a new one > for the next query. And having opened the connection with 'auto_commit=1' > also helped. Attached is a _very_ experimental patch that re-works some of the connection state logic and locking in the Sybase.py module. Please apply it to an original copy of Sybase.py, and let me know how it goes. With it, I am able to run many queries in sequence very reliably. Unfortunately, I don't have a Sybase installation to test, so I don't know exactly where the FreeTDS implementation of libCT seems to be diverging from what must obviously be robust for many Sybase users. Good luck, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: ja...@th... Fax: (216) 986-0714 WWW: http://www.theopalgroup.com |
|
From: hopfgartner <hop...@ro...> - 2002-09-11 05:05:22
|
On Tue, 10 Sep 2002 06:40:18 -0400 (EDT) Kevin Jacobs <ja...@pe...> wrote: > On Tue, 10 Sep 2002, Harri Pasanen wrote: > > I experienced similar things. Probably if you change > the query order, it will > > still be so that the first one works. So the problem > is that the connection > > / cursors keep some state that throws it off balance. > > > > I managed to work around this by closing the cursor and > reallocating a new one > > for the next query. And having opened the connection > with 'auto_commit=1' > > also helped. > > Attached is a _very_ experimental patch that re-works > some of the connection > state logic and locking in the Sybase.py module. Please > apply it to an > original copy of Sybase.py, and let me know how it goes. > With it, I am able > to run many queries in sequence very reliably. > Unfortunately, I don't have > a Sybase installation to test, so I don't know exactly > where the FreeTDS > implementation of libCT seems to be diverging from what > must obviously be > robust for many Sybase users. > > Good luck, > -Kevin > > -- > Kevin Jacobs > The OPAL Group - Enterprise Systems Architect > Voice: (216) 986-0710 x 19 E-mail: > ja...@th... > Fax: (216) 986-0714 WWW: > http://www.theopalgroup.com The patch behaves exactly like the previous one. Anyway, your trick of closing and reallocating the cursor for every query works great. Thank you, Peter |
|
From: Dave C. <dj...@ob...> - 2002-09-21 20:35:34
|
>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes: Kevin> On Tue, 10 Sep 2002, Harri Pasanen wrote: >> I experienced similar things. Probably if you change the query >> order, it will still be so that the first one works. So the >> problem is that the connection / cursors keep some state that >> throws it off balance. >> >> I managed to work around this by closing the cursor and >> reallocating a new one for the next query. And having opened the >> connection with 'auto_commit=1' also helped. Kevin> Attached is a _very_ experimental patch that re-works some of Kevin> the connection state logic and locking in the Sybase.py module. Kevin> Please apply it to an original copy of Sybase.py, and let me Kevin> know how it goes. With it, I am able to run many queries in Kevin> sequence very reliably. Unfortunately, I don't have a Sybase Kevin> installation to test, so I don't know exactly where the FreeTDS Kevin> implementation of libCT seems to be diverging from what must Kevin> obviously be robust for many Sybase users. After being away from this stuff for a while I am now ready to get back into it. Sorry for the absence. I would like to build a new release (0.35pre2) but before I do that can I ask people to try the patch from Kevin Jacobs? There seems to be some variance in the observed behaviour. Can people please report whether what configuration they are using and whether or not they are having problems? client platform (win/linux/solaris...): client library (freetds/sybase vers): server plaform: server release: It would really help if we could build up some sort of profile. - Dave -- http://www.object-craft.com.au |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X