python-sybase-misc

RE: [python-sybase] Re: Your test program (sp_test.py) output

[Bradley F. <br...@re...>]

That patch worked for me.  I'm getting the output parm back now!  =
Hooray!

*Bradley

-----Original Message-----
From: pyt...@ww...
[mailto:pyt...@ww...] On Behalf Of Dave =
Cole
Sent: Thursday, March 17, 2005 10:38 PM
To: pyt...@ob...
Subject: [python-sybase] Re: Your test program (sp_test.py) output


I keep forgetting to send to the mailing list :-(.

Bradley Feldman wrote:
> Dave:
>=20
> If I run your test program (slightly modded for my environment) on=20
> FreeTDS/MS SQL, here's what I get as output:
>=20
> {'@num': 12345, '@result': <DataBufType object at 0x2a95596770>}=20
> [54321, <DataBufType object at 0x2a95596940>]
>=20
> Attached is the debug trace.  Let me know what you discover.

Extremely odd.

The parts of the log to do with calling the stored procedure are:

Cursor.callproc
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd3

Allocated a command structure to send a command to the server.

ct_command(cmd3, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED)
-> CS_SUCCEED

Start constructing the command; use an RPC command telling the server to
  execute a stored procedure.

ct_param(cmd3, &databuf0->fmt=3D[name:"@result" type:CS_INT_TYPE
status:CS_RETURN format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf0->buff, 4, 0) -> CS_SUCCEED

Tell the command that we want to bind a buffer to receive a return =
parameter
(status =3D=3D CS_RETURN) called @result.

ct_param(cmd3, &databuf1->fmt=3D[name:"@num" type:CS_INT_TYPE
status:CS_INPUTVALUE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf1->buff, 4, 0) -> CS_SUCCEED

Tell the command that we have an input parameter called '@num'.  The =
value
is already in the associated buffer.

ct_send(cmd3) -> CS_SUCCEED

Send the command to the server.

ct_results(cmd3, &result) -> CS_SUCCEED, CS_STATUS_RESULT

Server says that there is some status returned.  We fetch this and =
discard
it.

ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt0=3D[name:"" =
type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0] ct_bind(cmd3, 1, &datafmt0->fmt=3D[name:"" type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf2->buff,
databuf2->copied, databuf2->indicator) -> CS_SUCCEED, databuf2
_fetch_rows
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_SUCCEED, 1
_fetch_rows ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) =
->
CS_END_DATA, 0

Status result has been fetched.  The next logs are where we get the
parameter results.

ct_results(cmd3, &result) -> CS_SUCCEED, CS_PARAM_RESULT

Server tells us to begin fetching the parameter result set.

ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1

There is one return parameter.

ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt1=3D[name:"@result"
type:CS_INT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1 =
maxlength:4
scale:0 precision:0]

It is called '@result' (which is what we expected).  The *really* =
strange
thing here is that the status is not CS_RETURN!!!  When I run it here =
the
status *is* CS_RETURN.  The upshot of this is that the result is ignored =
by
the code in Sybase.py

I think that a fix for this that should work all of the time is to =
change
_FetchNowParams._param_result():

     def _param_result(self):
         bufs =3D _row_bind(self._cmd, 1)
         while 1:
             status, rows_read =3D self._cmd.ct_fetch()
             if status =3D=3D CS_SUCCEED:
                 pass
             elif status =3D=3D CS_END_DATA:
                 break
             elif status in (CS_ROW_FAIL, CS_FAIL, CS_CANCELED):
                 self._raise_error(Error, 'ct_fetch')
             pos =3D -1
             for buf in bufs:
                 if buf.status & CS_RETURN:
                     if type(self._params) is type({}):
                         self._params[buf.name] =3D =
_column_value(buf[0])
                     else:
                         while 1:
                             pos +=3D 1
                             param =3D self._params[pos]
                             if (type(param) is DataBufType
                                 and param.status & CS_RETURN):
                                 break
                         self._params[pos] =3D _column_value(buf[0])

If you just remove the test for buf.status & CS_RETURN it should do the
right thing.

     def _param_result(self):
         bufs =3D _row_bind(self._cmd, 1)
         while 1:
             status, rows_read =3D self._cmd.ct_fetch()
             if status =3D=3D CS_SUCCEED:
                 pass
             elif status =3D=3D CS_END_DATA:
                 break
             elif status in (CS_ROW_FAIL, CS_FAIL, CS_CANCELED):
                 self._raise_error(Error, 'ct_fetch')
             pos =3D -1
             for buf in bufs:
                 if type(self._params) is type({}):
                     self._params[buf.name] =3D _column_value(buf[0])
                 else:
                     while 1:
                         pos +=3D 1
                         param =3D self._params[pos]
                         if (type(param) is DataBufType
                             and param.status & CS_RETURN):
                             break
                     self._params[pos] =3D _column_value(buf[0])

Let me know how it goes.

- Dave

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

_______________________________________________
Python-sybase mailing list Pyt...@ww...
https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase

RE: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

[Bradley F. <br...@re...>]

FreeTDS 0.64 isn't a stable release, yet....

0.62.4 is the last true stable release.  I'm using it on Gentoo.

*Bradley

-----Original Message-----
From: Dave Cole [mailto:dj...@ob...] 
Sent: Thursday, March 17, 2005 10:50 PM
To: pyt...@ww...
Cc: Bradley Feldman
Subject: Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter
Handling


Dave Cole wrote:
> Dave Cole wrote:
> 
>> Bradley Feldman wrote:
>>
>>> What version of FreeTDS are you using?
>>
>>
>>
>> I originally tried it using 0.61 as I am using Debian sarge.  That
>> failed in the attempt to pass a parameter.  I then downloaded the cvs 
>> snapshot freetds-0.64.dev.20050317.  It failed in the interesting way 
>> described.
>>
>> Maybe the small change in the previously posted message might work
>> around the problem in 0.62.4.
> 
> 
> I just installed FreeTDS 0.62.4 and tried with the small change to
> _FetchNowParams._param_result().
> 
> The test program now works.

Forgot to add:

I have to go home now.  I will put together a new release of the module 
over the weekend.

It appears that the 0.64 FreeTDS is going to break this again however. :-(

- Dave

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

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Dave Cole wrote:
> Dave Cole wrote:
> 
>> Bradley Feldman wrote:
>>
>>> What version of FreeTDS are you using?
>>
>>
>>
>> I originally tried it using 0.61 as I am using Debian sarge.  That 
>> failed in the attempt to pass a parameter.  I then downloaded the cvs 
>> snapshot freetds-0.64.dev.20050317.  It failed in the interesting way 
>> described.
>>
>> Maybe the small change in the previously posted message might work 
>> around the problem in 0.62.4.
> 
> 
> I just installed FreeTDS 0.62.4 and tried with the small change to 
> _FetchNowParams._param_result().
> 
> The test program now works.

Forgot to add:

I have to go home now.  I will put together a new release of the module 
over the weekend.

It appears that the 0.64 FreeTDS is going to break this again however. :-(

- Dave

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

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Dave Cole wrote:
> Bradley Feldman wrote:
> 
>> What version of FreeTDS are you using?
> 
> 
> I originally tried it using 0.61 as I am using Debian sarge.  That 
> failed in the attempt to pass a parameter.  I then downloaded the cvs 
> snapshot freetds-0.64.dev.20050317.  It failed in the interesting way 
> described.
> 
> Maybe the small change in the previously posted message might work 
> around the problem in 0.62.4.

I just installed FreeTDS 0.62.4 and tried with the small change to 
_FetchNowParams._param_result().

The test program now works.

- Dave

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

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Bradley Feldman wrote:
> What version of FreeTDS are you using?

I originally tried it using 0.61 as I am using Debian sarge.  That 
failed in the attempt to pass a parameter.  I then downloaded the cvs 
snapshot freetds-0.64.dev.20050317.  It failed in the interesting way 
described.

Maybe the small change in the previously posted message might work 
around the problem in 0.62.4.

- Dave

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

[python-sybase] Re: Your test program (sp_test.py) output

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

I keep forgetting to send to the mailing list :-(.

Bradley Feldman wrote:
> Dave:
> 
> If I run your test program (slightly modded for my environment) on
> FreeTDS/MS SQL, here's what I get as output:
> 
> {'@num': 12345, '@result': <DataBufType object at 0x2a95596770>}
> [54321, <DataBufType object at 0x2a95596940>]
> 
> Attached is the debug trace.  Let me know what you discover.

Extremely odd.

The parts of the log to do with calling the stored procedure are:

Cursor.callproc
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd3

Allocated a command structure to send a command to the server.

ct_command(cmd3, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED)
-> CS_SUCCEED

Start constructing the command; use an RPC command telling the server to
  execute a stored procedure.

ct_param(cmd3, &databuf0->fmt=[name:"@result" type:CS_INT_TYPE
status:CS_RETURN format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf0->buff, 4, 0) -> CS_SUCCEED

Tell the command that we want to bind a buffer to receive a return
parameter (status == CS_RETURN) called @result.

ct_param(cmd3, &databuf1->fmt=[name:"@num" type:CS_INT_TYPE
status:CS_INPUTVALUE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf1->buff, 4, 0) -> CS_SUCCEED

Tell the command that we have an input parameter called '@num'.  The
value is already in the associated buffer.

ct_send(cmd3) -> CS_SUCCEED

Send the command to the server.

ct_results(cmd3, &result) -> CS_SUCCEED, CS_STATUS_RESULT

Server says that there is some status returned.  We fetch this and
discard it.

ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt0=[name:""
type:CS_INT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1
maxlength:4 scale:0 precision:0]
ct_bind(cmd3, 1, &datafmt0->fmt=[name:"" type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf2->buff,
databuf2->copied, databuf2->indicator) -> CS_SUCCEED, databuf2
_fetch_rows
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> CS_SUCCEED, 1
_fetch_rows
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) ->
CS_END_DATA, 0

Status result has been fetched.  The next logs are where we get the
parameter results.

ct_results(cmd3, &result) -> CS_SUCCEED, CS_PARAM_RESULT

Server tells us to begin fetching the parameter result set.

ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1

There is one return parameter.

ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt1=[name:"@result"
type:CS_INT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1
maxlength:4 scale:0 precision:0]

It is called '@result' (which is what we expected).  The *really*
strange thing here is that the status is not CS_RETURN!!!  When I run it
here the status *is* CS_RETURN.  The upshot of this is that the result
is ignored by the code in Sybase.py

I think that a fix for this that should work all of the time is to
change _FetchNowParams._param_result():

     def _param_result(self):
         bufs = _row_bind(self._cmd, 1)
         while 1:
             status, rows_read = self._cmd.ct_fetch()
             if status == CS_SUCCEED:
                 pass
             elif status == CS_END_DATA:
                 break
             elif status in (CS_ROW_FAIL, CS_FAIL, CS_CANCELED):
                 self._raise_error(Error, 'ct_fetch')
             pos = -1
             for buf in bufs:
                 if buf.status & CS_RETURN:
                     if type(self._params) is type({}):
                         self._params[buf.name] = _column_value(buf[0])
                     else:
                         while 1:
                             pos += 1
                             param = self._params[pos]
                             if (type(param) is DataBufType
                                 and param.status & CS_RETURN):
                                 break
                         self._params[pos] = _column_value(buf[0])

If you just remove the test for buf.status & CS_RETURN it should do the
right thing.

     def _param_result(self):
         bufs = _row_bind(self._cmd, 1)
         while 1:
             status, rows_read = self._cmd.ct_fetch()
             if status == CS_SUCCEED:
                 pass
             elif status == CS_END_DATA:
                 break
             elif status in (CS_ROW_FAIL, CS_FAIL, CS_CANCELED):
                 self._raise_error(Error, 'ct_fetch')
             pos = -1
             for buf in bufs:
                 if type(self._params) is type({}):
                     self._params[buf.name] = _column_value(buf[0])
                 else:
                     while 1:
                         pos += 1
                         param = self._params[pos]
                         if (type(param) is DataBufType
                             and param.status & CS_RETURN):
                             break
                     self._params[pos] = _column_value(buf[0])

Let me know how it goes.

- Dave

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

RE: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

[Bradley F. <br...@re...>]

What version of FreeTDS are you using?

I'm not seeing any errors like that at all.  I'm using FreeTDS 0.62.4.  =
See
below:

Cursor.callproc
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd3
ct_command(cmd3, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED) =
->
CS_SUCCEED
ct_param(cmd3, &databuf0->fmt=3D[name:"@result" type:CS_INT_TYPE
status:CS_RETURN format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf0->buff, 4, 0) -> CS_SUCCEED
ct_param(cmd3, &databuf1->fmt=3D[name:"@num" type:CS_INT_TYPE
status:CS_INPUTVALUE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf1->buff, 4, 0) -> CS_SUCCEED
ct_send(cmd3) -> CS_SUCCEED
ct_results(cmd3, &result) -> CS_SUCCEED, CS_STATUS_RESULT
ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt0=3D[name:"" =
type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0]
ct_bind(cmd3, 1, &datafmt0->fmt=3D[name:"" type:CS_INT_TYPE =
status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf2->buff, databuf2->copied, databuf2->indicator) -> CS_SUCCEED,
databuf2
_fetch_rows
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_SUCCEED, 1
_fetch_rows
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_END_DATA,
0
ct_results(cmd3, &result) -> CS_SUCCEED, CS_PARAM_RESULT
ct_res_info(cmd3, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd3, 1, &fmt) -> CS_SUCCEED, datafmt1=3D[name:"@result"
type:CS_INT_TYPE status:CS_FALSE format:CS_FMT_UNUSED count:1 =
maxlength:4
scale:0 precision:0]
ct_bind(cmd3, 1, &datafmt1->fmt=3D[name:"@result" type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0], databuf3->buff, databuf3->copied, databuf3->indicator) ->
CS_SUCCEED, databuf3
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_SUCCEED, 1
ct_fetch(cmd3, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_END_DATA,
0
ct_results(cmd3, &result) -> CS_SUCCEED, CS_CMD_SUCCEED
ct_results(cmd3, &result) -> CS_SUCCEED, CS_CMD_DONE
ct_results(cmd3, &result) -> CS_END_RESULTS, CS_FALSE
{'@num': 12345, '@result': <DataBufType object at 0x2a95596770>}
Cursor.callproc
ct_cmd_drop(cmd3) -> CS_SUCCEED
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd4
ct_command(cmd4, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED) =
->
CS_SUCCEED
ct_param(cmd4, &databuf5->fmt=3D[name:"" type:CS_INT_TYPE =
status:CS_INPUTVALUE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf5->buff, 4, 0) -> CS_SUCCEED
ct_param(cmd4, &databuf4->fmt=3D[name:"" type:CS_INT_TYPE =
status:CS_RETURN
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf4->buff, 4, 0) -> CS_SUCCEED
ct_send(cmd4) -> CS_SUCCEED
ct_results(cmd4, &result) -> CS_SUCCEED, CS_STATUS_RESULT
ct_res_info(cmd4, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd4, 1, &fmt) -> CS_SUCCEED, datafmt2=3D[name:"" =
type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0]
ct_bind(cmd4, 1, &datafmt2->fmt=3D[name:"" type:CS_INT_TYPE =
status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf6->buff, databuf6->copied, databuf6->indicator) -> CS_SUCCEED,
databuf6
_fetch_rows
ct_fetch(cmd4, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_SUCCEED, 1
_fetch_rows
ct_fetch(cmd4, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_END_DATA,
0
ct_results(cmd4, &result) -> CS_SUCCEED, CS_PARAM_RESULT
ct_res_info(cmd4, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 1
ct_describe(cmd4, 1, &fmt) -> CS_SUCCEED, datafmt3=3D[name:"" =
type:CS_INT_TYPE
status:CS_FALSE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0
precision:0]
ct_bind(cmd4, 1, &datafmt3->fmt=3D[name:"" type:CS_INT_TYPE =
status:CS_FALSE
format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 precision:0],
databuf7->buff, databuf7->copied, databuf7->indicator) -> CS_SUCCEED,
databuf7
ct_fetch(cmd4, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_SUCCEED, 1
ct_fetch(cmd4, CS_UNUSED, CS_UNUSED, CS_UNUSED, &rows_read) -> =
CS_END_DATA,
0
ct_results(cmd4, &result) -> CS_SUCCEED, CS_CMD_SUCCEED
ct_results(cmd4, &result) -> CS_SUCCEED, CS_CMD_DONE
ct_results(cmd4, &result) -> CS_END_RESULTS, CS_FALSE
[54321, <DataBufType object at 0x2a95596940>]
ct_cmd_drop(cmd4) -> 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

-----Original Message-----
From: pyt...@ww...
[mailto:pyt...@ww...] On Behalf Of Dave =
Cole
Sent: Thursday, March 17, 2005 10:00 PM
To: pyt...@ww...
Subject: Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter
Handling


Dave Cole wrote:
> Dave Cole <dj...@ob...>Dave Cole
> <dj...@ob...>Dave Cole wrote:
>=20
>> I just installed ASE 12.5.2 on my machine so I could do some testing.
>> It appears there is a problem with the Cursor.callproc() method, but=20
>> only when you use a sequence to pass parameters.  Dictionary=20
>> parameters are fine.
>>
>> The attached sp_test.py program shows my testing.
>>
>> This program produces the following output (after applying the
>> attached callproc.patch to fix sequence argument passing).
>>
>> {'@num': 12345, '@result': 12345}
>> [54321, 54321]
>>
>> If I remove the comment character from the code that enables the
>> debugging I get the output contained in the attached sp_test.log.
>>
>> So if it is not working with FreeTDS then they are doing something
>> slightly differently that is either confusing my code or is =
incorrect.
>=20
>=20
> I just installed FreeTDS 0.61 (Debian sarge) and the test program=20
> fails
> to run.  The ct_param() functions fail.  What I did discover was that=20
> you can fudge it like this:
>=20
> print db.execute('''
> declare @result int
> exec sp_test_output 12345, @result output
> select @result
> ''')
>=20
> It prints the following:
> [[], [(12345,)]]
>=20
> I am now downloading the current cvs snapshot for FreeTDS to see if=20
> they
> have fixed parameter passing.

I just downloaded and installed the CVS snapshot.  With the original=20
test program it appears to send the parameters to the server but fails=20
with a server message.

Looking at the debug log:

Cursor.callproc
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd3
ct_command(cmd3, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED)=20
-> CS_SUCCEED
ct_param(cmd3, &databuf0->fmt=3D[name:"@result" type:CS_INT_TYPE=20
status:CS_RETURN format:CS_FMT_UNUSED count:1 maxlength:4 scale:0=20
precision:0], databuf0->buff, 4, 0) -> CS_SUCCEED ct_param(cmd3,
&databuf1->fmt=3D[name:"@num" type:CS_INT_TYPE=20
status:CS_INPUTVALUE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0=20
precision:0], databuf1->buff, 4, 0) -> CS_SUCCEED


So it appears that parameters are being accepted by FreeTDS but from the =

next debug lines, they are not being sent correctly.


ct_send(cmd3) -> CS_SUCCEED
servermsg_cb
Msg 245, Level 16, State 1, Procedure sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT =
field.
servermsg_cb Msg 245, Level 16, State 1, Procedure sp_test_output Domain
error during implicit conversion of DECIMAL value '' to a INT field.
ct_results(cmd3, &result) -> CS_SUCCEED, CS_STATUS_RESULT =
ct_cancel(conn0,
NULL, CS_CANCEL_ALL) -> CS_SUCCEED Traceback (most recent call last):
   File "a.py", line 21, in ?
     r =3D c.callproc('sp_test_output', {'@num': 12345, '@result':=20
Sybase.OUTPUT(1)})
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 718, in =
callproc
     self.description =3D fetcher.start(self.arraysize, out_params)
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 391, in start
     return _FetchNow.start(self, arraysize)
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 315, in start
     raise e
Sybase.DatabaseError: Msg 245, Level 16, State 1, Procedure =
sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT =
field.
Msg 245, Level 16, State 1, Procedure sp_test_output Domain error during
implicit conversion of DECIMAL value '' to a INT field.

Even more worrying is that the fudge in the previous message no longer=20
works.  I get crap back.

Oh well, looks like I can wait for another couple of FreeTDS releases=20
before trying again...

- Dave

--=20
http://www.object-craft.com.au
_______________________________________________
Python-sybase mailing list Pyt...@ww...
https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Dave Cole wrote:
> Dave Cole <dj...@ob...>Dave Cole 
> <dj...@ob...>Dave Cole wrote:
> 
>> I just installed ASE 12.5.2 on my machine so I could do some testing. 
>> It appears there is a problem with the Cursor.callproc() method, but 
>> only when you use a sequence to pass parameters.  Dictionary 
>> parameters are fine.
>>
>> The attached sp_test.py program shows my testing.
>>
>> This program produces the following output (after applying the 
>> attached callproc.patch to fix sequence argument passing).
>>
>> {'@num': 12345, '@result': 12345}
>> [54321, 54321]
>>
>> If I remove the comment character from the code that enables the 
>> debugging I get the output contained in the attached sp_test.log.
>>
>> So if it is not working with FreeTDS then they are doing something 
>> slightly differently that is either confusing my code or is incorrect.
> 
> 
> I just installed FreeTDS 0.61 (Debian sarge) and the test program fails 
> to run.  The ct_param() functions fail.  What I did discover was that 
> you can fudge it like this:
> 
> print db.execute('''
> declare @result int
> exec sp_test_output 12345, @result output
> select @result
> ''')
> 
> It prints the following:
> [[], [(12345,)]]
> 
> I am now downloading the current cvs snapshot for FreeTDS to see if they 
> have fixed parameter passing.

I just downloaded and installed the CVS snapshot.  With the original 
test program it appears to send the parameters to the server but fails 
with a server message.

Looking at the debug log:

Cursor.callproc
ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd3
ct_command(cmd3, CS_RPC_CMD, "sp_test_output", CS_NULLTERM, CS_UNUSED) 
-> CS_SUCCEED
ct_param(cmd3, &databuf0->fmt=[name:"@result" type:CS_INT_TYPE 
status:CS_RETURN format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 
precision:0], databuf0->buff, 4, 0) -> CS_SUCCEED
ct_param(cmd3, &databuf1->fmt=[name:"@num" type:CS_INT_TYPE 
status:CS_INPUTVALUE format:CS_FMT_UNUSED count:1 maxlength:4 scale:0 
precision:0], databuf1->buff, 4, 0) -> CS_SUCCEED


So it appears that parameters are being accepted by FreeTDS but from the 
next debug lines, they are not being sent correctly.


ct_send(cmd3) -> CS_SUCCEED
servermsg_cb
Msg 245, Level 16, State 1, Procedure sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT field.
servermsg_cb
Msg 245, Level 16, State 1, Procedure sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT field.
ct_results(cmd3, &result) -> CS_SUCCEED, CS_STATUS_RESULT
ct_cancel(conn0, NULL, CS_CANCEL_ALL) -> CS_SUCCEED
Traceback (most recent call last):
   File "a.py", line 21, in ?
     r = c.callproc('sp_test_output', {'@num': 12345, '@result': 
Sybase.OUTPUT(1)})
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 718, in callproc
     self.description = fetcher.start(self.arraysize, out_params)
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 391, in start
     return _FetchNow.start(self, arraysize)
   File "/usr/lib/python2.3/site-packages/Sybase.py", line 315, in start
     raise e
Sybase.DatabaseError: Msg 245, Level 16, State 1, Procedure sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT field.
Msg 245, Level 16, State 1, Procedure sp_test_output
Domain error during implicit conversion of DECIMAL value '' to a INT field.

Even more worrying is that the fudge in the previous message no longer 
works.  I get crap back.

Oh well, looks like I can wait for another couple of FreeTDS releases 
before trying again...

- Dave

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

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Dave Cole <dj...@ob...>Dave Cole 
<dj...@ob...>Dave Cole wrote:
> I just installed ASE 12.5.2 on my machine so I could do some testing. It 
> appears there is a problem with the Cursor.callproc() method, but only 
> when you use a sequence to pass parameters.  Dictionary parameters are 
> fine.
> 
> The attached sp_test.py program shows my testing.
> 
> This program produces the following output (after applying the attached 
> callproc.patch to fix sequence argument passing).
> 
> {'@num': 12345, '@result': 12345}
> [54321, 54321]
> 
> If I remove the comment character from the code that enables the 
> debugging I get the output contained in the attached sp_test.log.
> 
> So if it is not working with FreeTDS then they are doing something 
> slightly differently that is either confusing my code or is incorrect.

I just installed FreeTDS 0.61 (Debian sarge) and the test program fails 
to run.  The ct_param() functions fail.  What I did discover was that 
you can fudge it like this:

print db.execute('''
declare @result int
exec sp_test_output 12345, @result output
select @result
''')

It prints the following:
[[], [(12345,)]]

I am now downloading the current cvs snapshot for FreeTDS to see if they 
have fixed parameter passing.

- Dave

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

Re: [python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

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

Bradley Feldman wrote:
> On a hunch, I reverted back to the original FreeTDS (0.62.4) I was using
> that works with the Sybase 0.63 module.  I then tried the same test within
> tsql:
> 
> 1>DECLARE @ReturnValue int
> 2>SELECT @ReturnValue = 3
> 3>EXEC sp_TestSproc 12345, @ReturnValue OUTPUT
> 4>SELECT @ReturnValue
> 5>go
> (return status = 0)
> 
> 55
> ---------------------------
> 
> I got the correct result, @ReturnValue of 55.   So there's something wrong
> with the handling of output parameters within the Sybase 0.36 module,
> because tsql through FreeTDS is seeing everything correctly.
> 
> Anyone have any other ideas on where/how to retrieve the value of output
> parameters using callproc in the Sybase 0.36 module?

I just installed ASE 12.5.2 on my machine so I could do some testing. 
It appears there is a problem with the Cursor.callproc() method, but 
only when you use a sequence to pass parameters.  Dictionary parameters 
are fine.

The attached sp_test.py program shows my testing.

This program produces the following output (after applying the attached 
callproc.patch to fix sequence argument passing).

{'@num': 12345, '@result': 12345}
[54321, 54321]

If I remove the comment character from the code that enables the 
debugging I get the output contained in the attached sp_test.log.

So if it is not working with FreeTDS then they are doing something 
slightly differently that is either confusing my code or is incorrect.

- Dave

P.S.  All username and password details have been removed.

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

[python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

[Bradley F. <br...@re...>]

On a hunch, I reverted back to the original FreeTDS (0.62.4) I was using
that works with the Sybase 0.63 module.  I then tried the same test within
tsql:

1>DECLARE @ReturnValue int
2>SELECT @ReturnValue = 3
3>EXEC sp_TestSproc 12345, @ReturnValue OUTPUT
4>SELECT @ReturnValue
5>go
(return status = 0)

55
---------------------------

I got the correct result, @ReturnValue of 55.   So there's something wrong
with the handling of output parameters within the Sybase 0.36 module,
because tsql through FreeTDS is seeing everything correctly.

Anyone have any other ideas on where/how to retrieve the value of output
parameters using callproc in the Sybase 0.36 module?

Thanks in advance,

*Bradley

[python-sybase] RE: Sybase Module 0.36 Output Parameter Handling

[Bradley F. <br...@re...>]

I tried the code Dave (and Skip) suggested, but I still can't seem to =
find
the value of the returned parameters, even through fetchall/nextset =
calls.
Also, using a debugger I don't see anything being passed back to the buf
object.

I'm wondering if the issue has something to do that I'm using Sybase =
0.36
module with FreeTDS 0.62 and MS SQL Server 2000.  I'm assuming that it =
all
works on Sybase 9.0 and that it's Microsoft munging everything up.

So, I tried to upgrade to a later version of FreeTDS (0.63 or higher)-- =
I
read somewhere that later version is handling output parameters better.
Everything is now built straight from source.  When I fire up python and =
try
to "import Sybase" I get an error saying "Import Error: libct.so.2 - =
cannot
open shared object file"  Upon further investigation I see that FreeTDS
0.63+ does not produce a libct.so.2 -- only a libct.so.3.

So, is there something that can be easily fixed within Sybase module to =
link
with libct.so.3 instead of libct.so.2?

BTW, Here's a test I performed to see if the new FreeTDS and MS SQL =
Server
are communicating properly:

--------------------------------
FreeTDS Version 0.64.dev.20050317

Using tsql with the following simple example:

1>DECLARE @ReturnValue int
2>SELECT @ReturnValue =3D 3
3>EXEC sp_TestSproc 12345, @ReturnValue OUTPUT
4>SELECT @ReturnValue
5>go
(return status =3D 0)

55
---------------------------

So that proves that FreeTDS and tsql are passing and returning =
parameters
correctly to/from MS SQL Server 2000 because the value of @ReturnValue =
is
changed from 3 to 55 upon execution of the Stored Procedure.

All I need now is instructions for how to see the return value using the
Python Sybase 0.36 module and I'm good to go!

Any ideas from anyone?

*Bradley

[python-sybase] Re: Question about Sybase Module 0.36 Output Parameter Handling

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

Ooops - forgot to respond to the list as well...

Bradley Feldman wrote:

 > Hi Dave:
 >
 > Thanks so much for providing your great Sybase module for Python!  I've
 > installed it and it works great so far.


Thanks for the response.

 > I have a question about the handling of Output Parms which is a new 
feature
 > of 0.36.  I understand how to pass the output parm syntax to the database
 > within the callproc as given in the release notes, but how to I see the
 > value passed back?  This seems simple, but there is no example of 
evaluating
 > the resulting parameter and I can't seem to figure it out.


The problem is due to a shortcoming in the Sybase CT library.  There is 
no way to ask the library whether parameters to a query are input or 
output.  If you get it wrong then the query fails.  So in the absence of 
a way to automatically determine the direction of an argument, the user 
must tell the module.

The OUTPUT() function uses the passed value to construct a buffer that 
will accept a value of the same type from the Sybase CT library in 
response to a query.

 > For example, you give:
 >
 > C.callproc ('testproc', {'@parm1': 'value1', '@outputparm':
 > Sybase.OUTPUT(1)})
 >
 > If I print the callproc object after it executes I get back something 
like:
 > {'@parm1':'value1','@outputparm': <DataBufType object at 0x2a394999>}


This is showing you the parameters that will be passed to the CT 
library.  The results will not be available until you try to fetch 
results from the cursor.

 > So how to I examine the contents of the DataBufType object, using 
python db
 > api syntax?


The result should come back as a row via the fetchone() method on the 
cursor.

 > Finally, what does the "1" in Sybase.OUTPUT(1) mean?   A buffer size of 1
 > byte?  A value of 1 contained in one byte?  Can I simply pass a variable
 > reference instead, such as Sybase.OUTPUT(thisVar)?


This is not explained in the documentation.  It probably should be I 
suppose.

Communication with the Sybase server is via the CT library.  The CT 
library uses two objects for passing values to, and accepting values 
from the server; a CS_DATAFMT structure, and a data buffer.  The 
CS_DATAFMT structure describes (among other things) the type, size, and 
direction of a related data buffer.  The data buffer is simply a pointer 
to an area of memory that matches the description in the CS_DATAFMT.

For passing values to Sybase all you need to do is place the value in a 
data buffer and describe it using a CS_DATAFMT.  You can see this in 
operation in the Cursor.callproc() method.  It takes plain values and 
places them in a data buffer via DataBuf() constructor.

      buf = DataBuf(value)

The DataBuf object contains an embedded CS_DATAFMT structure that is 
initialised using the type and size of the Python object that was passed 
to the constructor.  It also contains an allocated area of memory into 
which the value passed to the constructor is copied.

      buf.name = name

After constructing The Cursor.callproc() method then assigns the 
specified parameter name to the .name member of the DataBuf.  This is 
sufficient to create the CS_DATAFMT and data buffer to pass a parameter 
to Sybase.

      cmd.ct_param(buf)


As mentioned above, Sybase does not provide any mechanism to query the 
CT Library about whether a parameter to a stored procedure is for input 
or output.  If you get it wrong then the query will fail.  To get around 
this, the OUTPUT() function establishes a DataBuf object in the same way 
as the Cursor.callproc() method, but then in addition, sets the .status 
attribute of the embedded CS_DATAFMT to CS_RETURN.  This tells Sybase 
that the buffer is intended to receive a return value from the query 
rather than pass a value to the query.


For column values returned by plain queries the Sybase module asks the 
Sybase CT Library the format of each column and then constructs a 
DataBuf to receive that value.  The _row_bind() function in the Sybase 
module shows this:

     cmd.ct_res_info(CS_NUMDATA)

Asks CT how many columns are in the query result.

     cmd.ct_describe(i + 1)

Asks CT to describe one of the columns.  The second return value is a 
CS_DATAFMT object.

     cmd.ct_bind(i + 1, fmt)

This constructs a DataBuf from the CS_DATAFMT and tells CT to bind the 
specified column to the area of memory in the DataBuf.  The second 
return value is the constructed DataBuf object.


So after all of that, if you want to be a bit more direct in 
constructing output parameter buffers to stored procedures you do use 
something like this:

fmt = Sybase.CS_DATAFMT()
fmt.datatype = Sybase.CS_VARCHAR_TYPE
fmt.maxlength = 1024
fmt.count = 1
buf = Sybase.DataBuf(fmt)
buf.status = Sybase.CS_RETURN

The buf can then be passed like this:

  C.callproc ('testproc', {'@parm1': 'value1', '@outputparm': buf})

As explained above, the return parameter should be available as a normal 
row returned using one of the Cursor.fetch*() methods.

Note that when you fiddle with DataBuf objects you must hold a reference 
to that buffer until the CT library has finished using the memory in the 
buffer.  This is transparently done for you by the code in Sybase.py.

If you start programming directly to the sybasect extension module then 
you will need to manage your own DataBuf references.

 > Thanks so much for your help, in advance.


No problem.  Is a distraction from the work I am supposed to be doing :-) .

- Dave

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

Re: [python-sybase] Sybase Module 0.36 Output Parameter Handling

[Skip M. <sk...@po...>]

    Bradley> For example:

    Bradley> C.callproc ('testproc', {'@parm1': 'value1', '@outputparm':
    Bradley> Sybase.OUTPUT(1)})

    Bradley> If I print the callproc object after it executes I get back
    Bradley> something like: {'@parm1':'value1','@outputparm': <DataBufType
    Bradley> object at 0x2a394999>}

    Bradley> So how to I examine the contents of the DataBufType object,
    Bradley> using python db api syntax?

I think it's returned by a subsequent call to C.fetchall().  A stored
procedure can return the result of multiple selects so you need to keep
asking the cursor if there are more result sets and call fetchall() as long
as there are:

        while True:
           rows = C.fetchall()
           print rows
           if not C.nextset():
               break

    Bradley> Finally, what does the "1" in Sybase.OUTPUT(1) mean?  

I don't recall.  Someone else will have to chime in.

Skip

[python-sybase] Sybase Module 0.36 Output Parameter Handling

[Bradley F. <br...@br...>]

I have a question about the handling of Output Parms which is a new =
feature
of 0.36.  I understand how to pass the output parm syntax to the =
database
within the callproc as given in the release notes, but how to I see the
value passed back?  This seems simple, but there is no example of =
evaluating
the resulting parameter and I can't seem to figure it out.

For example:

C.callproc ('testproc', {'@parm1': 'value1', '@outputparm':
Sybase.OUTPUT(1)})

If I print the callproc object after it executes I get back something =
like:
{'@parm1':'value1','@outputparm': <DataBufType object at 0x2a394999>}

So how to I examine the contents of the DataBufType object, using python =
db
api syntax?

Finally, what does the "1" in Sybase.OUTPUT(1) mean?   A buffer size of =
1
byte?  A value of 1 contained in one byte?  Can I simply pass a variable
reference instead, such as Sybase.OUTPUT(thisVar)?

Thanks so much for your help, in advance.

*Bradley

Re: [python-sybase] GTK & Sybase

[Andrew M. <an...@ob...>]

>Probably related to this:
>
>This is one of the new things in Python 2.4. Now there is a
>locale-independent (C locale) way of treating numbers. I bet the module
>has to be adapted to this change to take advantage of this fact (and
>letting users choose their own locale without breaking apps).
>
>http://www.python.org/doc/2.4/whatsnew/node11.html

It's certainly related, but I don't think the 2.4 changes were the cause.

What is almost certainly happening is that GTK is changing the locale,
which effects the conversion within the python-sybase modules C code.

If python-sybase used the new interface (when available), that would
hopefully eliminate this problem. Someone who uses locales want to find
the offending conversions and post a patch?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] GTK & Sybase

[<se...@en...>]

This locale feature is started on 19-Jul-2003 in PEP 331, the latest
Sybase module is created on 27-Apr-2003. I think it's not use this
feature yet.

Anyway, I wrote my own converter.
It's ugly solution and maybe slow, but it's works...


def sybase_num_to_python_float(sybase_num):
    if sybase_num == None:
        return None

    elif not '.' in str(sybase_num):
        return int(sybase_num)

    else:
        if '-' in str(sybase_num):
            negative = True
            whole,decimal = str(sybase_num).replace('-','').split('.')
        else:
            negative = False
            whole,decimal = str(sybase_num).split('.')

        value = float(whole) + float(decimal) / (10 ** len(decimal))

        if negative: value = - value
        return value


Norbert Sebok

>Probably related to this:
>
>This is one of the new things in Python 2.4. Now there is a
>locale-independent (C locale) way of treating numbers. I bet the module
>has to be adapted to this change to take advantage of this fact (and
>letting users choose their own locale without breaking apps).
>
>http://www.python.org/doc/2.4/whatsnew/node11.html
>
>Andrew McNamara dijo:
>  
>
>>>I have some problem, when I use Sybase module with GTK:
>>>
>>> cursor.execute(" select 1.2 ")
>>> num = cursor.fetchone()[0]
>>> print num           # 1.2
>>> print float(1.2)    # 1.2
>>> print float(num)    # 1.2
>>>
>>> import gtk
>>> print num           # 1.2
>>> print float(1.2)    # 1.2
>>> print float(num)    # 1.0  <- not 1.2
>>>
>>>
>>>After import gtk, the float truncates the decimal.
>>>How can I fix this?
>>>      
>>>
>>This is a shot in the dark, but could gtk be setting the locale?
>>
>>It might also be useful to print the type of num, eg:
>>
>>    print type(num)
>>    
>>

Re: [python-sybase] GTK & Sybase

[Marcos <ma...@bu...>]

Probably related to this:

This is one of the new things in Python 2.4. Now there is a
locale-independent (C locale) way of treating numbers. I bet the module
has to be adapted to this change to take advantage of this fact (and
letting users choose their own locale without breaking apps).

http://www.python.org/doc/2.4/whatsnew/node11.html

Andrew McNamara dijo:
>>I have some problem, when I use Sybase module with GTK:
>>
>>  cursor.execute(" select 1.2 ")
>>  num = cursor.fetchone()[0]
>>  print num           # 1.2
>>  print float(1.2)    # 1.2
>>  print float(num)    # 1.2
>>
>>  import gtk
>>  print num           # 1.2
>>  print float(1.2)    # 1.2
>>  print float(num)    # 1.0  <- not 1.2
>>
>>
>>After import gtk, the float truncates the decimal.
>>How can I fix this?
>
> This is a shot in the dark, but could gtk be setting the locale?
>
> It might also be useful to print the type of num, eg:
>
>     print type(num)
>

Re: [python-sybase] GTK & Sybase

[Andrew M. <an...@ob...>]

>I have some problem, when I use Sybase module with GTK:
>
>  cursor.execute(" select 1.2 ")
>  num = cursor.fetchone()[0]
>  print num           # 1.2
>  print float(1.2)    # 1.2
>  print float(num)    # 1.2
>
>  import gtk
>  print num           # 1.2
>  print float(1.2)    # 1.2
>  print float(num)    # 1.0  <- not 1.2
>
>
>After import gtk, the float truncates the decimal.
>How can I fix this?

This is a shot in the dark, but could gtk be setting the locale?

It might also be useful to print the type of num, eg:

    print type(num)

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

[python-sybase] GTK & Sybase

[<se...@en...>]

Hi!

I have some problem, when I use Sybase module with GTK:

  cursor.execute(" select 1.2 ")
  num = cursor.fetchone()[0]
  print num           # 1.2
  print float(1.2)    # 1.2
  print float(num)    # 1.2

  import gtk
  print num           # 1.2
  print float(1.2)    # 1.2
  print float(num)    # 1.0  <- not 1.2


After import gtk, the float truncates the decimal.
How can I fix this?

Thanks,
Norbert Sebok

Re: [python-sybase] python sybase installation

[Gregory B. <gn...@it...>]

Andrew McNamara wrote:

>Ta. That's what I suspected. Is it using LD_LIBRARY_PATH in that case, or
>some other environment variable 
>
It uses LD_LIBRARY_PATH, because that's what the SYBASE.sh script sets.

(I think the dlopen is for the transport stuff, so at connect time it 
dynamically links the appropriate transport library.)

Re: [python-sybase] python sybase installation

[Andrew M. <an...@ob...>]

>>Hmmm - either it statically linked with the sybase client lib, or it's
>>pulling in shared libs by hand. Anyone on the list have a better idea
>>what it's up to?
>
>The sybase  libs do dlopen() (or equiv) to link some of their libraries 
>at connect time, so ldd doesn't help much. You've pretty much gotta have 
>the correct LD_LIBRARY_PATH at runtime.

Ta. That's what I suspected. Is it using LD_LIBRARY_PATH in that case, or
some other environment variable (if they're using dlopen(), they can take
their choice)?

Anyway, strace should reveal if it's coming off the rails and pulling in an
old version of the lib.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] python sybase installation

[Gregory B. <gn...@it...>]

Andrew McNamara wrote:

>Hmmm - either it statically linked with the sybase client lib, or it's
>pulling in shared libs by hand. Anyone on the list have a better idea
>what it's up to?
>
>
>  
>
The sybase  libs do dlopen() (or equiv) to link some of their libraries 
at connect time, so ldd doesn't help much. You've pretty much gotta have 
the correct LD_LIBRARY_PATH at runtime.

Re: [python-sybase] python sybase installation

[Andrew M. <an...@ob...>]

>Here's the output.. looks good?
>
>[ajt@scratch ajt]$
>ldd /usr/local/lib/python2.4/site-packages/sybasect.so
>        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004c9000)
>        libc.so.6 => /lib/tls/libc.so.6 (0x00e6a000)
>        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x008af000)
>
>I also did it for my 2.2 installation..
>
>[ajt@scratch ajt]$ ldd /usr/lib/python2.2/site-packages/sybasect.so
>        libc.so.6 => /lib/tls/libc.so.6 (0x0070b000)
>        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00a14000)
>
>Looks exciting! ;)

Hmmm - either it statically linked with the sybase client lib, or it's
pulling in shared libs by hand. Anyone on the list have a better idea
what it's up to?

You might want to try running strace (linux) or truss (solaris) on python
as it starts. Something like:

    strace -o /tmp/trace.out -f python -ic "import Sybase"

The contents of trace.out will be too large to post to the list, but
reading through it might give some clues as to how it's pulling in the
client libs. Jump to where it's reading sybasect.so and see what happens
after that.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] python sybase installation

[Andrew T. <and...@ap...>]

On Mon, 2005-02-14 at 15:42 +1100, Andrew McNamara wrote:
> What does the output of:
> 
>  $ ldd /usr/local/lib/python2.4/site-packages/sybasect.so
> 
> look like?

Andrew,

Here's the output.. looks good?

[ajt@scratch ajt]$
ldd /usr/local/lib/python2.4/site-packages/sybasect.so
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004c9000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00e6a000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x008af000)

I also did it for my 2.2 installation..

[ajt@scratch ajt]$ ldd /usr/lib/python2.2/site-packages/sybasect.so
        libc.so.6 => /lib/tls/libc.so.6 (0x0070b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00a14000)

Looks exciting! ;)

Regards,

ajt.

> 
> I know very little about Sybase (I don't have it installed, either),
> but I've been working with the dynamic linkers under Linux (and Solaris)
> for years. I've seen this specific problem mentioned on the list a few
> times, but I can't find a solution in the list archives. The error is
> more suggestive of an incorrect library version, rather than a missing
> file, so pay careful attention to the paths.
> 
> You can also use ldd to explore the shared dependancies of any other
> libraries being used by sybasect.so.
> 
-- 
Andrew Thomson <and...@ap...>