python-sybase-misc

Re: [python-sybase] Problems running on Windows 2000

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

>>>>> "chris" == McCafferty, Chris <Chr...@Dr...> writes:

chris> Hi, I am encountering problems with sybase-0.35release that I
chris> probably ought to report.

chris> I install according to you instructions and the output seems ok
chris> (see below).  Unfortunately, when running through your example,
chris> python crashes at the point: db = Sybase.connect('DB_DEV',
chris> 'my_dbo', 'password') 'DB_DEV' is set up in my interfaces file,
chris> sybase.ini

chris> I get the error: python.exe - Application error The exception
chris> Priviledged instruction.  (0xc0000096) occurred in the
chris> application at location 0x0012ecc2

chris> Click on OK to terminate, etc.

Do you get the Cancel button which give you the opportunity to debug?

A stack trace would really help find this problem.

- Dave

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

[python-sybase] Problems running on Windows 2000

[McCafferty, C. <Chr...@Dr...>]

Hi,

I am encountering problems with sybase-0.35release that I probably ought to
report. 

I install according to you instructions and the output seems ok (see below).
Unfortunately, when running through your example, python crashes at the
point:
db = Sybase.connect('DB_DEV', 'my_dbo', 'password')
'DB_DEV' is set up in my interfaces file, sybase.ini

I get the error:
python.exe - Application error
The exception Priviledged instruction.
(0xc0000096) occurred in the application at location 0x0012ecc2

Click on OK to terminate, etc.

This error occurs regardless of which servername I put in.

System:
Windows 2000
Python 2.2 (#28, Dec 21 2001, 12:21:22)
MS Visual Studio 6.0

If it's worth upgrading python, let me know. If I should gather results
against the very lastest version let me know.

Once I get this working I should be able to get some results from Sybase 12
databases - in the meantime I'll try against 11.9.2 installations.

Cheers,

Chris


Log output when installing:
--------------------------

C:\installed\Python22\packages\sybase-0.35>setup.py install
running install
running build
running build_py
creating build
creating build\lib.win32-2.2
copying Sybase.py -> build\lib.win32-2.2
running build_ext
building 'sybasect' extension
creating build\temp.win32-2.2
creating build\temp.win32-2.2\Release
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcblk.c
/Fobuild\temp.win32-2.2\Release\blk.obj
blk.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcdatabuf.c
/Fobuild\temp.win32-2.2\Release\databuf.obj
databuf.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tccmd.c
/Fobuild\temp.win32-2.2\Release\cmd.obj
cmd.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcconn.c
/Fobuild\temp.win32-2.2\Release\conn.obj
conn.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcctx.c
/Fobuild\temp.win32-2.2\Release\ctx.obj
ctx.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcdatafmt.c
/Fobuild\temp.win32-2.2\Release\datafmt.obj
datafmt.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tciodesc.c
/Fobuild\temp.win32-2.2\Release\iodesc.obj
iodesc.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tclocale.c
/Fobuild\temp.win32-2.2\Release\locale.obj
locale.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcmsgs.c
/Fobuild\temp.win32-2.2\Release\msgs.obj
msgs.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcnumeric.c
/Fobuild\temp.win32-2.2\Release\numeric.obj
numeric.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcmoney.c
/Fobuild\temp.win32-2.2\Release\money.obj
money.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcdatetime.c
/Fobuild\temp.win32-2.2\Release\datetime.obj
datetime.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD
/W3 /GX -DWANT_BULKCOPY -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DR
OP -DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA -DHAVE_CT_SETPARAM
-DHAVE_CS
_CALC -DHAVE_CS_CMP -Ic:\installed\Sybase\include
-IC:\INSTAL~1\Python22\include /Tcsybasect.c
/Fobuild\temp.win32-2.2\Release\sybasect.obj
sybasect.c
C:\Program Files\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo
/INCREMENTAL:NO /LIBPATH:c:\installed\Sybase\lib
/LIBPATH:C:\INSTAL~1\Python22
\libs libblk.lib libct.lib libcs.lib /EXPORT:initsybasect
build\temp.win32-2.2\Release\blk.obj
build\temp.win32-2.2\Release\databuf.obj build\temp.win
32-2.2\Release\cmd.obj build\temp.win32-2.2\Release\conn.obj
build\temp.win32-2.2\Release\ctx.obj
build\temp.win32-2.2\Release\datafmt.obj build\temp.
win32-2.2\Release\iodesc.obj build\temp.win32-2.2\Release\locale.obj
build\temp.win32-2.2\Release\msgs.obj
build\temp.win32-2.2\Release\numeric.obj bu
ild\temp.win32-2.2\Release\money.obj
build\temp.win32-2.2\Release\datetime.obj
build\temp.win32-2.2\Release\sybasect.obj /OUT:build\lib.win32-2.2\syba
sect.pyd /IMPLIB:build\temp.win32-2.2\Release\sybasect.lib
   Creating library build\temp.win32-2.2\Release\sybasect.lib and object
build\temp.win32-2.2\Release\sybasect.exp
running install_lib
copying build\lib.win32-2.2\Sybase.py ->
C:\INSTAL~1\Python22\Lib\site-packages
copying build\lib.win32-2.2\sybasect.pyd ->
C:\INSTAL~1\Python22\Lib\site-packages
byte-compiling C:\INSTAL~1\Python22\Lib\site-packages\Sybase.py to
Sybase.pyc

C:\installed\Python22\packages\sybase-0.35>



----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail 
disclaimer statement and monitoring policy, please refer to 
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------

Re: [python-sybase] GPF in win 2000

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

>>>>> "Shai" == Shai Berger <Sha...@in...> writes:

Shai> I have failed to make myself clear: It flies. Python is aborted
Shai> because of a general protection fault. The "message" I was
Shai> talking about is the GPF-notification dialog window.  No
Shai> stack-trace for you today.

If you have the MSVC compiler installed it will give you the
opportunity to debug the program when it GP faults.  From within MSVC
you should be able to see the stack trace.

Without a stack trace almost impossible to know what has happened.

- Dave

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

Re: [python-sybase] Patch for compiling with FreeTDS current

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

>>>>> "hopfgartner" == hopfgartner  <hop...@ro...> writes:

hopfgartner> The following makes 2 changes in freetds.h: 1) The
hopfgartner> definition of CS_CLEAR is removed, since it's defined in
hopfgartner> the FreeTDS headers.

