python-sybase-misc

[python-sybase] newbie: Sybase.py segv on import?

[De C. <de...@uc...>]

Greetings all.  I am a Python newbie but a Sybase hacker of old (also
a Tcl hacker).  I want to learn python and since databases are my
favourite play-toy and I have several sybase servers, I thought I
would get sybase-python and try it out.

I downloaded from the website 

	http://www.object-craft.com.au/projects/sybase/download.html

and installed using the install command suggested for linux systems

	python setup.py install

I downloaded the sample script (cut and pasted from

	http://www.object-craft.com.au/projects/sybase/examples.html

and edited it slightly to refer to one of my servers.

I then ran an interactive python session and pasted in commands
one at a time.

the first thing I noticed was that the libct.so was not automatically
found, I had to add /opt/sybase/lib to my LD_LIBRARY_PATH envar before
the Sybase.py module would work.

Python 1.5.2 (#1, Apr  3 2002, 18:16:26)  [GCC 2.96 20000731 (Red Hat Linux 7.2 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys, string, Sybase
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python1.5/site-packages/Sybase.py", line 15, in ?
    from sybasect import *
ImportError: libct.so: cannot open shared object file: No such file or directory
>>> 

adding /opt/sybase/lib to the LD_LIBRARY_PATH envar gets us past this error,
but...

Python 1.5.2 (#1, Apr  3 2002, 18:16:26)  [GCC 2.96 20000731 (Red Hat Linux 7.2 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys, string, Sybase
Segmentation fault (core dumped)

this is not encouraging :-)  

just to make sure

Python 1.5.2 (#1, Apr  3 2002, 18:16:26)  [GCC 2.96 20000731 (Red Hat Linux 7.2 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> import string
>>> import Sybase
Segmentation fault (core dumped)

it is definitely the sybase module that is croaking.

I am running this sybase server (in this instance):

  SQL Server/11.0.3.3/P/Linux Intel/Linux 2.0.36 i586/1/OPT/Thu Sep 10 13:42:44 CEST 1998 

the home page for the Sybase.py project says that 11.0.3 is supported, so I hope
I will be able to talk to my server if I can ever get the module to load.

the rest of the environment:

  gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

can anyone give me a clue please, so I can get started?

tia

de

-- 
.............................................................................
:De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
:Mail: de...@uc... |                                                     :
:Web: www.ucolick.org |             Don't Fear the Penguins                 :
:1024D/B9C9E76E           F892 5F17 8E0A F095 05CD  EE8B D169 EDAA B9C9 E76E:

Re: [python-sybase] newbie: Sybase.py segv on import?

[Dave C. <dj...@ob...>]

>>>>> "De" == De Clarke <de...@uc...> writes:

>>>> import sys, string, Sybase
De> Segmentation fault (core dumped)

De> this is not encouraging :-)

Try checking your LANG and/or LC_ALL environment.  The Sybase
libraries segfault when these are not correct.

De> the home page for the Sybase.py project says that 11.0.3 is
De> supported, so I hope I will be able to talk to my server if I can
De> ever get the module to load.

You should be able to get it going once the environment is sorted out.

- Dave

-- 
http://www.object-craft.com.au

[python-sybase] python newbie seeks advice on sybase.py

[De C. <de...@uc...>]

dear all:  the Fearless (and Clueless) Python Newbie here trying to
understand the sybase module :-)  Dave Cole very kindly helped me
to identify the source of the segv.  looks like libct is a bit
more temperamental than the libsybdb that I'm used to:  it gets
upset if the locale in LANG envar isn't in locales.dat, in the 
block for your OS.  segv seems like a rather extreme response
to this condition, but that's Sybase's problem :-)

am starting to get my bearings, have figured out where col names/types 
are stashed (c.description) after execution of a query.

but now am puzzled because I got a rowcount of -1 when I expected to
get a rowcount of <number of rows returned>.  here's the braindead code.

    c.execute('select * from numbers order by tablename')
    print c.description
    a = []
    for item in c.description:
        a.append(item[0])
    print "COL NAMES:",a
    print c.rowcount," ROWS"
    for row in c.fetchall():
        print row

