python-sybase-misc

Re: [python-sybase] NumericType not hashable?

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

> By the looks of it, NumericType is not python hash table friendly.

It should be...  Can you tell us how you built the module and which
platform you are using?

This is what happens when I try using the hash functionality:

>>> import Sybase
>>> n = Sybase.numeric(2)
>>> type(n)
<type 'NumericType'>
>>> d = {n: 'two' }
>>> d[2] 
'two'
>>> m = Sybase.numeric(3L)
>>> d[m] = 'three'
>>> d[3]
'three'
>>> o = Sybase.numeric('4')
>>> d[o] = 'four'
>>> d[4]
'four'

With my new 0.35pre1 callback error handling I now have problems with
longs...

>>> m = Sybase.numeric(1231312313123133L)
>>> m
1231312313123133
>>> hash(m)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "Sybase.py", line 133, in _cslib_cb
    raise Error(_fmt_client(msg))
Sybase.Error: Layer: 2, Origin: 4
cs_convert: cslib user api layer: common library error: The conversion/operation resulted in overflow.

The numeric hash calculation tries to convert to an integer first in
order to work out an integer compatible hash.  So it looks like I am
going to have to create a fully internal CS_CONTEXT for doing things
which I know might fail - such as attempts to convert NumericType to
integer before doing a conversion to string then to long in order to
calculate the hash.

> That means that something like:
> 
> c.execute('select id, limit_id, name from Sublimit_cvt')
> rows = c.fetchall()
> for row in rows:
>     id, limit_id, name = row
> 
> c.execute('select id from MyTable')
> rows = c.fetchall()
> for row in rows:
>   id = row[0]
>   print map[id]
> 
> 
> will fail if id is of type AutomaticID in Sybase.
> 
> I'm not sure if this is required by DB API, but I think it violates
> the principle of least surprise.

can you try doing something like this:

c.execute('select id, limit_id, name from Sublimit_cvt')
rows = c.fetchall()
for row in rows:
    id, limit_id, name = row
    print id, type(id), hash(id)


> My workaround was to force a conversion to string, so my code now
> reads map[str(id)]. But maybe NumericType should be modified to act
> as any number when used as a hash key?  Any opinions?

It Already Does (TM) so I suspect there is something else going on,
maybe related to the compilation.

- Dave

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

[python-sybase] NumericType not hashable?

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

Hi,

By the looks of it, NumericType is not python hash table friendly.

That means that something like:

c.execute('select id, limit_id, name from Sublimit_cvt')
rows = c.fetchall()
for row in rows:
    id, limit_id, name = row

c.execute('select id from MyTable')
rows = c.fetchall()
for row in rows:
  id = row[0]
  print map[id]


will fail if id is of type AutomaticID in Sybase.

I'm not sure if this is required by DB API, but I think it violates the
principle of least surprise.

My workaround was to force a conversion to string, so my code now reads
map[str(id)]. But maybe NumericType should be modified to act as any number
when used as a hash key?  Any opinions?

-Harri

[python-sybase] Sybase module 0.35pre1 released

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

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

Notes:

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

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

FreeTDS support is much improved in this version.  You will still
experience segfaults while using FreeTDS though.  These issues are
still being worked on.

For the adventurous, 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/sybase-0.35pre1.tar.gz

The module home page is here:

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

- Dave

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

Re: [python-sybase] Working on the next release

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

>>>>> "Dave" == Dave Cole <dj...@ob...> writes:

Dave> Now all I have to do is implement cs_config() in the extension
Dave> module and convert Sybase.py module to used callback error
Dave> handling.

Slow but steady progress...

I have implemented the cs_config() method for CS_CONTEXT objects.  I
then realised that a whole class of errors were never reaching the
outside (Python) world due to my use of an internal CS_CONTEXT for
doing numeric conversions (among other things).  I decided to fix this
up by placing the creation of the internal CS_CONTEXT under the
control of Python code.

The following is a test program which shows the new features.

- - bugger.py - - - - - - - - - - - - - - - - - - - - - - - - - - -
from sybasect import *

def cslib_cb(ctx, msg):
    print 'cslib_cb:'
    print '  severity ', msg.severity
    print '  msgnumber', msg.msgnumber
    print '  msgstring', msg.msgstring
    print '  osnumber ', msg.osnumber
    print '  osstring ', msg.osstring
    print '  status   ', msg.status
    print '  sqlstate ', msg.sqlstate
    raise ValueError('bugger!')