hopfgartner> 2) The prototype of ct_commant got a const qualifier.

hopfgartner> This enables compilation for FreeTDS current, as of
hopfgartner> November 28.

Thanks for that.

It would be a good thing if the FreeTDS tdsver.h included the version
number as a numeric value and changed it after an official release :-)

The CVS snapshot says that it is still v0.60...

#define TDS_VERSION_NO "freetds v0.60"

- Dave

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

Re: [python-sybase] Problems invoking stored procedures

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

>>>>> "hopfgartner" == hopfgartner  <hop...@ro...> writes:

>> You don't say whether or not you are using FreeTDS.  I also get
>> segfaults in FreeTDS 0.60 when I try to call stored procedures.  I
>> have not tried the current CVS version of FreeTDS.  Something to
>> try a bit later.
>> 
hopfgartner> Sorry, I've forgot to mention it. Indeed, I'm using
hopfgartner> FreeTDS 0.6.

That helps a bit.

>> Is it an error to have the stored procedure error message reported
>> as an exception?
>> 
hopfgartner> This should not be an error from the SQL server, but I
hopfgartner> will look closer to it. This is simply a message telling
hopfgartner> that there are no FK referencing this table. When running
hopfgartner> from Query Analyser, this message appears in the
hopfgartner> 'Messages' tab, wheras results are in the 'Grid' tab.

That raises the question of what I should do with messages from the
stored procedure.  Should I simply discard the messages?

hopfgartner> The same stored procedure does not give any error
hopfgartner> messages when run from Query Analyser.

It would be really helpful if you could send a fragment of SQL (no
matter how trivial) that I could run here to set up the exactly same
situation that you are seeing.

- Dave

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

RE: [python-sybase] GPF in win 2000

[<Sha...@in...>]

I have failed to make myself clear: It flies. Python is aborted because
of a general protection fault. The "message" I was talking about is the
GPF-notification dialog window.
No stack-trace for you today.

Have fun,
	Shai.


-----Original Message-----
From: Dave Cole [mailto:dj...@ob...]=20
Sent: Thursday, November 28, 2002 04:46
To: Berger, Shai
Cc: pyt...@ob...; sh...@pl...
Subject: Re: [python-sybase] GPF in win 2000