python test.py
[('tablename', 0, 0, 30, 0, 0, 0), ('nserial', 8, 0, 4, 0, 0, 0), ('uid', 7, 0, 2, 0, 0, 32), ('stamp', 13, 0, 4, 0, 0, 32)]
COL NAMES: ['tablename', 'nserial', 'uid', 'stamp']
-1  ROWS
('Agents', 200, 1, '25/07/96')
('Alarms', 1, 1, '28/04/97')
...
currentThread(): no current thread for 1024

why do I get -1 rows?  the dbapi doco says this value is -1 when no
command has been executed;  but as you see, a SQL command has been
executed and rows are being returned.  am I missing something?

also as you see I keep getting this "no current thread" message.
it seems harmless (like a bogus condition on image rundown) but
I wish I knew what it meant.

de

-- 
.............................................................................
:De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
:Mail: de...@uc... |                                                     :
:Web: www.ucolick.org |             Don't Fear the Penguins                 :
:1024D/B9C9E76E           F892 5F17 8E0A F095 05CD  EE8B D169 EDAA B9C9 E76E:

Re: [python-sybase] python newbie seeks advice on sybase.py

[Dave C. <dj...@ob...>]

De> dear all: the Fearless (and Clueless) Python Newbie here trying to
De> understand the sybase module :-) Dave Cole very kindly helped me
De> to identify the source of the segv.  looks like libct is a bit
De> more temperamental than the libsybdb that I'm used to: it gets
De> upset if the locale in LANG envar isn't in locales.dat, in the
De> block for your OS.  segv seems like a rather extreme response to
De> this condition, but that's Sybase's problem :-)

We all just have to suffer :-)

De> am starting to get my bearings, have figured out where col
De> names/types are stashed (c.description) after execution of a
De> query.
De> 
De> but now am puzzled because I got a rowcount of -1 when I expected
De> to get a rowcount of <number of rows returned>.  here's the
De> braindead code.

As far as I know the row count is only available from the Sybase CT
library once all of the results have been consumed.  The relevant line
of code from Sybase.py is:

        status, self.rowcount = self._cmd.ct_res_info(CS_ROW_COUNT)

You could play around with this by moving the call to ct_res_info() to
different places in the code.  I seem to remember trying this without
success.  It would be nice to be able to have the row count
immediately though.

De>     c.execute('select * from numbers order by tablename')
De>     print c.description
De>     a = []
De>     for item in c.description:
De>         a.append(item[0])
De>     print "COL NAMES:",a
De>     print c.rowcount," ROWS"
De>     for row in c.fetchall():
De>         print row
De> 
De> python test.py
De> [('tablename', 0, 0, 30, 0, 0, 0), ('nserial', 8, 0, 4, 0, 0, 0), ('uid', 7, 0, 2, 0, 0, 32), ('stamp', 13, 0, 4, 0, 0, 32)]
De> COL NAMES: ['tablename', 'nserial', 'uid', 'stamp']
De> -1  ROWS
De> ('Agents', 200, 1, '25/07/96')
De> ('Alarms', 1, 1, '28/04/97')
De> ...
De> currentThread(): no current thread for 1024
De> 
De> why do I get -1 rows?  the dbapi doco says this value is -1 when
De> no command has been executed; but as you see, a SQL command has
De> been executed and rows are being returned.  am I missing
De> something?

If someone could work out how to get the row count before fetching the
results could they please tell me?  It also worried me when I wrote
the code.

De> also as you see I keep getting this "no current thread" message.
De> it seems harmless (like a bogus condition on image rundown) but I
De> wish I knew what it meant.

Copied and slightly edited from another message...:

Looks like my lock management code in the Cursor destructor is not
working.  This is something which drove me crazy - I could not
understand how else to solve the problem.

The TDS protocol does not allow multiple queries to be in flight over
the same connection.  To "hide" this limitation I lock the connection
whenever a cursor performs a query.  This allows you to share
connections between threads if you want to.  The __del__() method of
the cursor makes sure that it releases any lock it has on the
Connection object.

When a program terminates the Python interpreter deletes all objects
(calling the __del__() method if it is defined) which still exist.  I
discovered that the thread object in which a Connection lock was
created would sometimes be deleted before the cursor object which
still held a lock in that thread.  The code in the __del__() method
attempts to move the lock to the current thread so it can be unlocked.
It seems to be not working for you.

The error message should not be there.  It is either a bug in my code,
or a bug in the threading module which comes with the Python you are
running.  If I was to place a bet, I would say that the bug is in my
code.

- Dave

-- 
http://www.object-craft.com.au