status, ctx = cs_ctx_alloc(CS_VERSION_110)
set_global_ctx(ctx)
ctx.cs_config(CS_SET, CS_MESSAGE_CB, cslib_cb)
numeric('12a')
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

When I run it this is what happens:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
cslib_cb:
  severity  1
  msgnumber 33816856
  msgstring cs_convert: cslib user api layer: common library error: The conversion/operation was stopped due to a syntax error in the source field.
  osnumber  0
  osstring  
  status    1076857758
  sqlstate  ZZZZZ
Traceback (most recent call last):
  File "bugger.py", line 17, in ?
    numeric('12a')
  File "bugger.py", line 12, in cslib_cb
    raise ValueError('bugger!')
ValueError: bugger!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Now I am finally ready to convert Sybase.py to callback error handling.

- Dave

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

Re: [python-sybase] Working on the next release

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

>>>>> "Dave" == Dave Cole <dj...@ob...> writes:

Dave> The only way I can see to do this is to only allow a single
Dave> thread to operate on a connection at a time.  Before calling the
Dave> Sybase API I would store the PyThreadState with my connection
Dave> structure.  When a callback is performed by the Sybase API I
Dave> locate my connection structure and restore the associated
Dave> PyThreadState before bouncing the callback up into the Python
Dave> code registered for that callback.

Just a heads-up.

I have made the GIL modifications to the sybasect extension module and
things seem to work OK.  With the module compiled with threading
enabled I successfully ran the examples/timeout.py program triggering
a timeout callback.

Now all I have to do is implement cs_config() in the extension module
and convert Sybase.py module to used callback error handling.

At the end of this process I should have a module which works properly
with FreeTDS.

- Dave

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

[python-sybase] Working on the next release

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

Just thought I should mention what I a working on for the next release
of the module...

I have decided to try switching to callback style error handling
instead of inline error handling.  This will have a couple of benefits;

1) FreeTDS uses callback error handling.

2) I should pick up server error messages generated while executing
   stored procedures.

The biggest problem is in managing the global interpreter lock (GIL).

Consider the case where there are two threads using the module.
Whenever I call a Sybase API in the extension module I release the GIL
to allow other threads to run while the server does its thing.  Once
the API returns I reacquire the lock before returning to the
interpreter.

With callback error handling the Sybase API will be calling a function
in the extension module while the GIL is released.  This presents a
small problem in that I must reacquire the GIL with the correct thread
state before bouncing the callback up into some Python code.  Consider
the following...

GIL:  Thread 1:                         Thread 2:
      PyThreadState *save1;             PyThreadState *save2;
    
1     save1 = PyThreadState_Swap(NULL);
1     PyEval_ReleaseLock();
2                                       save1 = PyThreadState_Swap(NULL);
2                                       PyEval_ReleaseLock();
-   
-     Sybase API                        Sybase API
-   
1     PyEval_AcquireLock();
1     PyThreadState_Swap(save1);
2                                       PyEval_AcquireLock();
2                                       PyThreadState_Swap(save1);

When both threads are executing a Sybase API and the callback function
is invoked I need to be able to reacquire the GIL using the correct
PyThreadState...

The only way I can see to do this is to only allow a single thread to
operate on a connection at a time.  Before calling the Sybase API I
would store the PyThreadState with my connection structure.  When a
callback is performed by the Sybase API I locate my connection
structure and restore the associated PyThreadState before bouncing the
callback up into the Python code registered for that callback.

I am still studying the Sybase documentation to make sure that the
above theory will work for the callbacks I am interested in handling.

- Dave

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

Re: Re[2]: [python-sybase] Problem with calling stored procedures

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

>>>>> "Harri" == Harri Pasanen <har...@tr...> writes:

>> begin tran
>> go
>> select * from authors
>> go
>> sp_helpindex authors
>> go

Harri> Maybe a dumb question, but why would you be opening a
Harri> transaction in the Sybase module if not explicitly asked?

The begin tran is implicit as the connection is in chained transaction
mode by default.  To turn off this behaviour you need to pass the
auto_commit flag to the Sybase.connect() function.

Harri> I'd expect what I'm doing in python be the same as above,
Harri> without the "begin tran" line.

The other way to get it to happen is this:

set chained on
go
select * from authors
go
sp_helpindex authors
go