>>>>> "Shai" =3D=3D Shai Berger <Sha...@in...>=20
>>>>> writes:

Shai> Hi All, Wanted to let you know (couldn't find a bug database) that

Shai> when running the new 0.35 on Win 2000 Pro, with Sybase 12.0 and=20
Shai> Python 2.2.1, I get a GPF when I try to connect to the server (and

Shai> the message says something about a pointer to 0xffffffff which is=20
Shai> -1).  I tried 0.34, and it works fine.

Are you able to give us a stack trace?

- Dave

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

[python-sybase] Patch for compiling with FreeTDS current

[hopfgartner <hop...@ro...>]

The following makes 2 changes in freetds.h:

1) The definition of CS_CLEAR is removed, since it's
defined in the FreeTDS headers.

2) The prototype of ct_commant got a const qualifier.

This enables compilation for FreeTDS current, as of
November 28.

Peter

[python-sybase] Problems compiling with FreeTDS current

[hopfgartner <hop...@ro...>]

Dear David,

while trying to look at the issue of strored procedures, I
tried to compile with a current (downloaded today, 28
November) FreeTDS version.

FreeTDS was compiled with:
./configure --prefix=/usr/local/freetds --enable-msdblib
--enable-threadsafe --with-tdsver=8.0

Setting SYBASE:
export SYBASE=/usr/local/freetds

and trying to compile the Python Sybase Connector:
python2.3 setup.py build_ext -D HAVE_FREETDS -U
WANT_BULKCOPY

I get:

bonobo@bonobo:~/devel/sybase-0.36pre1$ python2.3 setup.py
build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
running build_ext
building 'sybasect' extension
creating build
creating build/temp.linux-i686-2.3
gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWANT_BULKCOPY -DHAVE_FREETDS=1 -UWANT_BULKCOPY
-I/usr/local/freetds/include -I/usr/include/python2.3 -c
iodesc.c -o build/temp.linux-i686-2.3/iodesc.o
In file included from sybasect.h:18,
                 from iodesc.c:9:
freetds.h:82:1: warning: "CS_CLEAR" redefined
In file included from sybasect.h:10,
                 from iodesc.c:9:
/usr/local/freetds/include/cspublic.h:417:1: warning: this
is the location of the previous definition
In file included from sybasect.h:18,
                 from iodesc.c:9:
freetds.h:114: conflicting types for `ct_command'
/usr/local/freetds/include/ctpublic.h:43: previous
declaration of `ct_command'
error: command 'gcc-3.2' failed with exit status 1


I will still try with other options and let you know.

Thank you for your attention,

Peter

Re: [python-sybase] Problems invoking stored procedures

[hopfgartner <hop...@ro...>]

On 28 Nov 2002 13:42:01 +1100
 Dave Cole <dj...@ob...> wrote:
> 
> > Hello, since we are suning SQL Server 2000 the whole
> day I'm working
> > on some tools that should help us to:
> > 
> > 1) get quickly all objects as text files in DDL, that
> can be
> > processed by CVS
> > 
> > 2) export the database schme to DIA.
> > 
> > 3) eventually help porting the objects to SQL:1999 or
> PostgreSQL
> > 
> > Many things work now, but when I try to run a stored
> procedure,
> > sp_helpconstraint, I get a lot of problems.
> > 
> > The system I'm working on is:
> > 
> > Server:
> >     Windows 2000 SP2
> >     SQL Server 2000 SP2
> > 
> > Client:
> >     Debian testing
> >     Python 2.1.2 and Python 2.3 pre-packages
> >     sybase-3.6pre1
> > 
> > The problem is included in the 2 attachments. They
> contain 2
> > different invokations of the the stored procedure.
> 
> You don't say whether or not you are using FreeTDS.  I
> also get
> segfaults in FreeTDS 0.60 when I try to call stored
> procedures.  I
> have not tried the current CVS version of FreeTDS.
>  Something to try a
> bit later.
> 
Sorry, I've forgot to mention it. Indeed, I'm using FreeTDS
0.6. 

