Menu
▾
▴
python-sybase-misc
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
(26) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
(6) |
Nov
(14) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(31) |
Feb
(15) |
Mar
(6) |
Apr
(18) |
May
(11) |
Jun
(3) |
Jul
(7) |
Aug
(5) |
Sep
(6) |
Oct
(1) |
Nov
(2) |
Dec
(6) |
| 2004 |
Jan
(3) |
Feb
(3) |
Mar
(18) |
Apr
(4) |
May
(13) |
Jun
(32) |
Jul
(21) |
Aug
(22) |
Sep
(11) |
Oct
(2) |
Nov
(6) |
Dec
(5) |
| 2005 |
Jan
(4) |
Feb
(16) |
Mar
(21) |
Apr
(10) |
May
(1) |
Jun
(5) |
Jul
(3) |
Aug
(3) |
Sep
(13) |
Oct
(15) |
Nov
(20) |
Dec
|
| 2006 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(4) |
Jun
(6) |
Jul
(23) |
Aug
(6) |
Sep
(5) |
Oct
(8) |
Nov
|
Dec
(12) |
| 2007 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(6) |
Aug
(5) |
Sep
(3) |
Oct
|
Nov
(5) |
Dec
(6) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(3) |
May
|
Jun
(12) |
Jul
|
Aug
(1) |
Sep
|
Oct
(7) |
Nov
(1) |
Dec
(4) |
| 2009 |
Jan
|
Feb
(2) |
Mar
(16) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(21) |
Sep
(11) |
Oct
(4) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
(9) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marcos P. <msa...@gr...> - 2003-02-19 07:59:17
|
Hello
What is the current status regarding parameter passing with
freetds/MSSQL2000? I get an error if I try simple queries.
import Sybase as dbapi
con=3Ddbapi.connect('cazalla','gotta','password','personal')
cur=3Dcon.cursor()
cur.execute('select * from usuarios where cd_usuario=3D@u', =20
{'@u':'marcos'})
pprint.pprint(cur.fetchall())
This is what I get (line numbers are incorrect)
Traceback (most recent call last):
File "etcPythonSybase.py", line 191, in ?
cur.execute('select * from usuarios where
cd_usuario=3D@u',{'@u':'marcos'})
File "/usr/lib/python2.2/site-packages/Sybase.py", line 379, in
execute
self._raise_error(Error, 'ct_param')
File "/usr/lib/python2.2/site-packages/Sybase.py", line 309, in
_raise_error
raise exc(text)
Sybase.Error: ct_param
--=20
gpg --recv-keys --keyserver wwwkeys.pgp.net B9AD9B1B
|
|
From: Dave C. <dj...@ob...> - 2003-02-19 07:34:49
|
> Question regarding error handling when using stored procedures. If I
> have a procedure usp_delete_database_data which takes 3 parameters
> @dbID int, @error_no int output and @error_desc varchar(255) output,
> and I call this procedure using something as follows:
> try:
> varTest =
> c.callproc('usp_delete_database_data',{'@dbID':varDBID,'@error_no':varErrorNo,'@error_desc':varErrorDesc})
> except Sybase.DatabaseError:
> print "Unable to delete database data for database_id"
> else:
> print "Success"
>
> Is there any way to capture the error_no and error_desc return
> variables? If I simply call the procedure using c.callproc outside
> of a try block and an SQL error occurs within the procedure, Python
> raises the Sybase.DatabaseError and the script blows up. When inside
> the try block the varErrorNo and varErrorDesc are not populated. I'm
> assuming this is because the c.callproc() doesn't really run
> successfully because of the Sybase.DatabaseError that is occurring?
> The procedure error that I am testing is a simple 2601 duplicate key
> insert error. I need the c.callproc() to run successfully and then
> be able to capture the error_no and error_desc outputs. Perhaps I'm
> missing something? Thanks
It is possible to retrieve the named arguments in the lower level
extension module. Look at the rpc.py/rpc.sql in the examples
subdirectory.
Problem is that you need to set the status of the return CS_DATAFMT
(via DataBuf) to CS_RETURN otherwise the CT library does not know you
want to receive output parameters in the buffer. If there was a nice
way to work out which of the parameters you passed in your Python are
for output then it should be possible to handle the above code.
A while ago I tried setting CS_RETURN in the status of all parameter
values in the Cursor.callproc() method. I seem to remember it didn't
work. I should five it another try.
Note that the rpc.py only seems to work for Sybase client libraries.
FreeTDS still seems to have problems.
- Dave
--
http://www.object-craft.com.au
|
|
From: Dave C. <dj...@ob...> - 2003-02-18 23:47:18
|
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:
This is another incremental improvement to FreeTDS support.
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.36pre4.tar.gz
The module home page is here:
http://www.object-craft.com.au/projects/sybase/
CHANGES SINCE 0.36pre3:
* Fixed cursor locking bug with .nextset() method.
* Added .debug_msg() method to context type which writes to the debug
log when debugging is enabled for the context object.
* Merged AIX build changes from Dietmar Rothkamp.
* Now compiles with FreeTDS 0.61.
* Limit size of TEXT fields to 65536.
CHANGES SINCE 0.35
* Removed references to CS_PENDING and CS_BUSY in Sybase.py.
* Bind CS_VARBINARY_TYPE as CS_BINARY_TYPE.
* Do not attempt to ct_cancel() when handling an exception if have not
connected to the server. Bug fix in Sybase.py.
* Seems like FreeTDS reports the wrong maxlength in ct_describe() for
CS_NUMERIC_TYPE and CS_DECIMAL_TYPE. Ignore FreeTDS and assume a
maxlength of sizeof(CS_NUMERIC). Bugfix in databuf.c.
* Use correct T_STRING_INPLACE type in structure member descriptions.
The code does not use Python API for these members.
* Debug output for DataFmt now includes scale and precision.
* More definitions added to freetds.h; CS_SRC_VALUE, CS_CLEAR.
--
http://www.object-craft.com.au
|
|
From: <Sha...@in...> - 2003-02-04 12:49:11
|
Hi, Are you aware of the Zope Sybase DA = (http://www.zope.org/Products/DA/SybaseDA)? Is there a reason why you aren't using it? Zope has a rich machinery for dealing with SQL databases. It is not = perfect, but usually solves more problems than it raises. By using an external = function, you give up all that machinery. I don't know -- it may, or may not, be a good idea to rewrite the Sybase = adapter with the Sybase module; however, for practical reasons, it's available. (and, perhaps, it is a good idea for sybasect to compare notes with the = extension module underlying this DA, sy_occ). Disclaimer: I am not related to the SybaseDA, and I haven't even tried = it. I just found out about it when I ran a search in Zope.org. Have fun, Shai. -----Original Message----- From: Sebastien MICHEL [mailto:seb...@db...]=20 Sent: Monday, February 03, 2003 19:23 To: pyt...@ob... Subject: [python-sybase] Simultaneous request Hi, =A0 =A0 =A0 =A0 i've installed python-sybase 0.35 according to INSTALL = file. Everything is ok, I got sybasect.so compiled. =A0 =A0 =A0 =A0 When I make some connections to database, everythin is = right. But i'm using this module which is called as an external Method = by Zope and if more than 2 connections occured on the same time, it = crahsed. Any idea ? Blow the external method : import sys from string import replace, strip from sybasect import * from sybase_errors import * MAX_COLSIZE =3D 255 def init_db(): =A0 =A0 # allocate a context =A0 =A0 status, ctx =3D cs_ctx_alloc(CS_VERSION_100) =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise Error('cs_ctx_alloc failed') =A0 =A0 if ctx.cs_diag(CS_INIT) !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise CSError(ctx, 'cs_diag failed') =A0 =A0 # initialize the library =A0 =A0 if ctx.ct_init(CS_VERSION_100) !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise CSError(ctx, 'ct_init failed') =A0 =A0 return ctx def connect_db(ctx, server, user_name, password): =A0 =A0 # Allocate a connection pointer =A0 =A0 status, con =3D ctx.ct_con_alloc() =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise CSError(ctx, 'ct_con_alloc failed') =A0 =A0 if con.ct_diag(CS_INIT) !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise CTError(con, 'ct_diag failed') =A0 =A0 # Set the username and password properties =A0 =A0 if con.ct_con_props(CS_SET, CS_USERNAME, user_name) !=3D = CS_SUCCEED: =A0 =A0 =A0 =A0 raise CTError(con, 'ct_con_props CS_USERNAME failed') =A0 =A0 if con.ct_con_props(CS_SET, CS_PASSWORD, password) !=3D = CS_SUCCEED: =A0 =A0 =A0 =A0 raise CTError(con, 'ct_con_props CS_PASSWORD failed') =A0 =A0 # connect to the server =A0 =A0 if con.ct_connect(server) !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 raise CTError(con, 'ct_connect failed') =A0 =A0 return con def bind_columns(cmd): =A0 =A0 =A0 =A0 status, num_cols =3D cmd.ct_res_info(CS_NUMDATA) =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.con, 'ct_res_info = failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return bufs =A0 =A0 =A0 =A0 bufs =3D [None] * num_cols =A0 =A0 =A0 =A0 for i in range(num_cols): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt =3D CS_DATAFMT() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.datatype =3D CS_CHAR_TYPE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.maxlength =3D MAX_COLSIZE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.count =3D 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.format =3D CS_FMT_NULLTERM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Bind returned data to host variables =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, buf =3D cmd.ct_bind(i + 1, fmt) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return bufs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs[i] =3D buf =A0 =A0 =A0 =A0 return bufs def fetch(cmd, bufs, results): =A0 =A0 =A0 =A0 status, num_cols =3D cmd.ct_res_info(CS_NUMDATA) =A0 =A0 =A0 =A0 if status =3D=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Fetch the bound data into host = variables =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while 1: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, rows_read =3D = cmd.ct_fetch() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 row =3D [] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status not in = (CS_SUCCEED, CS_ROW_FAIL): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status =3D=3D = CS_ROW_FAIL: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for i in = range(num_cols): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if = bufs[i][0] =3D=3D None: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 row.append('') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 row.append(strip(replace(bufs[i][0],'\000',''))) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 results.append(row) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_END_DATA: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, = 'ct_fetch failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, 'ct_res_info = failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass def handle_returns(cmd, retcode, outputs, rows): =A0 =A0 =A0 =A0 # Process all returned result types =A0 =A0 =A0 =A0 sql_status =3D CS_SUCCEED =A0 =A0 =A0 =A0 while 1: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, result =3D cmd.ct_results() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if result =3D=3D CS_ROW_RESULT: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D = bind_columns(cmd) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, rows) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_DONE: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_FAIL: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, = 'ct_results: CS_CMD_FAIL') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_status =3D CS_FAIL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_PARAM_RESULT: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D = bind_columns(cmd) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, = outputs) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_STATUS_RESULT: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D = bind_columns(cmd) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, = retcode) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_COMPUTE_RESULT: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break =A0 =A0 =A0 =A0 if status !=3D CS_END_RESULTS: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, 'ct_results = failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_FAIL =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if sql_status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_FAIL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_SUCCEED def cleanup_db(ctx,status): =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exit_type =3D CS_FORCE_EXIT =A0 =A0 =A0 =A0 else: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exit_type =3D CS_UNUSED =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # close and cleanup connection to the = server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ctx.ct_exit(exit_type) !=3D = CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CSError(ctx, = 'ct_exit failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # drop the context =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ctx.cs_ctx_drop() !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CSError(ctx, = 'cs_ctx_drop failed') class SybaseSQL: =A0 =A0 =A0 =A0 """Execute a stored procedure on a Sybase server""" =A0 =A0 =A0 =A0 def __init__(self, server, user, password, = sql_statement): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = self.__allow_access_to_unprotected_subobjects__ =3D 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.retcode =3D [] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.outputs =3D [] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.rows =3D [] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a context and initialize = client-library =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctx =3D init_db() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a command structure =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con =3D connect_db(ctx, server, user, = password) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a command structure =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, cmd =3D con.ct_cmd_alloc() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CTError(con, = 'ct_cmd_alloc failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Send the command to the server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_command(CS_LANG_CMD, = sql_statement) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D = CTError(cmd.con, 'ct_command failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Execute SQL statement on the server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_send() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D = CTError(cmd.con, 'ct_send failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Process results from the server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D handle_returns(cmd, = self.retcode, self.outputs, self.rows) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise = CTError(con,'handle_returns failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Drop the command structure =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_cmd_drop() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D = =A0CTError(con, 'ct_cmd_drop failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Close the connection to the server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D con.ct_close() =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D = =A0CTError(con, 'ct_close failed') =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Drop the context and do general = cleanup =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status) =A0 =A0 =A0 =A0 def ReturnCode(self): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the code of the procedure""" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.retcode =A0 =A0 =A0 =A0 def Outputs(self): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the output parameters""" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.outputs =A0 =A0 =A0 =A0 def Rows(self): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the rows""" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.rows def execSybaseSQL(server, user, password, sql_statement): =A0 =A0 =A0 =A0 """Init a Sybase RPC object""" =A0 =A0 =A0 =A0 return SybaseSQL(server, user, password, sql_statement) if __name__ =3D=3D "__main__": =A0 =A0 =A0 =A0 Request =3D execSybaseSQL("ds_teddy_uat", "michse", = "smhuat01","select * from TEDDY_USERS") =A0 =A0 =A0 =A0 print Request.ReturnCode() =A0 =A0 =A0 =A0 print Request.Outputs() =A0 =A0 =A0 =A0 print Request.Rows() Sebastien. Sebastien Michel Front Office Technology +33 1 44 95 62 89 3, avenue de Friedland 75008 Paris -- This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in = error) please notify the sender immediately and destroy this e-mail. Any = unauthorized copying, disclosure or distribution of the material in this = e-mail is strictly forbidden. _______________________________________________ Python-sybase mailing list Pyt...@ob... https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase |
|
From: Sebastien M. <seb...@db...> - 2003-02-04 12:23:31
|
Hi,
=A0 =A0 =A0 =A0 i've installed python-sybase 0.35 according to INSTALL =
file. Everything is ok, I got sybasect.so compiled.
=A0 =A0 =A0 =A0 When I make some connections to database, everythin is =
right. But i'm using this module which is called as an external Method =
by Zope and if more than 2 connections occured on the same time, it cra=
hsed. Any idea ?
Blow the external method :
import sys
from string import replace, strip
from sybasect import *
from sybase_errors import *
MAX_COLSIZE =3D 255
def init_db():
=A0 =A0 # allocate a context
=A0 =A0 status, ctx =3D cs_ctx_alloc(CS_VERSION_100)
=A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise Error('cs_ctx_alloc failed')
=A0 =A0 if ctx.cs_diag(CS_INIT) !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise CSError(ctx, 'cs_diag failed')
=A0 =A0 # initialize the library
=A0 =A0 if ctx.ct_init(CS_VERSION_100) !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise CSError(ctx, 'ct_init failed')
=A0 =A0 return ctx
def connect_db(ctx, server, user_name, password):
=A0 =A0 # Allocate a connection pointer
=A0 =A0 status, con =3D ctx.ct_con_alloc()
=A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise CSError(ctx, 'ct_con_alloc failed')
=A0 =A0 if con.ct_diag(CS_INIT) !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise CTError(con, 'ct_diag failed')
=A0 =A0 # Set the username and password properties
=A0 =A0 if con.ct_con_props(CS_SET, CS_USERNAME, user_name) !=3D CS_SUC=
CEED:
=A0 =A0 =A0 =A0 raise CTError(con, 'ct_con_props CS_USERNAME failed')
=A0 =A0 if con.ct_con_props(CS_SET, CS_PASSWORD, password) !=3D CS_SUCC=
EED:
=A0 =A0 =A0 =A0 raise CTError(con, 'ct_con_props CS_PASSWORD failed')
=A0 =A0 # connect to the server
=A0 =A0 if con.ct_connect(server) !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 raise CTError(con, 'ct_connect failed')
=A0 =A0 return con
def bind_columns(cmd):
=A0 =A0 =A0 =A0 status, num_cols =3D cmd.ct_res_info(CS_NUMDATA)
=A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.con, 'ct_res_info fa=
iled')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return bufs
=A0 =A0 =A0 =A0 bufs =3D [None] * num_cols
=A0 =A0 =A0 =A0 for i in range(num_cols):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt =3D CS_DATAFMT()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.datatype =3D CS_CHAR_TYPE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.maxlength =3D MAX_COLSIZE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.count =3D 1
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmt.format =3D CS_FMT_NULLTERM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Bind returned data to host variables
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, buf =3D cmd.ct_bind(i + 1, fmt)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return bufs
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs[i] =3D buf
=A0 =A0 =A0 =A0 return bufs
def fetch(cmd, bufs, results):
=A0 =A0 =A0 =A0 status, num_cols =3D cmd.ct_res_info(CS_NUMDATA)
=A0 =A0 =A0 =A0 if status =3D=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Fetch the bound data into host variab=
les
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while 1:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, rows_read =3D c=
md.ct_fetch()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 row =3D []
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status not in (CS_SU=
CCEED, CS_ROW_FAIL):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status =3D=3D CS_ROW=
_FAIL:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continu=
e
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for i in range(num_cols=
):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if bufs=
[i][0] =3D=3D None:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 row.append('')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 row.append(strip(replace(bufs[i][0],'\000','')))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 results.append(row)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_END_DATA:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn=
, 'ct_fetch failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass
=A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, 'ct_res_info f=
ailed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass
def handle_returns(cmd, retcode, outputs, rows):
=A0 =A0 =A0 =A0 # Process all returned result types
=A0 =A0 =A0 =A0 sql_status =3D CS_SUCCEED
=A0 =A0 =A0 =A0 while 1:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, result =3D cmd.ct_results()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if result =3D=3D CS_ROW_RESULT:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D bind_columns(c=
md)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, rows)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_DONE:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_CMD_FAIL:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn=
, 'ct_results: CS_CMD_FAIL')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_status =3D CS_FAIL
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_PARAM_RESULT:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D bind_columns(c=
md)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, output=
s)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_STATUS_RESULT:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufs =3D bind_columns(c=
md)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fetch(cmd, bufs, retcod=
e)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elif result =3D=3D CS_COMPUTE_RESULT:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pass
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break
=A0 =A0 =A0 =A0 if status !=3D CS_END_RESULTS:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #raise CTError(cmd.conn, 'ct_results fa=
iled')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_FAIL
=A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if sql_status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_FAIL
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return CS_SUCCEED
def cleanup_db(ctx,status):
=A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exit_type =3D CS_FORCE_EXIT
=A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exit_type =3D CS_UNUSED
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # close and cleanup connection to the s=
erver
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ctx.ct_exit(exit_type) !=3D CS_SUCCE=
ED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CSError(ctx, 'ct_=
exit failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # drop the context
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ctx.cs_ctx_drop() !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CSError(ctx, 'cs_=
ctx_drop failed')
class SybaseSQL:
=A0 =A0 =A0 =A0 """Execute a stored procedure on a Sybase server"""
=A0 =A0 =A0 =A0 def __init__(self, server, user, password, sql_statemen=
t):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.__allow_access_to_unprotected_subo=
bjects__ =3D 1
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.retcode =3D []
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.outputs =3D []
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.rows =3D []
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a context and initialize cli=
ent-library
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ctx =3D init_db()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a command structure
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con =3D connect_db(ctx, server, user, p=
assword)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Allocate a command structure
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status, cmd =3D con.ct_cmd_alloc()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CTError(con, 'ct_=
cmd_alloc failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Send the command to the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_command(CS_LANG_CMD, =
sql_statement)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D CTError(c=
md.con, 'ct_command failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Execute SQL statement on the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_send()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D CTError(c=
md.con, 'ct_send failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Process results from the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D handle_returns(cmd, self.ret=
code, self.outputs, self.rows)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd.ct_cmd_drop()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise CTError(con,'hand=
le_returns failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Drop the command structure
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D cmd.ct_cmd_drop()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D =A0CTErro=
r(con, 'ct_cmd_drop failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 con.ct_close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Close the connection to the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D con.ct_close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if status !=3D CS_SUCCEED:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sql_error =3D =A0CTErro=
r(con, 'ct_close failed')
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 raise sql_error
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Drop the context and do general clean=
up
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cleanup_db(ctx, status)
=A0 =A0 =A0 =A0 def ReturnCode(self):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the code of the procedure"""
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.retcode
=A0 =A0 =A0 =A0 def Outputs(self):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the output parameters"""
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.outputs
=A0 =A0 =A0 =A0 def Rows(self):
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 """Return the rows"""
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return self.rows
def execSybaseSQL(server, user, password, sql_statement):
=A0 =A0 =A0 =A0 """Init a Sybase RPC object"""
=A0 =A0 =A0 =A0 return SybaseSQL(server, user, password, sql_statement)=
if __name__ =3D=3D "__main__":
=A0 =A0 =A0 =A0 Request =3D execSybaseSQL("ds_teddy_uat", "michse", "sm=
huat01","select * from TEDDY_USERS")
=A0 =A0 =A0 =A0 print Request.ReturnCode()
=A0 =A0 =A0 =A0 print Request.Outputs()
=A0 =A0 =A0 =A0 print Request.Rows()
Sebastien.
Sebastien Michel
Front Office Technology
+33 1 44 95 62 89
3, avenue de Friedland
75008 Paris
--
This e-mail may contain confidential and/or privileged information. If =
you are not the intended recipient (or have received this e-mail in err=
or) please notify the sender immediately and destroy this e-mail. Any u=
nauthorized copying, disclosure or distribution of the material in this=
e-mail is strictly forbidden.
=
|
|
From: Valerie R. C. <vr...@co...> - 2003-01-29 18:59:47
|
>
>
>I think that maxlength is the problem here. Can you try a little
>experiment for me... Try this patch:
>
>--- Sybase.py 23 Jan 2003 10:11:02 -0000 1.56
>+++ Sybase.py 24 Jan 2003 01:01:13 -0000
>@@ -158,6 +158,8 @@
> fmt.count = count
> if fmt.datatype == CS_VARBINARY_TYPE:
> fmt.datatype = CS_BINARY_TYPE
>+ if fmt.maxlength > 65536:
>+ fmt.maxlength = 65536
> status, buf = cmd.ct_bind(i + 1, fmt)
> if status != CS_SUCCEED:
> raise Error('ct_bind')
>
>
>
Dave,
This patch works! (I have edited for typos). Furthermore, it works
whether or not the text fields are all at the end. I don't get the
other error I was talking about as long as I don't select a field with a
unique type.
Thanks!
Valerie
|
|
From: May, C. (IMS) <Ma...@im...> - 2003-01-28 13:13:39
|
I am trying to use the parameters feature of the execute for the first
time, and there seems to be a bug. I all the parameters I set are of
the same type (all numeric, all varchar, etc...), then the call works
fine. However, if I mix and match, I get some strange errors. The code
is below.
Also, is there a function, like in Perl::DBI, which will escape a string
so that you can build an SQL string. It handles strings with quotes,
etc... I assume if I can get the parameters working, it won't matter.
Thanks,
Chuck
#!/usr/bin/env python -O
if __name__=3D=3D'__main__':
import Sybase
db =3D Sybase.connect('peach5025d', 'may', 'maymay', 'bsiweb_dev')
c =3D db.cursor()
status_id =3D 0
output_text =3D "OUTPUT"
error_text =3D "ABC"
job_id =3D 30
# this works (all numeric fields)
c.execute('UPDATE jobs SET status_id =3D @status_id WHERE job_id =3D
@job_id', \
{ '@job_id' : job_id, '@status_id' : 1 })
# this doesn't work (one numeric, one varchar), and give the
following error:
# Traceback (most recent call last):
# File "./testd.py", line 19, in ?
# { '@error_text' : error_text, '@job_id' : job_id })
# File "/opt/net/utils/lib/python2.2/site-packages/Sybase.py",
line 376, in execute
# self._start_results()
# File "/opt/net/utils/lib/python2.2/site-packages/Sybase.py",
line 548, in _start_results
# status, result =3D self._cmd.ct_results()
# File "/opt/net/utils/lib/python2.2/site-packages/Sybase.py",
line 145, in _servermsg_cb
# raise DatabaseError(_fmt_server(msg))
# Sybase.DatabaseError: Msg 1622, Level 18, State 2, Line 1
# Type 'C' not implemented.
c.execute("UPDATE jobs SET error_text =3D @error_text WHERE job_id =
=3D
@job_id", \
{ '@error_text' : error_text, '@job_id' : job_id })
=20
# this works (all varchar fields)
c.execute("UPDATE jobs SET output =3D @output, error_text =3D
@error_text WHERE job_id =3D 30", \
{ '@output' : output_text, '@error_text' : error_text })
db.commit()
|
|
From: Harri P. <har...@tr...> - 2003-01-28 11:11:46
|
On Saturday 25 January 2003 06:02, Dave Cole wrote: > I decided that it was about time to upgrade to 12.5. I downloaded the > linux rpms from sybase.com and converted them to debs using alien (I > use Debian) and installed. > > I set the maximum shared memory size to 64M (the documentation says > this is the minimum). > > Then I found I could not run the license configuration tool since it > is written in Java and their jvm is linked against glibc 2.0 (!). So > I decided to see if I could manually build a license.dat file from the > less than helpful documentation. It doesn't look like I was > successful. > > I forged ahead and tried to run srvbuild (oh joy, another stoopid GUI > app - what is wrong with curses, or heaven forbid, cli?). The process > segfaults with some massive stack trace. > > So now I cannot do anything with Sybase. Why oh why do they make the > installation process harder and harder with every release... > > Has anyone out there managed to get Sybase ASE 12.5 going on Linux > (even better, Debian)? > > - Dave Maybe it would be simpler for you just to install glibc 2.0? It should not do any harm. I've only used OpenClient 12.5 on Linux, Mandrake 9.0, and that works without problems. Installing Oracle 8.1.7 also died for me because of some jvm issue. Looks like the Java 'virus' at work there as well... -Harri |
|
From: <Sha...@in...> - 2003-01-27 04:13:39
|
Hi,
The Sybase equivalent of 'set implicit_transactions on' is 'set chained =
on'. This might work on MSSQL too -- I don't have one on me... But you =
may still activate the feature in very similar ways (executing a =
statement) rather than very different ones (statement vs. setting a =
connection property).
In any case, I think if you fail to set up chained transactions you =
should definitely not "just ignore it quietly"; this would be very =
un-pythonic. You should let the user allow it to be quietly ignored, or =
have an option to explicitly connect in auto-commit mode, but not as =
default.
Having a connection succeed, but use a subtly different semantics than =
the user expects (because of the DBAPI spec, and the fact that =
Sybase/MSSQL do support chained mode), is just asking for trouble.
My 2 cents,
Shai.
-----Original Message-----
From: Dave Cole [mailto:dj...@ob...]=20
Sent: Friday, January 24, 2003 15:11
To: Marcos S=E1nchez Provencio
Cc: pyt...@ob...
Subject: Re: [python-sybase] Error in ct_options
> First, thank you for the module in general and for the fast answer in=20
> particular.
>=20
> I suppose you meant=20
> - if status !=3D CS_SUCCEED:
> - self._raise_error(Error, 'ct_options')
> + self.auto_commit =3D (status !=3D CS_SUCCEED)
> ^^^^^^
>=20
> Well, now it connects alright, but I don't get auto-commit off, do I?=20
> I do want standard dbapi behavior.
>=20
> Would it be ok to just execute
> c.execute('set implicit_transactions on') on the connection?
Does anyone know if there is a standard way to disable auto commit on =
both Sybase and SQL Server?
- Dave
--=20
http://www.object-craft.com.au
_______________________________________________
Python-sybase mailing list
Pyt...@ob... =
https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
|
|
From: <Sha...@in...> - 2003-01-27 04:02:51
|
Hi all,
This exposes a deep problem with text/image columns:
a) They must be treated specially, not like other columns -- they have a
special calling sequence, a special set of functions for dealing with
them;
b) This special treatment cannot be applied to columns in the middle of
the query -- all text/image columns must come after all "normal"
columns.
Now, my knowledge is based on Sybase's client library, ct. FreeTds may
be different. However,
Dave: If the Sybase module does not pay special attention to text/image
columns, it is a bug with the direct Sybase implementation (sorry, no
time to check for myself right now).
Valerie: Whether or not Sybase module has a bug, you may need to change
the query so that the text fields are all in the end. You don't need to
redefine the table, only query with a specified list of fields ("select
a,b,c from table"), so that the order of fields is as required.
Hope this helps,
Shai.
-----Original Message-----
From: Valerie R. Coffman [mailto:vr...@co...]=20
Sent: Thursday, January 23, 2003 22:20
To: Dave Cole
Cc: pyt...@ob...
Subject: Re: [python-sybase] MemoryError using Sybase, FreeTDS, MS SQL
Hi,
Dave, thanks for your response. We have a big interest in this module=20
because without it, we have to use a combination of Perl and Python and=20
it's pretty ugly.
I've dowloaded the version 0.36pre3 and turned on the debugging. I'm=20
still seeing the same error and it appears that the problem is with=20
retrieving a text type column. Here is part of the output. The full=20
output is attatched in the file "output".
ct_describe(cmd1, 9, &fmt) -> CS_SUCCEED, datafmt8=3D[name:"lengthScale" =
type:CS_FLOAT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1
maxlength:8] ct_bind(cmd1, 9, &datafmt8->fmt=3D[name:"lengthScale"
type:CS_FLOAT_TYPE=20
status:CS_FALSE format:CS_FMT_UNUSED count:32 maxlength:8],=20
databuf8->buff, databuf8->copied, databuf8->indicator) -> CS_SUCCEED,
databuf8
ct_describe(cmd1, 10, &fmt) -> CS_SUCCEED, datafmt9=3D[name:"material"=20
type:CS_TEXT_TYPE status:CS_CANBENULL format:CS_FMT_UNUSED count:1=20
maxlength:2147483647]
Traceback (most recent call last):
File "DBTest.py", line 10, in ?
db.execute("SELECT * FROM FEMMD_Parameters")
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line=20
727, in execute
result_list =3D self._fetch_results()
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line=20
745, in _fetch_results
bufs =3D _row_bind(cmd, self.arraysize)
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line=20
159, in _row_bind
status, buf =3D cmd.ct_bind(i + 1, fmt)
MemoryError
ct_cmd_drop(cmd1) -> CS_SUCCEED
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->=20
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
There should be two more columns after the "material" column, so it=20
seems that it does not finish retrieving one row, but stops at the first
text type row.
Knowing this, I've tried a similar query on a table that does not have a
text column and I get a different error. Here is part of the output,=20
the full output is attached in "output2".
ct_describe(cmd1, 8, &fmt) -> CS_SUCCEED, datafmt7=3D[name:"energy"=20
type:CS_FLOAT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1=20
maxlength:8 scale:0 precision:0]
ct_bind(cmd1, 8, &datafmt7->fmt=3D[name:"energy" type:CS_FLOAT_TYPE=20
status:CS_FALSE format:CS_FMT_UNUSED count:32 maxlength:8 scale:0=20
precision:0], databuf7->buff, databuf7->copied, databuf7->indicator) ->=20
CS_SUCCEED, databuf7
ct_fetch(cmd1, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) ->=20
CS_ROW_FAIL, 0
Traceback (most recent call last):
File "DBTest.py", line 10, in ?
db.execute("SELECT * FROM FEMMD_AtomicInfo")
File=20
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-
packages/Sybase.py",=20
line 732, in execute
result_list =3D self._fetch_results()
File=20
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-
packages/Sybase.py",=20
line 751, in _fetch_results
logical_result =3D self._fetch_logical_result(bufs)
File=20
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-
packages/Sybase.py",=20
line 760, in _fetch_logical_result
rows =3D _fetch_rows(cmd, bufs)
File=20
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-
packages/Sybase.py",=20
line 196, in _fetch_rows
raise Error('ct_fetch')
Sybase.Error: ct_fetch
ct_cmd_drop(cmd1) -> CS_SUCCEED
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->=20
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
Thanks,
Valerie
|
|
From: Dave C. <dj...@ob...> - 2003-01-26 00:02:18
|
I decided that it was about time to upgrade to 12.5. I downloaded the linux rpms from sybase.com and converted them to debs using alien (I use Debian) and installed. I set the maximum shared memory size to 64M (the documentation says this is the minimum). Then I found I could not run the license configuration tool since it is written in Java and their jvm is linked against glibc 2.0 (!). So I decided to see if I could manually build a license.dat file from the less than helpful documentation. It doesn't look like I was successful. I forged ahead and tried to run srvbuild (oh joy, another stoopid GUI app - what is wrong with curses, or heaven forbid, cli?). The process segfaults with some massive stack trace. So now I cannot do anything with Sybase. Why oh why do they make the installation process harder and harder with every release... Has anyone out there managed to get Sybase ASE 12.5 going on Linux (even better, Debian)? - Dave -- http://www.object-craft.com.au |
|
From: Ashley G. <ash...@ho...> - 2003-01-25 20:26:44
|
ok turned on debugging and this is what i get:
[root@the-box db-stuff]# python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Sybase
>>> Sybase._ctx.debug = 1
>>> db = Sybase.connect('Oscar', 'docent', 'docent')
ct_con_alloc(ctx0, &conn) -> CS_SUCCEED, conn0
ct_con_props(conn0, CS_SET, CS_USERNAME, "docent", CS_NULLTERM, NULL) -> CS_SUCCEED
ct_con_props(conn0, CS_SET, CS_PASSWORD, "docent", CS_NULLTERM, NULL) -> CS_SUCCEED
servermsg_cb
servermsg_cb
ct_connect(conn0, "Oscar", CS_NULLTERM) -> CS_SUCCEED
ct_options(conn0, CS_SET, CS_OPT_CHAINXACTS, 1, CS_UNUSED, NULL) -> CS_SUCCEED
>>> c = db.cursor()
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd0
.....
ct_bind(cmd0, 35, &datafmt34->fmt=[name:"msrepl_tran_version" type:CS_FORCE_CLOSE status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:16 scale:0 precision:0], databuf34->buff, databuf34->copied,
databuf34->indicator) -> CS_SUCCEED, databuf34
ct_describe(cmd0, 36, &fmt) -> CS_SUCCEED, datafmt35=[name:"careerModelID" type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0]
ct_bind(cmd0, 36, &datafmt35->fmt=[name:"careerModelID" type:CS_INT_TYPE status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0], databuf35->buff, databuf35->copied,
databuf35->indicator) -> CS_SUCCEED, databuf35
ct_describe(cmd0, 37, &fmt) -> CS_SUCCEED, datafmt36=[name:"countryID" type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0]
ct_bind(cmd0, 37, &datafmt36->fmt=[name:"countryID" type:CS_INT_TYPE status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0], databuf36->buff, databuf36->copied,
databuf36->indicator) -> CS_SUCCEED, databuf36
ct_describe(cmd0, 38, &fmt) -> CS_SUCCEED, datafmt37=[name:"careerCounselorID" type:CS_INT_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0]
ct_bind(cmd0, 38, &datafmt37->fmt=[name:"careerCounselorID" type:CS_INT_TYPE status:CS_CANBENULL
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0], databuf37->buff, databuf37->copied,
databuf37->indicator) -> CS_SUCCEED, databuf37
ct_describe(cmd0, 39, &fmt) -> CS_SUCCEED, datafmt38=[name:"myLTicket" type:CS_CHAR_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:32 scale:0 precision:0]
ct_bind(cmd0, 39, &datafmt38->fmt=[name:"myLTicket" type:CS_CHAR_TYPE status:CS_CANBENULL
format:CS_FMT_UNUSED count:1 maxlength:32 scale:0 precision:0], databuf38->buff, databuf38->copied,
databuf38->indicator) -> CS_SUCCEED, databuf38
ct_describe(cmd0, 40, &fmt) -> CS_SUCCEED, datafmt39=[name:"userTicket" type:CS_CHAR_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:32 scale:0 precision:0]
ct_bind(cmd0, 40, &datafmt39->fmt=[name:"userTicket" type:CS_CHAR_TYPE status:CS_CANBENULL
format:CS_FMT_UNUSED count:1 maxlength:32 scale:0 precision:0], databuf39->buff, databuf39->copied,
databuf39->indicator) -> CS_SUCCEED, databuf39
ct_describe(cmd0, 41, &fmt) -> CS_SUCCEED, datafmt40=[name:"subStatus" type:CS_CHAR_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:1 scale:0 precision:0]
ct_bind(cmd0, 41, &datafmt40->fmt=[name:"subStatus" type:CS_CHAR_TYPE status:CS_CANBENULL
format:CS_FMT_UNUSED count:1 maxlength:1 scale:0 precision:0], databuf40->buff, databuf40->copied,
databuf40->indicator) -> CS_SUCCEED, databuf40
ct_describe(cmd0, 42, &fmt) -> CS_SUCCEED, datafmt41=[name:"businessUnit" type:CS_CHAR_TYPE
status:CS_CANBENULL format:CS_FMT_UNUSED count:1 maxlength:5 scale:0 precision:0]
ct_bind(cmd0, 42, &datafmt41->fmt=[name:"businessUnit" type:CS_CHAR_TYPE status:CS_CANBENULL
format:CS_FMT_UNUSED count:1 maxlength:5 scale:0 precision:0], databuf41->buff, databuf41->copied,
databuf41->indicator) -> CS_SUCCEED, databuf41
>>> c.fetchall()
ct_fetch(cmd0, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> CS_ROW_FAIL, 0
ct_cancel(NULL, cmd0, CS_CANCEL_ALL) -> CS_SUCCEED
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/site-packages/Sybase.py", line 490, in fetchall
row = self.fetchone()
File "/usr/lib/python2.2/site-packages/Sybase.py", line 410, in fetchone
_array = _fetch_rows(self._cmd, self._bufs)
File "/usr/lib/python2.2/site-packages/Sybase.py", line 196, in _fetch_rows
raise Error('ct_fetch')
Sybase.Error: ct_fetch
* Dave Cole (dj...@ob...) wrote:
>
> > upgrade to sybase v.36pre3 and now I get these errors:
>
> > [root@the-box hash]# python
> > Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
> > [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import Sybase
> > >>> db = Sybase.connect('Oscar', 'docent', 'docent')
> > >>> c = db.cursor()
> > >>> c.execute("select * from docent.DRUser")
> > >>> c.fetchall()
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 490, in fetchall
> > row = self.fetchone()
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 410, in fetchone
> > _array = _fetch_rows(self._cmd, self._bufs)
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 196, in _fetch_rows
> > raise Error('ct_fetch')
> > Sybase.Error: ct_fetch
> > >>>
> > Any idea what is going wrong here?
> >
> > It also doesn't matter if I use the c.fetchall() or c.fetchone()
>
> Try doing this and post the debug output:
>
> import Sybase
> Sybase._ctx.debug = 1
> db = Sybase.connect('Oscar', 'docent', 'docent')
> c = db.cursor()
> c.execute("select * from docent.DRUser")
> c.fetchall()
>
> - Dave
>
> --
> http://www.object-craft.com.au
>
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ob...
> https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
|
|
From: Adam S. <as...@ma...> - 2003-01-25 12:51:49
|
Not sure if this belongs on this list, but seemed like it was worth
passing along.
I just successfully built the Sybase module (with only a simple change
to setup.py shown below) against a current build of python 2.3 on Mac
OS X 10.2.3 with the Sybase ASE v12.5. All the tests listed in section
1.3 of the documentation passed and so far it seems to work great.
Only change I made was to insert the following at line 32 of setup.py
(basically duplicating the logic from the 'nt' section)
if os.environ.has_key('SYBASE_OCS'):
ocs = os.environ['SYBASE_OCS']
sybase = os.path.join(sybase, ocs)
I haven't tried building against the version of python that ships with
Jaguar, but if anyone is interested let me know and I'll try it with a
fresh 10.2 install.
To everyone who made this work - thank you!!
- adam
|
|
From: May, C. (IMS) <Ma...@im...> - 2003-01-25 10:15:59
|
I am getting an error when I try to select a numeric(6,2) field from a
table. Here is the code:
# connect to the database
db =3D Sybase.connect('peach5026d', 'may', 'maymay', 'nci_dev')
c =3D db.cursor()
c.arraysize =3D 64
c.execute("SELECT volume FROM vial WHERE study_id =3D 'AHS'")
while 1:
rows =3D c.fetchmany()
if not rows : break
for row in rows:
print row
c.close()
and here is the error:
(
Traceback (most recent call last):
File "./test_sybase.py", line 17, in ?
print row
ValueError: no globla context defined
Searching on the other fields work fine. Also, changing the SQL to read
SELECT convert(float, volume) FROM vial WHERE study_id =3D 'AHS'"
also fixes the error.
Chuck
|
|
From: Dave C. <dj...@ob...> - 2003-01-25 08:11:27
|
> First, thank you for the module in general and for the fast answer
> in particular.
>
> I suppose you meant
> - if status != CS_SUCCEED:
> - self._raise_error(Error, 'ct_options')
> + self.auto_commit = (status != CS_SUCCEED)
> ^^^^^^
>
> Well, now it connects alright, but I don't get auto-commit off, do
> I? I do want standard dbapi behavior.
>
> Would it be ok to just execute
> c.execute('set implicit_transactions on') on the connection?
Does anyone know if there is a standard way to disable auto commit on
both Sybase and SQL Server?
- Dave
--
http://www.object-craft.com.au
|
|
From: Dave C. <dj...@ob...> - 2003-01-25 08:09:49
|
> upgrade to sybase v.36pre3 and now I get these errors:
> [root@the-box hash]# python
> Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
> [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import Sybase
> >>> db = Sybase.connect('Oscar', 'docent', 'docent')
> >>> c = db.cursor()
> >>> c.execute("select * from docent.DRUser")
> >>> c.fetchall()
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "/usr/lib/python2.2/site-packages/Sybase.py", line 490, in fetchall
> row = self.fetchone()
> File "/usr/lib/python2.2/site-packages/Sybase.py", line 410, in fetchone
> _array = _fetch_rows(self._cmd, self._bufs)
> File "/usr/lib/python2.2/site-packages/Sybase.py", line 196, in _fetch_rows
> raise Error('ct_fetch')
> Sybase.Error: ct_fetch
> >>>
> Any idea what is going wrong here?
>
> It also doesn't matter if I use the c.fetchall() or c.fetchone()
Try doing this and post the debug output:
import Sybase
Sybase._ctx.debug = 1
db = Sybase.connect('Oscar', 'docent', 'docent')
c = db.cursor()
c.execute("select * from docent.DRUser")
c.fetchall()
- Dave
--
http://www.object-craft.com.au
|
|
From: Marcos P. <ra...@ar...> - 2003-01-25 06:32:52
|
First, thank you for the module in general and for the fast answer in
particular.
I suppose you meant
- if status != CS_SUCCEED:
- self._raise_error(Error, 'ct_options')
+ self.auto_commit = (status != CS_SUCCEED)
^^^^^^
Well, now it connects alright, but I don't get auto-commit off, do I? I
do want standard dbapi behavior.
Would it be ok to just execute
c.execute('set implicit_transactions on') on the connection?
El vie, 24-01-2003 a las 02:16, Dave Cole escribió:
> > I am getting Sybase.Error: ct_options when connecting to MSSQL or
> > Sybase. If I comment out the CS_OPT_CHAINXACTS line, it seems to
> > work for simple selects. tsql from freetds, today's version works
> > fine, so I suppose my freetds.conf file is right. What is the next
> > place to look?
>
> The CS_OPT_CHAINXACTS option is there to conform to the DB-API
> specification
>
> http://www.python.org/topics/database/DatabaseAPI-2.0.html
>
> Connection Objects
> commit()
>
> Commit any pending transaction to the database. Note that if the
> database supports an auto-commit feature, this must be initially
> off. An interface method may be provided to turn it back on.
>
> Database modules that do not support transactions should
> implement this method with void functionality.
>
> I probably should silently ignore problems setting this option...
>
> > I get the following when connecting to MSSQL2000:
> >
> > marcos@cynar:~/sybase-0.36pre3$ python -c "import
> > Sybase;Sybase._ctx.debug = 1;Sybase.connect('cazalla','sa','xxx')"
> > ct_con_alloc(ctx0, &conn) -> CS_SUCCEED, conn0
> > ct_con_props(conn0, CS_SET, CS_USERNAME, "sa", CS_NULLTERM, NULL) ->
> > CS_SUCCEED
> > ct_con_props(conn0, CS_SET, CS_PASSWORD, "xxx", CS_NULLTERM, NULL) ->
> > CS_SUCCEED
> > servermsg_cb
> > servermsg_cb
> > ct_connect(conn0, "cazalla", CS_NULLTERM) -> CS_SUCCEED
> > ct_options(conn0, CS_SET, CS_OPT_CHAINXACTS, 1, CS_UNUSED, NULL) ->
> > CS_FAIL
> > ct_cancel(conn0, NULL, CS_CANCEL_ALL) -> CS_SUCCEED
> > Traceback (most recent call last):
> > File "<string>", line 1, in ?
> > File "Sybase.py", line 768, in connect
> > strip, auto_commit, delay_connect, locking)
> > File "Sybase.py", line 608, in __init__
> > self.connect()
> > File "Sybase.py", line 633, in connect
> > self._raise_error(Error, 'ct_options')
> > File "Sybase.py", line 621, in _raise_error
> > raise exc(text)
> > Sybase.Error: ct_options
> > ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
> > CS_SUCCEED, CS_CONSTAT_CONNECTED
> > ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
> > ct_con_drop(conn0) -> CS_SUCCEED
>
> Can you try this patch (to 0.36pre3) for me (contains changes for
> Valerie R. Coffman as well)?
>
> - Dave
>
> -- Sybase.py 23 Jan 2003 10:11:02 -0000 1.56
> +++ Sybase.py 24 Jan 2003 01:13:55 -0000
>
> @@ -158,6 +158,8 @@
> fmt.count = count
> if fmt.datatype == CS_VARBINARY_TYPE:
> fmt.datatype = CS_BINARY_TYPE
> + if fmt.maxlngth > 65536:
> + fmx.maxlength = 65536
> status, buf = cmd.ct_bind(i + 1, fmt)
> if status != CS_SUCCEED:
> raise Error('ct_bind')
> @@ -629,8 +631,7 @@
> self._raise_error(Error, 'ct_connect')
> self._is_connected = 1
> status = conn.ct_options(CS_SET, CS_OPT_CHAINXACTS, not self.auto_commit)
> - if status != CS_SUCCEED:
> - self._raise_error(Error, 'ct_options')
> + self.auto_commit = (status != SUCCEED)
> finally:
> self._unlock()
> if self.database:
--
Marcos Sánchez Provencio <ra...@ar...>
|
|
From: Ashley G. <ash...@ho...> - 2003-01-25 00:57:15
|
upgrade to sybase v.36pre3 and now I get these errors:
[root@the-box hash]# python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Sybase
>>> db = Sybase.connect('Oscar', 'docent', 'docent')
>>> c = db.cursor()
>>> c.execute("select * from docent.DRUser")
>>> c.fetchall()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/site-packages/Sybase.py", line 490, in fetchall
row = self.fetchone()
File "/usr/lib/python2.2/site-packages/Sybase.py", line 410, in fetchone
_array = _fetch_rows(self._cmd, self._bufs)
File "/usr/lib/python2.2/site-packages/Sybase.py", line 196, in _fetch_rows
raise Error('ct_fetch')
Sybase.Error: ct_fetch
>>>
Any idea what is going wrong here?
It also doesn't matter if I use the c.fetchall() or c.fetchone()
thanks
Ashley
* Dave Cole (dj...@ob...) wrote:
>
> > more information. I am using freetds v0.60 and python-sybase v0.35
> >
> > [root@the-box db-stuff]# python
> > Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
> > [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import Sybase
> > >>> db = Sybase.connect('Server', 'user','passwd')
> > >>> c = db.cursor()
> > >>> c.execute("select * from docent.DRUser where userID = '50970'")
> > >>> c.fetchall()
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 489, in fetchall
> > row = self.fetchone()
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 409, in fetchone
> > _array = _fetch_rows(self._cmd, self._bufs)
> > File "/usr/lib/python2.2/site-packages/Sybase.py", line 193, in _fetch_rows
> > elif status in (CS_ROW_FAIL, CS_FAIL, CS_CANCELED,
> > NameError: global name 'CS_PENDING' is not defined
> > >>>
>
> FreeTDS does not define the CS_PENDING and CS_BUSY values. The quick
> fix for this problem is to delete all references to CS_PENDING and
> CS_BUSY from Sybase.py.
>
> 0.36pre2 does not use CS_PENDING or CS_BUSY in Sybase.py
>
> - Dave
>
> --
> http://www.object-craft.com.au
>
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ob...
> https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
----- End forwarded message -----
|
|
From: Dave C. <dj...@ob...> - 2003-01-24 20:49:14
|
> Knowing this, I've tried a similar query on a table that does not > have a text column and I get a different error. Here is part of the > output, the full output is attached in "output2". [snip] > ct_command(cmd1, CS_LANG_CMD, "SELECT * FROM FEMMD_AtomicInfo", CS_NULLTERM, CS_OPT_AUTHOFF) -> CS_SUCCEED [snip] > ct_describe(cmd1, 1, &fmt) -> CS_SUCCEED, datafmt0=[name:"guid" type:CS_FORCE_CLOSE status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:16 scale:0 precision:0] Hmm... My debug code tries to convert the reported type of the column back into a text string and comes up with CS_FORCE_CLOSE!?! The debug code groups binary values into categories. When doing a lookup, it tries to resolve the value in the VAL_TYPE category and fails. It then just returns anything which matches the value. Looking at the FreeTDS header, this value corresponds to the type CS_UNIQUE_TYPE (which I don't have in my module). Maybe I should download the latest Sybase packages. Try building statements which select one column at a time to see which column types are causing the module to trip up. - Dave -- http://www.object-craft.com.au |
|
From: Dave C. <dj...@ob...> - 2003-01-24 20:16:07
|
> I am getting Sybase.Error: ct_options when connecting to MSSQL or
> Sybase. If I comment out the CS_OPT_CHAINXACTS line, it seems to
> work for simple selects. tsql from freetds, today's version works
> fine, so I suppose my freetds.conf file is right. What is the next
> place to look?
The CS_OPT_CHAINXACTS option is there to conform to the DB-API
specification
http://www.python.org/topics/database/DatabaseAPI-2.0.html
Connection Objects
commit()
Commit any pending transaction to the database. Note that if the
database supports an auto-commit feature, this must be initially
off. An interface method may be provided to turn it back on.
Database modules that do not support transactions should
implement this method with void functionality.
I probably should silently ignore problems setting this option...
> I get the following when connecting to MSSQL2000:
>
> marcos@cynar:~/sybase-0.36pre3$ python -c "import
> Sybase;Sybase._ctx.debug = 1;Sybase.connect('cazalla','sa','xxx')"
> ct_con_alloc(ctx0, &conn) -> CS_SUCCEED, conn0
> ct_con_props(conn0, CS_SET, CS_USERNAME, "sa", CS_NULLTERM, NULL) ->
> CS_SUCCEED
> ct_con_props(conn0, CS_SET, CS_PASSWORD, "xxx", CS_NULLTERM, NULL) ->
> CS_SUCCEED
> servermsg_cb
> servermsg_cb
> ct_connect(conn0, "cazalla", CS_NULLTERM) -> CS_SUCCEED
> ct_options(conn0, CS_SET, CS_OPT_CHAINXACTS, 1, CS_UNUSED, NULL) ->
> CS_FAIL
> ct_cancel(conn0, NULL, CS_CANCEL_ALL) -> CS_SUCCEED
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> File "Sybase.py", line 768, in connect
> strip, auto_commit, delay_connect, locking)
> File "Sybase.py", line 608, in __init__
> self.connect()
> File "Sybase.py", line 633, in connect
> self._raise_error(Error, 'ct_options')
> File "Sybase.py", line 621, in _raise_error
> raise exc(text)
> Sybase.Error: ct_options
> ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
> CS_SUCCEED, CS_CONSTAT_CONNECTED
> ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
> ct_con_drop(conn0) -> CS_SUCCEED
Can you try this patch (to 0.36pre3) for me (contains changes for
Valerie R. Coffman as well)?
- Dave
--- Sybase.py 23 Jan 2003 10:11:02 -0000 1.56
+++ Sybase.py 24 Jan 2003 01:13:55 -0000
@@ -158,6 +158,8 @@
fmt.count = count
if fmt.datatype == CS_VARBINARY_TYPE:
fmt.datatype = CS_BINARY_TYPE
+ if fmt.maxlngth > 65536:
+ fmx.maxlength = 65536
status, buf = cmd.ct_bind(i + 1, fmt)
if status != CS_SUCCEED:
raise Error('ct_bind')
@@ -629,8 +631,7 @@
self._raise_error(Error, 'ct_connect')
self._is_connected = 1
status = conn.ct_options(CS_SET, CS_OPT_CHAINXACTS, not self.auto_commit)
- if status != CS_SUCCEED:
- self._raise_error(Error, 'ct_options')
+ self.auto_commit = (status != SUCCEED)
finally:
self._unlock()
if self.database:
--
http://www.object-craft.com.au
|
|
From: Dave C. <dj...@ob...> - 2003-01-24 20:04:10
|
> Hi, Dave, thanks for your response. We have a big interest in this
> module because without it, we have to use a combination of Perl and
> Python and it's pretty ugly.
Funny, that is why I wrote the module - I was looking at either Perl
or ISQL...
[snip]
> ct_describe(cmd1, 10, &fmt) -> CS_SUCCEED, datafmt9=[name:"material"
> type:CS_TEXT_TYPE status:CS_CANBENULL format:CS_FMT_UNUSED count:1
> maxlength:2147483647]
I think that maxlength is the problem here. Can you try a little
experiment for me... Try this patch:
--- Sybase.py 23 Jan 2003 10:11:02 -0000 1.56
+++ Sybase.py 24 Jan 2003 01:01:13 -0000
@@ -158,6 +158,8 @@
fmt.count = count
if fmt.datatype == CS_VARBINARY_TYPE:
fmt.datatype = CS_BINARY_TYPE
+ if fmt.maxlngth > 65536:
+ fmx.maxlength = 65536
status, buf = cmd.ct_bind(i + 1, fmt)
if status != CS_SUCCEED:
raise Error('ct_bind')
I am not sure if will solve the problem or not, but it is worth a try.
> There should be two more columns after the "material" column, so it
> seems that it does not finish retrieving one row, but stops at the
> first text type row.
>
> Knowing this, I've tried a similar query on a table that does not
> have a text column and I get a different error. Here is part of the
> output, the full output is attached in "output2".
>
> ct_describe(cmd1, 8, &fmt) -> CS_SUCCEED, datafmt7=[name:"energy"
> type:CS_FLOAT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1
> maxlength:8 scale:0 precision:0]
> ct_bind(cmd1, 8, &datafmt7->fmt=[name:"energy" type:CS_FLOAT_TYPE
> status:CS_FALSE format:CS_FMT_UNUSED count:32 maxlength:8 scale:0
> precision:0], databuf7->buff, databuf7->copied, databuf7->indicator)
> ->
> CS_SUCCEED, databuf7
> ct_fetch(cmd1, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) ->
> CS_ROW_FAIL, 0
This looks like another column binding problem. Can you send a more
complete debug trace?
- Dave
--
http://www.object-craft.com.au
|
|
From: Valerie R. C. <vr...@co...> - 2003-01-24 15:20:11
|
Hi,
Dave, thanks for your response. We have a big interest in this module
because without it, we have to use a combination of Perl and Python and
it's pretty ugly.
I've dowloaded the version 0.36pre3 and turned on the debugging. I'm
still seeing the same error and it appears that the problem is with
retrieving a text type column. Here is part of the output. The full
output is attatched in the file "output".
ct_describe(cmd1, 9, &fmt) -> CS_SUCCEED, datafmt8=[name:"lengthScale"
type:CS_FLOAT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:8]
ct_bind(cmd1, 9, &datafmt8->fmt=[name:"lengthScale" type:CS_FLOAT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:32 maxlength:8],
databuf8->buff, databuf8->copied, databuf8->indicator) -> CS_SUCCEED,
databuf8
ct_describe(cmd1, 10, &fmt) -> CS_SUCCEED, datafmt9=[name:"material"
type:CS_TEXT_TYPE status:CS_CANBENULL format:CS_FMT_UNUSED count:1
maxlength:2147483647]
Traceback (most recent call last):
File "DBTest.py", line 10, in ?
db.execute("SELECT * FROM FEMMD_Parameters")
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line
727, in execute
result_list = self._fetch_results()
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line
745, in _fetch_results
bufs = _row_bind(cmd, self.arraysize)
File "/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py", line
159, in _row_bind
status, buf = cmd.ct_bind(i + 1, fmt)
MemoryError
ct_cmd_drop(cmd1) -> CS_SUCCEED
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
There should be two more columns after the "material" column, so it
seems that it does not finish retrieving one row, but stops at the first
text type row.
Knowing this, I've tried a similar query on a table that does not have a
text column and I get a different error. Here is part of the output,
the full output is attached in "output2".
ct_describe(cmd1, 8, &fmt) -> CS_SUCCEED, datafmt7=[name:"energy"
type:CS_FLOAT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1
maxlength:8 scale:0 precision:0]
ct_bind(cmd1, 8, &datafmt7->fmt=[name:"energy" type:CS_FLOAT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:32 maxlength:8 scale:0
precision:0], databuf7->buff, databuf7->copied, databuf7->indicator) ->
CS_SUCCEED, databuf7
ct_fetch(cmd1, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) ->
CS_ROW_FAIL, 0
Traceback (most recent call last):
File "DBTest.py", line 10, in ?
db.execute("SELECT * FROM FEMMD_AtomicInfo")
File
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py",
line 732, in execute
result_list = self._fetch_results()
File
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py",
line 751, in _fetch_results
logical_result = self._fetch_logical_result(bufs)
File
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py",
line 760, in _fetch_logical_result
rows = _fetch_rows(cmd, bufs)
File
"/afs/.msc.cornell.edu/i386_linux22/usr/local/pub/dm/lib/python2.1/site-packages/Sybase.py",
line 196, in _fetch_rows
raise Error('ct_fetch')
Sybase.Error: ct_fetch
ct_cmd_drop(cmd1) -> CS_SUCCEED
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
Thanks,
Valerie
|
|
From: Marcos P. <msa...@gr...> - 2003-01-24 11:24:25
|
Hello there.
I am getting Sybase.Error: ct_options when connecting to MSSQL or
Sybase. If I comment out the CS_OPT_CHAINXACTS line, it seems to work
for simple selects. tsql from freetds, today's version works fine, so I
suppose my freetds.conf file is right. What is the next place to look?
I get the following when connecting to MSSQL2000:
marcos@cynar:~/sybase-0.36pre3$ python -c "import
Sybase;Sybase._ctx.debug =3D 1;Sybase.connect('cazalla','sa','xxx')"
ct_con_alloc(ctx0, &conn) -> CS_SUCCEED, conn0
ct_con_props(conn0, CS_SET, CS_USERNAME, "sa", CS_NULLTERM, NULL) ->
CS_SUCCEED
ct_con_props(conn0, CS_SET, CS_PASSWORD, "xxx", CS_NULLTERM, NULL) ->
CS_SUCCEED
servermsg_cb
servermsg_cb
ct_connect(conn0, "cazalla", CS_NULLTERM) -> CS_SUCCEED
ct_options(conn0, CS_SET, CS_OPT_CHAINXACTS, 1, CS_UNUSED, NULL) ->
CS_FAIL
ct_cancel(conn0, NULL, CS_CANCEL_ALL) -> CS_SUCCEED
Traceback (most recent call last):
File "<string>", line 1, in ?
File "Sybase.py", line 768, in connect
strip, auto_commit, delay_connect, locking)
File "Sybase.py", line 608, in __init__
self.connect()
File "Sybase.py", line 633, in connect
self._raise_error(Error, 'ct_options')
File "Sybase.py", line 621, in _raise_error
raise exc(text)
Sybase.Error: ct_options
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
I have this freetds.log
Starting log file with debug level 99.
2003-01-23 17:20:51.977855 iconv will convert client-side data to the ""
character set
2003-01-23 17:20:52.000075 Connecting addr 192.168.222.235 port 1433
with TDS version 8.0
2003-01-23 17:20:52.062367 inside tds_process_login_tokens()
Received header @ 2003-01-23 17:20:52.067664
0000 04 01 01 8d 00 34 01 00 |.....4..|
Received packet @ 2003-01-23 17:20:52.067873
0000 e3 1b 00 01 06 6d 00 61 00 73 00 74 00 65 00 72 |.....m.a
.s.t.e.r|
0010 00 06 6d 00 61 00 73 00 74 00 65 00 72 00 ab 7c |..m.a.s.
t.e.r..||
0020 00 45 16 00 00 02 00 31 00 43 00 61 00 6d 00 62 |.E.....1
.C.a.m.b|
0030 00 69 00 61 00 64 00 6f 00 20 00 65 00 6c 00 20 |.i.a.d.o .
.e.l. |
0040 00 63 00 6f 00 6e 00 74 00 65 00 78 00 74 00 6f |.c.o.n.t
.e.x.t.o|
0050 00 20 00 64 00 65 00 20 00 62 00 61 00 73 00 65 |. .d.e.=20
.b.a.s.e|
0060 00 20 00 64 00 65 00 20 00 64 00 61 00 74 00 6f |. .d.e.=20
.d.a.t.o|
0070 00 73 00 20 00 61 00 20 00 27 00 6d 00 61 00 73 |.s. .a.=20
.'.m.a.s|
0080 00 74 00 65 00 72 00 27 00 2e 00 07 43 00 41 00 |.t.e.r.'
....C.A.|
0090 5a 00 41 00 4c 00 4c 00 41 00 00 00 00 e3 08 00 |Z.A.L.L.
A.......|
00a0 07 05 0a 0c d0 00 00 00 e3 17 00 02 0a 75 00 73 |........
.....u.s|
00b0 00 5f 00 65 00 6e 00 67 00 6c 00 69 00 73 00 68 |._.e.n.g
.l.i.s.h|
00c0 00 00 ab 68 00 47 16 00 00 01 00 27 00 43 00 68 |...h.G..
...'.C.h|
00d0 00 61 00 6e 00 67 00 65 00 64 00 20 00 6c 00 61 |.a.n.g.e .d.
.l.a|
00e0 00 6e 00 67 00 75 00 61 00 67 00 65 00 20 00 73 |.n.g.u.a .g.e.
.s|
00f0 00 65 00 74 00 74 00 69 00 6e 00 67 00 20 00 74 |.e.t.t.i .n.g.
.t|
0100 00 6f 00 20 00 75 00 73 00 5f 00 65 00 6e 00 67 |.o. .u.s
._.e.n.g|
0110 00 6c 00 69 00 73 00 68 00 2e 00 07 43 00 41 00 |.l.i.s.h
....C.A.|
0120 5a 00 41 00 4c 00 4c 00 41 00 00 00 00 ad 36 00 |Z.A.L.L.
A.....6.|
0130 01 07 01 00 00 16 4d 00 69 00 63 00 72 00 6f 00 |......M.
i.c.r.o.|
0140 73 00 6f 00 66 00 74 00 20 00 53 00 51 00 4c 00 |s.o.f.t.=20
.S.Q.L.|
0150 20 00 53 00 65 00 72 00 76 00 65 00 72 00 00 00 | .S.e.r.
v.e.r...|
0160 00 00 08 00 00 c2 e3 13 00 04 04 34 00 30 00 39 |........
...4.0.9|
0170 00 36 00 04 34 00 30 00 39 00 36 00 fd 00 00 00 |.6..4.0.
9.6.....|
0180 00 00 00 00 00 |.....|
2003-01-23 17:20:52.068976 inside tds_process_default_tokens() marker is
e3(ENVCHANGE)
2003-01-23 17:20:52.069084 inside tds_process_default_tokens() marker is
ab(INFO)
2003-01-23 17:20:52.069333 inside tds_process_default_tokens() marker is
e3(ENVCHANGE)
2003-01-23 17:20:52.069417 inside tds_process_default_tokens() marker is
e3(ENVCHANGE)
2003-01-23 17:20:52.069502 inside tds_process_default_tokens() marker is
ab(INFO)
2003-01-23 17:20:52.069796 inside tds_process_default_tokens() marker is
e3(ENVCHANGE)
2003-01-23 17:20:52.069890 increasing block size from 4096 to 4096
2003-01-23 17:20:52.069990 inside tds_process_default_tokens() marker is
fd(DONE)
2003-01-23 17:20:52.070071 inside tds_process_end() more_results =3D 0,
was_cancelled =3D 0=20
2003-01-23 17:20:52.070156 inside tds_process_default_tokens() setting
state to COMPLETED
Sending packet @ 2003-01-23 17:20:52.070276
0000 01 01 00 22 00 00 01 00 73 00 65 00 6c 00 65 00 |..."....
s.e.l.e.|
0010 63 00 74 00 20 00 40 00 40 00 73 00 70 00 69 00 |c.t. .@.
@.s.p.i.|
0020 64 00 |d.|
Received header @ 2003-01-23 17:20:52.078838
0000 04 01 00 1d 00 34 01 00 |.....4..|
Received packet @ 2003-01-23 17:20:52.079068
0000 81 01 00 00 00 00 00 34 00 d1 34 00 fd 10 00 c1 |.......4
..4.....|
0010 00 01 00 00 00 |.....|
2003-01-23 17:20:52.079179 processing result tokens. marker is=20
81(TDS7_RESULT)
2003-01-23 17:20:52.079291 tds7_get_data_info:1089:=20
type =3D 52 (smallint)
column_varint_size =3D 0
colname =3D=20
colnamelen =3D 0
2003-01-23 17:20:52.079407 processing row tokens. marker is d1(ROW)
2003-01-23 17:20:52.079478 processing row. column is 0 varint size =3D 0
2003-01-23 17:20:52.079611 processing row. column size is 2=20
2003-01-23 17:20:52.079678 clearing column 0 NULL bit
2003-01-23 17:20:52.079738 processing row tokens. marker is fd(DONE)
2003-01-23 17:20:52.079808 inside tds_process_end() more_results =3D 0,
was_cancelled =3D 0=20
2003-01-23 17:20:52.079976 inside tds_process_result_tokens() state is
COMPLETED
2003-01-23 17:20:52.080054 leaving tds_process_login_tokens() returning
1
2003-01-23 17:20:52.080143 leaving ct_connect() returning 1
2003-01-23 17:20:52.080385 inside ct_options() action =3D CS_GET option =3D
7
2003-01-23 17:20:52.080544 inside ct_cancel()
Sending packet @ 2003-01-23 17:20:52.080615
0000 06 01 00 08 00 00 01 00 |........|
Received header @ 2003-01-23 17:20:52.082576
0000 04 01 00 11 00 34 01 00 |.....4..|
Received packet @ 2003-01-23 17:20:52.082852
0000 fd 20 00 fd 00 00 00 00 00 |. ...... .|
2003-01-23 17:20:52.082930 inside tds_process_end() more_results =3D 0,
was_cancelled =3D 1=20
2003-01-23 17:20:52.088732 inside ct_con_props() action =3D CS_GET
property =3D 26
2003-01-23 17:20:52.088965 inside ct_close()
2003-01-23 17:20:52.089404 inside ct_con_drop()
--=20
gpg --recv-keys --keyserver wwwkeys.pgp.net B9AD9B1B
|
|
From: Marcos P. <ra...@ar...> - 2003-01-24 11:09:45
|
Hello there.
I am getting Sybase.Error: ct_options when connecting to MSSQL or
Sybase. If I comment out the CS_OPT_CHAINXACTS line, it seems to work
for simple selects. tsql from freetds, today's version works fine, so I
suppose my freetds.conf file is right. What is the next place to look?
I get the following when connecting to MSSQL2000:
marcos@cynar:~/sybase-0.36pre3$ python -c "import
Sybase;Sybase._ctx.debug = 1;Sybase.connect('cazalla','sa','xxx')"
ct_con_alloc(ctx0, &conn) -> CS_SUCCEED, conn0
ct_con_props(conn0, CS_SET, CS_USERNAME, "sa", CS_NULLTERM, NULL) ->
CS_SUCCEED
ct_con_props(conn0, CS_SET, CS_PASSWORD, "xxx", CS_NULLTERM, NULL) ->
CS_SUCCEED
servermsg_cb
servermsg_cb
ct_connect(conn0, "cazalla", CS_NULLTERM) -> CS_SUCCEED
ct_options(conn0, CS_SET, CS_OPT_CHAINXACTS, 1, CS_UNUSED, NULL) ->
CS_FAIL
ct_cancel(conn0, NULL, CS_CANCEL_ALL) -> CS_SUCCEED
Traceback (most recent call last):
File "<string>", line 1, in ?
File "Sybase.py", line 768, in connect
strip, auto_commit, delay_connect, locking)
File "Sybase.py", line 608, in __init__
self.connect()
File "Sybase.py", line 633, in connect
self._raise_error(Error, 'ct_options')
File "Sybase.py", line 621, in _raise_error
raise exc(text)
Sybase.Error: ct_options
ct_con_props(conn0, CS_GET, CS_CON_STATUS, &value, CS_UNUSED, NULL) ->
CS_SUCCEED, CS_CONSTAT_CONNECTED
ct_close(conn0, CS_OPT_STATS_IO) -> CS_SUCCEED
ct_con_drop(conn0) -> CS_SUCCEED
--
Marcos Sánchez Provencio <ra...@ar...>
|
|
From: Dave C. <dj...@ob...> - 2003-01-24 05:37:08
|
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:
This is another incremental improvement to FreeTDS support.
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.36pre3.tar.gz
The module home page is here:
http://www.object-craft.com.au/projects/sybase/
CHANGES SINCE 0.35:
* Removed references to CS_PENDING and CS_BUSY in Sybase.py.
* Bind CS_VARBINARY_TYPE as CS_BINARY_TYPE.
* Do not attempt to ct_cancel() when handling an exception if have not
connected to the server. Bug fix in Sybase.py.
* Seems like FreeTDS reports the wrong maxlength in ct_describe() for
CS_NUMERIC_TYPE and CS_DECIMAL_TYPE. Ignore FreeTDS and assume a
maxlength of sizeof(CS_NUMERIC). Bugfix in databuf.c.
* Use correct T_STRING_INPLACE type in structure member descriptions.
The code does not use Python API for these members.
* Debug output for DataFmt now includes scale and precision.
* More definitions added to freetds.h; CS_SRC_VALUE, CS_CLEAR.
--
http://www.object-craft.com.au
|
3 messages has been excluded from this view by a project administrator.