The Sybase documentation says:

        If you set chained transaction mode, Adaptive Server
        implicitly invokes a begin transaction before the following
        statements: delete, insert, open, fetch, select, and
        update. You must still explicitly close the transaction with a
        commit.

        To cancel all or part of a transaction, use the rollback
        command.  The rollback command must appear within a
        transaction; you cannot roll back a transaction after it is
        committed.

- Dave

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

Re: [python-sybase] problem with pending results

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

>>>>> "Harri" == Harri Pasanen <har...@tr...> writes:

Harri> I presume you are seeing the message in the exception handler
Harri> for Sybase.Error ?

Harri> If you can, you could try closing the open cursors, call
Harri> db.commit() and then restart the operations.

Harri> Calling db.commit() in general seems to be a good idea for the
Harri> Sybase module (v0.34).  I rearranged my code to call
Harri> db.commit() before calling stored procedures, otherwise those
Harri> calls sometimes silently failed producing wrong results,
Harri> without throwing any exceptions.

The missing exception is a bug but requiring a commit() is correct
behaviour.  The DB-API specification says that in the documentation
for the Connection.commit() method:

        Commit any pending transaction to the database. Note that if
        the database supports an auto-commit feature, this must be
        initially off.

You can have the ISQL like behaviour by doing this:

db = Sybase.connect('SYBASE', user = 'sa', passwd = '', auto_commit = 1)

- Dave

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

Re: [python-sybase] pending results problem

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

>>>>> "Ralph" == Ralph Heinkel <rh...@ce...> writes:

Ralph> Hello, every once in a while (especially after having sybase
Ralph> server problems) I get the following message:

Ralph> ['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0,
Ralph> 'osstring': '', 'msgstring': 'ct_send(): user api layer:
Ralph> external error: This routine cannot be called because another
Ralph> command structure has results pending.', 'msgnumber': 16843057,
Ralph> 'severity': 1}]

Ralph> What would be the adequate reaction on this? (How do I detect
Ralph> this - the the msgnumber 16843057 unique to this error?)

It looks a bit suspicious.  Are you able to give any more details (SQL
for instance).

- Dave

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

Re: [python-sybase] problem with pending results

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

On Tue, 09 Apr 2002 10:13:34 +0200 Ralph Heinkel <rh...@ce...> wrote:

> Hello,
> 
> every once in a while (especially after having sybase server problems)
> I get the following message:
> 
> ['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0, 
> 'osstring': '', 'msgstring': 'ct_send(): user api layer: external error: 
> This routine cannot be called because another command structure has 
> results pending.', 'msgnumber': 16843057, 'severity': 1}]
> 
> 
> What would be the adequate reaction on this? (How do I detect this -
> the the msgnumber 16843057 unique to this error?)
> 
> Thanks,
> 
> Ralph
> 

I presume you are seeing the message in the exception handler for
Sybase.Error ?

If you can, you could try  closing the open cursors, call db.commit() and
then restart the operations.

Calling db.commit() in general seems to be a good idea for the Sybase
module (v0.34).  I rearranged my code to call db.commit() before calling
stored procedures, otherwise those calls sometimes silently failed
producing wrong results, without throwing any exceptions.


-Harri

[python-sybase] pending results problem

[Ralph H. <rh...@ce...>]

Hello,

every once in a while (especially after having sybase server problems)
I get the following message:

['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0, 
'osstring': '', 'msgstring': 'ct_send(): user api layer: external error: 
This routine cannot be called because another command structure has 
results pending.', 'msgnumber': 16843057, 'severity': 1}]       


What would be the adequate reaction on this? (How do I detect this -
the the msgnumber 16843057 unique to this error?)

Thanks,

Ralph

[python-sybase] pending results problem

[Ralph H. <rh...@ce...>]

Hello,

every once in a while (especially after having sybase server problems)
I get the following message:

['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0, 
'osstring': '', 'msgstring': 'ct_send(): user api layer: external error: 
This routine cannot be called because another command structure has 
results pending.', 'msgnumber': 16843057, 'severity': 1}]


What would be the adequate reaction on this? (How do I detect this -
the the msgnumber 16843057 unique to this error?)

Thanks,

Ralph

[python-sybase] problem with pending results

[Ralph H. <rh...@ce...>]

Hello,

every once in a while (especially after having sybase server problems)
I get the following message:

['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0, 
'osstring': '', 'msgstring': 'ct_send(): user api layer: external error: 
This routine cannot be called because another command structure has 
results pending.', 'msgnumber': 16843057, 'severity': 1}]


What would be the adequate reaction on this? (How do I detect this -
the the msgnumber 16843057 unique to this error?)

Thanks,

Ralph

Re[2]: [python-sybase] Problem with calling stored procedures

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

On 04 Apr 2002 01:03:10 +1000 Dave Cole <dj...@ob...> wrote:

> 
> > > import Sybase
> > > Sybase._ctx.debug = 1
> > > db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')
> > > 
> > > def test(table):
> > >     print "Test table:", table
> > >     c = db.cursor()
> > >     c.execute('select * from '+table)
> > >     c.fetchall()
> > >     c.close()
> > >     cmd = "sp_helpindex %s" % table
> > >     print db.execute(cmd)
> > > 
> > > test('authors')
> > 
> > Ahh...  It does fail - it returns a status code from the stored
> > procedure of -6.  I have no idea what that means...
> > 
> > What I did discover though is that the problem is transaction related.
> > If I knew a lot more about isolation levels and how they interact with
> > stored procedures I might be able to give a more meaningful answer.
> 
> Try this in ISQL:
> 
> begin tran
> go
> select * from authors
> go
> sp_helpindex authors
> go
> 

Maybe a dumb question, but why would you be opening a transaction in the
Sybase module if not explicitly asked?

I'd expect what I'm doing in python be the same as above, without the
"begin tran" line.


-Harri

Re: [python-sybase] Problem with calling stored procedures

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

> > import Sybase
> > Sybase._ctx.debug = 1
> > db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')
> > 
> > def test(table):
> >     print "Test table:", table
> >     c = db.cursor()
> >     c.execute('select * from '+table)
> >     c.fetchall()
> >     c.close()
> >     cmd = "sp_helpindex %s" % table
> >     print db.execute(cmd)
> > 
> > test('authors')
> 
> Ahh...  It does fail - it returns a status code from the stored
> procedure of -6.  I have no idea what that means...
> 
> What I did discover though is that the problem is transaction related.
> If I knew a lot more about isolation levels and how they interact with
> stored procedures I might be able to give a more meaningful answer.

Try this in ISQL:

begin tran
go
select * from authors
go
sp_helpindex authors
go

Now the real mystery is why the module is not detecting and reporting
the messages associated with the failed stored procedure...

Trying something else...

>>> import Sybase
>>> db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')
>>> def test(table):
...     print "Test table:", table
...     c = db.cursor()
...     c.execute('select * from '+table)
...     c.fetchall()
...     c.close()
...     cmd = "sp_helpindex %s" % table
...     print db.execute(cmd)
... 
>>> test('authors')
Test table: authors
[[(-6,)]]
>>> print Sybase._ct_errors(db._conn, 'oops')
oops
Msg 2762, Level 16, State 3:
Line 91:
The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.

Msg 2762, Level 16, State 3:
Line 102:
The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.

Msg 208, Level 16, State 6:
Line 305:
#spindtab not found. Specify owner.objectname or use sp_help to check whether the object exists (sp_help may produce lots of output).

So...  Now the real bug has been found - the Sybase.py module is not
detecting the failure of the stored procedure at the server side.  The
client side is working without errors and receiving the error status
from the server and it seems that my code interprets that as meaning
everything is fine.

Ooops.

- Dave

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

Re: [python-sybase] Problem with calling stored procedures

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

> import Sybase
> Sybase._ctx.debug = 1
> db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')
> 
> def test(table):
>     print "Test table:", table
>     c = db.cursor()
>     c.execute('select * from '+table)
>     c.fetchall()
>     c.close()
>     cmd = "sp_helpindex %s" % table
>     print db.execute(cmd)
> 
> test('authors')

Ahh...  It does fail - it returns a status code from the stored
procedure of -6.  I have no idea what that means...

What I did discover though is that the problem is transaction related.
If I knew a lot more about isolation levels and how they interact with
stored procedures I might be able to give a more meaningful answer.

Try this to shed some light on the problem:

import Sybase
Sybase._ctx.debug = 1
db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')

def test(table):
    print "Test table:", table
    c = db.cursor()
    c.execute('select * from '+table)
    c.fetchall()
    c.close()
    db.commit()
    cmd = "sp_helpindex %s" % table
    print db.execute(cmd)

test('authors')

- Dave

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

Re: Re[2]: [python-sybase] installation problem of the Sybase module

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

>>>>> "Andrew" == Andrew McNamara <an...@ob...> writes:

Andrew> Yes. While either LD_LIBRARY_PATH or -R will let you work
Andrew> around this problem, neither are really "the answer". Sybase
Andrew> probably should be naming their version of the library
Andrew> differently (but then, you may still have symbol name
Andrew> collisions).

>> Another option would be to link statically.

Andrew> Sigh.

The thing which most annoys me is I cannot seem to work out a scheme
which will allow the module to link with all of the open client based
products shipped by Sybase.

[thinks...]  Maybe I should have a look at the Perl modules for using
Sybase and see how the linking 6.023x10**23 products problem is
resolved there...

- Dave

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

Re: Re[2]: [python-sybase] installation problem of the Sybase module

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

>Yes, setting LD_LIBRARY_PATH will fix it, but problem is that one does not
>always have control of its value, as it can be overridden by some other
>application.  

Yep.

>Btw.  the sympton of the problem is that it complains about
>missing symbol comn_free.  I've seen that both on linux and Solaris.

I'm guessing that libintl is related to gettext() internationalisation,
and Sybase is shipping their own version of the library that is
incompatible with the linux one (neither my RH or my Debian system appear
to have one, BTW).

>As to "-R", that can be used, but better is to use -rpath. 
>
>>From GNU ld man page:
>
>           For  compatibility with other ELF linkers, if the "-R"
>           option is followed by a directory name, rather than  a
>           file name, it is treated as the "-rpath" option.

Ah - thanks for that. I was a little hasty in my reading.

>Indeed it might be preferable to use -rpath in setup.py.  The problem with
>that is when you are delivering binaries.  Then it may be that the target
>machine has Sybase client libs in a different directory, like if they have
>12.5 client libs and not 11.9.2, or have installed those into user
>directory.

Yes. While either LD_LIBRARY_PATH or -R will let you work around this
problem, neither are really "the answer". Sybase probably should be naming
their version of the library differently (but then, you may still have
symbol name collisions).

>Another option would be to link statically.

Sigh.

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

Re[2]: [python-sybase] installation problem of the Sybase module

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

On Wed, 03 Apr 2002 13:08:16 +1000 Andrew McNamara <an...@ob...> wrote:

> >Forgot to mention an installation/build problem with the Sybase module.
>  
> >On Linux Mandrake 8.1 + some patches, Python 2.2,  the module linked
> with
> >libintl.so from Sybase.  But at runtime it picked up the library from
> >/usr/lib, which is of course not the Sybase lib, even if has the same
> name.
> >
> >My workaround for the above was to create a symlink libsybintl.so ->
> >libintl.so in the sybase lib directory, and tweak the setup.py to use
> >libsybintl.so.
> 
> Hmm. Maybe setting an LD_LIBRARY_PATH environment variable including
> the Sybase library directory would allow you to run your application
> without the symlink (man ld.so)?
> 
> The Solaris linker allows the application builder to set the directories
> that will be searched at run-time with the "-R" option.  Opinion is split
> over whether this is "a good thing", but it's handy in cases like this. I
> don't know of a linux equivilent (-R means something else to GNU ld).
> 

Yes, setting LD_LIBRARY_PATH will fix it, but problem is that one does not
always have control of its value, as it can be overridden by some other
application.  Btw.  the sympton of the problem is that it complains about
missing symbol comn_free.  I've seen that both on linux and Solaris.

As to "-R", that can be used, but better is to use -rpath. 

From GNU ld man page:

           For  compatibility with other ELF linkers, if the "-R"
           option is followed by a directory name, rather than  a
           file name, it is treated as the "-rpath" option.

Indeed it might be preferable to use -rpath in setup.py.  The problem with
that is when you are delivering binaries.  Then it may be that the target
machine has Sybase client libs in a different directory, like if they have
12.5 client libs and not 11.9.2, or have installed those into user
directory.

Another option would be to link statically.

-Harri

Re[2]: [python-sybase] Problem with calling stored procedures

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

I replied to this from home, and the mailing list barked at that, so here
it goes again.  Sorry if you get it twice.  See below for a simple testcase
for the presumed bug.

-Harri


On Tuesday 02 April 2002 14:31, Dave Cole wrote:
> > Hello, I think the old problem with calling some stored procedures
> > still seems to be there.
> >
> > Namely, I still can't get any sensible results from calling
> > sp_helpindex.  The code is something like:
> >
> >
> > def getindex(table):
> >     print "getindex", table
> >     c = cnx.cursor()
> >     c.callproc("sp_helpindex", [table])
> >     l = c.fetchall()
> >     print l
> >     while c.nextset():
> >         l = c.fetchall()
> >         print l
> >
> > cnx=Sybase.connect("<server>","<uname>","<pass>")
> > cnx.cursor().execute("use mydb")
> >
> > getindex("mytable")
>
> Hmm...  It Seems To Work For Me With 0.34 (TM)
>
> >>> import Sybase
> >>> db = Sybase.connect('SYBASE', 'sa', '')
> >>> db.cursor().execute('use pubs2')
> >>> c = db.cursor()
> >>> c.callproc('sp_helpindex', ['titles'])
> >>> for r in c.fetchall():
>
> ...     print r
> ...
> ('titleidind          ', 'clustered, unique located on default             
>       ', ' title_id', 0, 0, 0) ('titleind            ', 'nonclustered
> located on default                         ', ' title', 0, 0, 0)
>
> >>> c.nextset()
>
> 1
>
> >>> for r in c.fetchall():
>
> ...     print r
> ...
> (0,)
>
> >>> c.nextset()
>
> - Dave

I finally fished from my disk the old testcase I sent your way last November, 
which still should exhibit the problem:

I wrote:

After some tests, I got a fairly minimal test case that should also fail for
you.  The preceding 'select' somehow throws the 'sp_helpindex' call off
balance.

-Harri

------8<------8<------8<------8<------8<------8<------8<------8<--------
import Sybase
Sybase._ctx.debug = 1
db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')

def test(table):
    print "Test table:", table
    c = db.cursor()
    c.execute('select * from '+table)
    c.fetchall()
    c.close()
    cmd = "sp_helpindex %s" % table
    print db.execute(cmd)

test('authors')

Re: [python-sybase] installation problem of the Sybase module

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

>Forgot to mention an installation/build problem with the Sybase module.  
>On Linux Mandrake 8.1 + some patches, Python 2.2,  the module linked with
>libintl.so from Sybase.  But at runtime it picked up the library from
>/usr/lib, which is of course not the Sybase lib, even if has the same name.
>
>My workaround for the above was to create a symlink libsybintl.so ->
>libintl.so in the sybase lib directory, and tweak the setup.py to use
>libsybintl.so.

Hmm. Maybe setting an LD_LIBRARY_PATH environment variable including
the Sybase library directory would allow you to run your application
without the symlink (man ld.so)?

The Solaris linker allows the application builder to set the directories
that will be searched at run-time with the "-R" option.  Opinion is split
over whether this is "a good thing", but it's handy in cases like this. I
don't know of a linux equivilent (-R means something else to GNU ld).

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

Re: [python-sybase] Problem with calling stored procedures

[Harri P. <ha...@ne...>]

On Tuesday 02 April 2002 14:31, Dave Cole wrote:
> > Hello, I think the old problem with calling some stored procedures
> > still seems to be there.
> >
> > Namely, I still can't get any sensible results from calling
> > sp_helpindex.  The code is something like:
> >
> >
> > def getindex(table):
> >     print "getindex", table
> >     c = cnx.cursor()
> >     c.callproc("sp_helpindex", [table])
> >     l = c.fetchall()
> >     print l
> >     while c.nextset():
> >         l = c.fetchall()
> >         print l
> >
> > cnx=Sybase.connect("<server>","<uname>","<pass>")
> > cnx.cursor().execute("use mydb")
> >
> > getindex("mytable")
>
> Hmm...  It Seems To Work For Me With 0.34 (TM)
>
> >>> import Sybase
> >>> db = Sybase.connect('SYBASE', 'sa', '')
> >>> db.cursor().execute('use pubs2')
> >>> c = db.cursor()
> >>> c.callproc('sp_helpindex', ['titles'])
> >>> for r in c.fetchall():
>
> ...     print r
> ...
> ('titleidind          ', 'clustered, unique located on default             
>       ', ' title_id', 0, 0, 0) ('titleind            ', 'nonclustered
> located on default                         ', ' title', 0, 0, 0)
>
> >>> c.nextset()
>
> 1
>
> >>> for r in c.fetchall():
>
> ...     print r
> ...
> (0,)
>
> >>> c.nextset()
>
> - Dave

I finally fished from my disk the old testcase I sent your way last November, 
which still should exhibit the problem:

I wrote:

After some tests, I got a fairly minimal test case that should also fail for
you.  The preceding 'select' somehow throws the 'sp_helpindex' call off
balance.

-Harri

------8<------8<------8<------8<------8<------8<------8<------8<--------
import Sybase
Sybase._ctx.debug = 1
db = Sybase.connect('SYBASE', 'sa', '', 'pubs2')

def test(table):
    print "Test table:", table
    c = db.cursor()
    c.execute('select * from '+table)
    c.fetchall()
    c.close()
    cmd = "sp_helpindex %s" % table
    print db.execute(cmd)

test('authors')

RE: [python-sybase] installation problem of the Sybase module

[Potian, J. (Exchange) <jp...@be...>]

Harry,

Did this solve your stored procedure problems?

Regards,

Jon-Marcelius Potian

-----Original Message-----
From: Harri Pasanen [mailto:har...@tr...]
Sent: Tuesday, April 02, 2002 5:19 AM
To: pyt...@ob...
Subject: [python-sybase] installation problem of the Sybase module


Me again,

Forgot to mention an installation/build problem with the Sybase module.  
On Linux Mandrake 8.1 + some patches, Python 2.2,  the module linked with
libintl.so from Sybase.  But at runtime it picked up the library from
/usr/lib, which is of course not the Sybase lib, even if has the same name.

My workaround for the above was to create a symlink libsybintl.so ->
libintl.so in the sybase lib directory, and tweak the setup.py to use
libsybintl.so.


-Harri

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


**********************************************************************
Please be aware that, notwithstanding the fact that the person sending
this communication has an address in Bear Stearns' e-mail system, this
person is not an employee, agent or representative of Bear Stearns.
Accordingly, this person has no power or authority to represent, make
any recommendation, solicitation, offer or statements or disclose
information on behalf of or in any way bind Bear Stearns or any of its
affiliates.
**********************************************************************

Re[2]: [python-sybase] installation problem of the Sybase module

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

No, that was a-priori problem I had to solve before I could run anything.

-Harri


On Tue, 2 Apr 2002 07:49:56 -0500  "Potian, Jon (Exchange)" <jp...@be...> wrote:

> Harry,
> 
> Did this solve your stored procedure problems?
> 
> Regards,
> 
> Jon-Marcelius Potian
> 
> -----Original Message-----
> From: Harri Pasanen [mailto:har...@tr...]
> Sent: Tuesday, April 02, 2002 5:19 AM
> To: pyt...@ob...
> Subject: [python-sybase] installation problem of the Sybase module
> 
> 
> Me again,
> 
> Forgot to mention an installation/build problem with the Sybase module.  
> On Linux Mandrake 8.1 + some patches, Python 2.2,  the module linked with
> libintl.so from Sybase.  But at runtime it picked up the library from
> /usr/lib, which is of course not the Sybase lib, even if has the same
> name.
> 
> My workaround for the above was to create a symlink libsybintl.so ->
> libintl.so in the sybase lib directory, and tweak the setup.py to use
> libsybintl.so.
> 
> 
> -Harri
> 

Re: [python-sybase] Problem with calling stored procedures

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

> Hello, I think the old problem with calling some stored procedures
> still seems to be there.
> 
> Namely, I still can't get any sensible results from calling
> sp_helpindex.  The code is something like:
> 
> 
> def getindex(table):
>     print "getindex", table
>     c = cnx.cursor()
>     c.callproc("sp_helpindex", [table])
>     l = c.fetchall()
>     print l
>     while c.nextset():
>         l = c.fetchall()
>         print l
> 
> cnx=Sybase.connect("<server>","<uname>","<pass>")
> cnx.cursor().execute("use mydb")
> 
> getindex("mytable")

Hmm...  It Seems To Work For Me With 0.34 (TM)

>>> import Sybase
>>> db = Sybase.connect('SYBASE', 'sa', '')
>>> db.cursor().execute('use pubs2')
>>> c = db.cursor()
>>> c.callproc('sp_helpindex', ['titles'])
>>> for r in c.fetchall():
...     print r
... 
('titleidind          ', 'clustered, unique located on default                    ', ' title_id', 0, 0, 0)
('titleind            ', 'nonclustered located on default                         ', ' title', 0, 0, 0)
>>> c.nextset()
1
>>> for r in c.fetchall():
...     print r
... 
(0,)
>>> c.nextset()
>>> 

- Dave

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