> > The first test gives me:
> > 
> > bonobo@bonobo:~/devel/dbweaver$ python spTest.py
> > [('DEFAULT on column alrm_time', 'DF_Alarme_Time',
> '(n/a)',
> > '(n/a)', '(n/a)', '(n/a)', '(getdate())'), ('PRIMARY
> KEY
> > (non-clustered)', 'PK_Alarme', '(n/a)', '(n/a)',
> '(n/a)',
> > '(n/a)', 'alrm_id')]
> > Traceback (most recent call last):
> >   File "spTest.py", line 8, in ?
> >     curs.close()
> >   File "/usr/lib/python2.1/site-packages/Sybase.py",
> line
> > 350, in close
> >     self._close()
> >   File "/usr/lib/python2.1/site-packages/Sybase.py",
> line
> > 262, in _close
> >     status = self._cmd.ct_cancel(CS_CANCEL_ALL)
> >   File "/usr/lib/python2.1/site-packages/Sybase.py",
> line
> > 145, in _servermsg_cb
> >     raise DatabaseError(_fmt_server(msg))
> > Sybase.DatabaseError: State 1, Procedure
> sp_helpconstraint,
> > Line 276
> >  Msg 15470, State 1, Procedure sp_helpconstraint, Line
> 287
> > No foreign keys reference this table.
> 
> Is it an error to have the stored procedure error message
> reported as
> an exception?
> 
This should not be an error from the SQL server, but I will
look closer to it. This is simply a message telling that
there are no FK referencing this table. When running from
Query Analyser, this message appears in the 'Messages' tab,
wheras results are in the 'Grid' tab.

Anyway, I've tryed it with a table that has FK-constraints,
and what I get is the following:

bonobo@bonobo:~/devel/dbweaver$ python spTest.py
[('DEFAULT on column PAPOS', 'DF_positionen_PAPOS',
'(n/a)', '(n/a)', '(n/a)', '(n/a)', '(0)'), ('DEFAULT on
column PARTI', 'DF_positionen_PARTI', '(n/a)', '(n/a)',
'(n/a)', '(n/a)', "(' ')"), ('DEFAULT on column
pos_menge_ist', 'DF_positionen_pos_menge_ist', '(n/a)',
'(n/a)', '(n/a)', '(n/a)', '(0)'), ('DEFAULT on column
pos_status', 'DF_positionen_pos_status', '(n/a)', '(n/a)',
'(n/a)', '(n/a)', '(30)'), ('FOREIGN KEY',
'FK_positionen_personal', 'No Action', 'No Action',
'Enabled', 'Is_For_Replication', 'pers_id'), (' ', ' ', '
', ' ', ' ', ' ', 'REFERENCES lager01_sap.dbo.personal
(pers_id)'), ('FOREIGN KEY',
'FK_positionen_transport_auftraege', 'No Action', 'No
Action', 'Enabled', 'Is_For_Replication', 'taft_id'), (' ',
' ', ' ', ' ', ' ', ' ', 'REFERENCES
lager01_sap.dbo.transport_auftraege (taft_id)'), ('PRIMARY
KEY (clustered)', 'PK_Positionen', '(n/a)', '(n/a)',
'(n/a)', '(n/a)', 'pos_id')]
Traceback (most recent call last):
  File "spTest.py", line 8, in ?
    curs.close()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
350, in close
    self._close()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
262, in _close
    status = self._cmd.ct_cancel(CS_CANCEL_ALL)
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
145, in _servermsg_cb
    raise DatabaseError(_fmt_server(msg))
Sybase.DatabaseError: State 1, Procedure sp_helpconstraint,
Line 276
 
The same stored procedure does not give any error messages
when run from Query Analyser.

> > The second gives simply:
> > 
> > bonobo@bonobo:~/devel/dbweaver$ python spTest2.py
> > Segmentation fault
> 
> This is exactly what I get with FreeTDS.
> 
> - Dave
> 
> -- 
> http://www.object-craft.com.au
> 

Let me know if I can help in the diagnosis. 

Peter

Re: [python-sybase] GPF in win 2000

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

>>>>> "Shai" == Shai Berger <Sha...@in...> writes:

Shai> Hi All, Wanted to let you know (couldn't find a bug database)
Shai> that when running the new 0.35 on Win 2000 Pro, with Sybase 12.0
Shai> and Python 2.2.1, I get a GPF when I try to connect to the
Shai> server (and the message says something about a pointer to
Shai> 0xffffffff which is -1).  I tried 0.34, and it works fine.

Are you able to give us a stack trace?

- Dave

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

Re: [python-sybase] Problems invoking stored procedures

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

> Hello, since we are suning SQL Server 2000 the whole day I'm working
> on some tools that should help us to:
> 
> 1) get quickly all objects as text files in DDL, that can be
> processed by CVS
> 
> 2) export the database schme to DIA.
> 
> 3) eventually help porting the objects to SQL:1999 or PostgreSQL
> 
> Many things work now, but when I try to run a stored procedure,
> sp_helpconstraint, I get a lot of problems.
> 
> The system I'm working on is:
> 
> Server:
>     Windows 2000 SP2
>     SQL Server 2000 SP2
> 
> Client:
>     Debian testing
>     Python 2.1.2 and Python 2.3 pre-packages
>     sybase-3.6pre1
> 
> The problem is included in the 2 attachments. They contain 2
> different invokations of the the stored procedure.

You don't say whether or not you are using FreeTDS.  I also get
segfaults in FreeTDS 0.60 when I try to call stored procedures.  I
have not tried the current CVS version of FreeTDS.  Something to try a
bit later.

> The first test gives me:
> 
> bonobo@bonobo:~/devel/dbweaver$ python spTest.py
> [('DEFAULT on column alrm_time', 'DF_Alarme_Time', '(n/a)',
> '(n/a)', '(n/a)', '(n/a)', '(getdate())'), ('PRIMARY KEY
> (non-clustered)', 'PK_Alarme', '(n/a)', '(n/a)', '(n/a)',
> '(n/a)', 'alrm_id')]
> Traceback (most recent call last):
>   File "spTest.py", line 8, in ?
>     curs.close()
>   File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 350, in close
>     self._close()
>   File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 262, in _close
>     status = self._cmd.ct_cancel(CS_CANCEL_ALL)
>   File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 145, in _servermsg_cb
>     raise DatabaseError(_fmt_server(msg))
> Sybase.DatabaseError: State 1, Procedure sp_helpconstraint,
> Line 276
>  Msg 15470, State 1, Procedure sp_helpconstraint, Line 287
> No foreign keys reference this table.

Is it an error to have the stored procedure error message reported as
an exception?

> The second gives simply:
> 
> bonobo@bonobo:~/devel/dbweaver$ python spTest2.py
> Segmentation fault

This is exactly what I get with FreeTDS.

- Dave

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

[python-sybase] GPF in win 2000

[<Sha...@in...>]

Hi All,

Wanted to let you know (couldn't find a bug database) that when running
the new 0.35 on Win 2000 Pro, with Sybase 12.0 and Python 2.2.1, I get a
GPF when I try to connect to the server (and the message says something
about a pointer to 0xffffffff which is -1). I tried 0.34, and it works
fine.

Have fun,
	Shai.

[python-sybase] Problems invoking stored procedures

[hopfgartner <hop...@ro...>]

Hello,

since we are suning SQL Server 2000 the whole day I'm
working on some tools that should help us to:

1) get quickly all objects as text files in DDL, that can
be processed by CVS

2) export the database schme to DIA.

3) eventually help porting the objects to SQL:1999 or
PostgreSQL

Many things work now, but when I try to run a stored
procedure, sp_helpconstraint, I get a lot of problems.

The system I'm working on is:

Server:
    Windows 2000 SP2
    SQL Server 2000 SP2

Client:
    Debian testing
    Python 2.1.2 and Python 2.3 pre-packages
    sybase-3.6pre1

The problem is included in the 2 attachments. They contain
2 different invokations of the the stored procedure.

The first test gives me:

bonobo@bonobo:~/devel/dbweaver$ python spTest.py
[('DEFAULT on column alrm_time', 'DF_Alarme_Time', '(n/a)',
'(n/a)', '(n/a)', '(n/a)', '(getdate())'), ('PRIMARY KEY
(non-clustered)', 'PK_Alarme', '(n/a)', '(n/a)', '(n/a)',
'(n/a)', 'alrm_id')]
Traceback (most recent call last):
  File "spTest.py", line 8, in ?
    curs.close()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
350, in close
    self._close()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
262, in _close
    status = self._cmd.ct_cancel(CS_CANCEL_ALL)
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
145, in _servermsg_cb
    raise DatabaseError(_fmt_server(msg))
Sybase.DatabaseError: State 1, Procedure sp_helpconstraint,
Line 276
 Msg 15470, State 1, Procedure sp_helpconstraint, Line 287
No foreign keys reference this table.

The second gives simply:

bonobo@bonobo:~/devel/dbweaver$ python spTest2.py
Segmentation fault


Could somebody help me?

Thank you very much for your attention.

Peter Hopfgartner

[python-sybase] Sybase module 0.35 released

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

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

NOTES:

In this release the module uses callback instead of inline error
handling from the Sybase CT library.  This has caused quite extensive
changes to the threading support inside the low level extension
module.

One of the nice side effects of using callback error handling is that
server errors while executing stored procedures will now be reported
correctly.

FreeTDS support is much improved in this version.

You can build for FreeTDS like this:

     python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
     python setup.py install

The module is available here:

    http://www.object-craft.com.au/projects/sybase/download/sybase-0.35.tar.gz

The module home page is here:

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

CHANGES SINCE 0.35pre3:

No problems were reported with the 0.35pre3 release so the changes are
minimal.

* sybasect extension module now includes a __version__ string.

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

[python-sybase] Sybase module 0.35pre3 released

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

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

This release corrects a mistake I made in packaging the 0.35pre2 release.

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

CHANGES SINCE 0.35pre2:

* Fixed the MANIFEST.in file to include freetds.h and sybasect.h.

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

[python-sybase] Sybase module 0.35pre2 released

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

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

NOTES:

In this release the module uses callback instead of inline error
handling from the Sybase CT library.  This has caused quite extensive
changes to the threading support inside the low level extension
module.

One of the nice side effects of using callback error handling is that
server errors while executing stored procedures will now be reported
correctly.

FreeTDS support is much improved in this version.

You can build for FreeTDS like this:

     python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
     python setup.py install

The module is available here:

    http://www.object-craft.com.au/projects/sybase/download/sybase-0.35pre2.tar.gz

The module home page is here:

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

CHANGES SINCE 0.35pre1:

* Changed ignored server messages to (5701, 5703).  Thanks to Kevin
  Jacobs.

* Allocate a new CS_COMMAND for each command executed on a cursor.
  This behaves like an explicit close() on the cursor in between
  commands.  This makes it possible to perform multiple .execute()
  commands on a cursor with FreeTDS.

* Added array binding to cursor to gain extra performance.  Set the
  arraysize cursor attribute before executing a command.

* Made connection locking optional.  Sybase.connect(..., locking = 0)

* Native DateTime types now has separate str() and repr().  print
  used to display "'11/01/63'".

ARRAY BINDING:

The following is a little test program to see the performance effect
of array binding in the .fetchmany() cursor method.

It looks like the speed was mostly going in function calls due to
locking and single row fetching.

run             locking array functions time (ave 10 runs)
test-array l          Y     N     88586 1.3248 secs
test-array            N     N     20450 0.9803 secs
test-array al         Y     Y      9458 0.5188 secs
test-array a          N     Y      7262 0.5002 secs

- - test-array.py - - - - - - - - - - - - - - - - - - - - - - - -
import sys, Sybase

def array_bind():
    db = Sybase.connect('SYBASE', 'sa', '', 'sybsystemprocs',
                        locking = do_locking)
    c = db.cursor()
    c.arraysize = 32
    c.execute('select text from syscomments')
    num_rows = 0
    while 1:
        rows = c.fetchmany()
        if not rows:
            break
        num_rows += len(rows)
    print num_rows, 'rows'

def single_bind():
    db = Sybase.connect('SYBASE', 'sa', '', 'sybsystemprocs',
                        locking = do_locking)
    c = db.cursor()
    c.execute('select text from syscomments')
    num_rows = 0
    while 1:
        row = c.fetchone()
        if not row:
            break
        num_rows += 1
    print num_rows, 'rows'

def main():
    if do_array:
        array_bind()
    else:
        single_bind()

do_profile = len(sys.argv) > 1 and sys.argv[1].find('p') >= 0
do_locking = len(sys.argv) > 1 and sys.argv[1].find('l') >= 0
do_array = len(sys.argv) > 1 and sys.argv[1].find('a') >= 0

if do_profile:
    import profile
    profile.run('main()')
else:
    main()
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

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

[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] 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] 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:

[python-sybase] Re: FW: Is Python Sybase module slow compared to Perl DBI?

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

chuck> Oops...accidentially hit the send button.  For a single table:
chuck> 
chuck> time (secs)  type/settings
chuck> -----------  ---------------------------------------------------
chuck>         160  Perl DBI
chuck>         320  sybase-0.34
chuck>         340  sybase-0.35pre2, fetchone
chuck>         265  sybase-0.35pre2, fetchone, locking=0
chuck>         153  sybase-0.35pre2, fetchmany, arraysize=32
chuck>         151  sybase-0.35pre2, fetchmany, arraysize=32, locking=0
chuck>         150  sybase-0.35pre2, fetchmany, arraysize=64
chuck>         150  sybase-0.35pre2, fetchmany, arraysize=64, locking=0
chuck>         155  sybase-0.35pre2, fetchmany, arraysize=128
chuck>         153  sybase-0.35pre2, fetchmany, arraysize=128, locking=0
chuck> 
chuck> The wierd thing also it that the locking doesn't seem to affect
chuck> the run once I started using the fetchmany.  Here is the new
chuck> source code I used:
chuck> 
chuck>         db = Sybase.connect(server, user, password, database) #, locking
chuck> = 0)
chuck> 
chuck>         # output the actual data
chuck>         c = db.cursor()
chuck>         c.arraysize = 64
chuck>         c.execute("SELECT %s FROM %s" % (select, table))
chuck>     
chuck>         num_recs = 0
chuck>         if os.path.isfile("%s.gz" % dumpfile):
chuck>             os.remove("%s.gz" % dumpfile)
chuck>         file = os.popen("gzip -c > %s.gz" % dumpfile, "w")
chuck>         while 1:
chuck>             rows = c.fetchmany()
chuck>             if not rows : break
chuck>     
chuck>             for row in rows:
chuck>                 line = []
chuck>                 for i in range(len(row)):
chuck>                     line.append("%-*s" % (lengths[i], row[i]))
chuck>                 print >> file, "".join(line)
chuck>                 num_recs += 1
chuck> 
chuck>         file.close()
chuck>         c.close()
chuck> 
chuck> What is the locking doing?  It is internal Python thread
chuck> locking, or is it Sybase locking?

The locking allows you to share database connections between Python
threads.  It is implemented in the Sybase.py code - by turning it off
you disable all of the associated function calls to the standard
Python threading module.

If you look closer at Sybase.py and read the sybasect documentation
you will see that the low level module also implements locking for
multiple threaded programs.  This is disabled in Sybase.py by the call
_ctx.ct_con_alloc(0) (the 0 turns off locking).  In sybasect I have
implemented (I think) all of the documented rules for multi-threaded
access to the Sybase CT library.  Since the connection level locks in
Sybase.py are much more coarse I turn off the fine grained locking in
the low level module.  The low level module can be used in a
standalone fashion - Sybase.py is just one example of how you can use
sybasect.so.

The reason for the locking in Sybase.py is that a database connection
is implemented (in Sybase) via a TCP socket which talks the TDS
(Tabular Data Stream (I think)) protocol.  TDS only supports a single
result set at a time over the socket - this represents a "small"
problem when you might want to have multiple cursors in your
multi-threaded program using the same connection...

So, what the Sybase.py locking code does is place a lock on the
connection when you do a Cursor.execute() or Cursor.callproc() then
releases the lock once the results have either been fetched or
cancelled.  This makes the single result set limitation mostly
invisible to your Python code.

If you are not using threads in your application you may as well pass
locking = 0 to the Sybase.connect() function.

chuck> Thanks again for the help.  I'd say that Python and Perl are
chuck> effectively now running at the same speed!

That is absolutely awesome!!!  I have made some more slight changes
which sped my test program up by another 10%.  I a version of the
changes I made to the python-sybase mailing list (minus the further
10% speedup):

     http://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase

If I do not get any reports of problems in the next week I am going to
make a new release.  Mind you I still have not had any report of
success as yet (excluding yours of course)...

Thank you very much for helping out.

- Dave

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

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

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

>>>>> "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

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[hopfgartner <hop...@ro...>]

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 

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[Kevin J. <ja...@pe...>]

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

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[Harri P. <har...@tr...>]

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