python-sybase-misc

Re: [python-sybase] Sybase module 0.38pre1 released

[<sab...@gm...>]

Hi Phil,

thanks for your patch.

I applied your correction to CS_BLKDESC_blk_describe (rev 308).

I will investigate further the other problem your reported.

regards

--
S=E9bastien Sabl=E9

2006/12/14, Phil Porter <ph...@ph...>:
>
> Hi,
>
> Thanks very much for taking this over.
>
> Like Paul, I posted a patch a while ago that doesn't seem to have made it
> into 0.38.  Any chance you could add the following fix as well?
>
> It looks like there are some missing braces in the implementation of
> blk_describe.  At the moment it always returns (status, None).  Here is a
> patch:
>
> --- blk.c.old   2006-09-09 15:41:49.520844800 +0100
> +++ blk.c.new   2006-09-09 15:42:56.657382400 +0100
> @@ -86,10 +86,11 @@
>          return NULL;
>      }
>
> -    if (status !=3D CS_SUCCEED)
> +    if (status !=3D CS_SUCCEED) {
>         if (self->debug)
>             debug_msg(", None\n");
>         return Py_BuildValue("iO", status, Py_None);
> +    }
>
>      fmt =3D datafmt_alloc(&datafmt, 0);
>      if (fmt =3D=3D NULL) {
>
> Another point is that blk_describe doesn't seem to behave in the way that
> the documentation describes.  The alloc_bufs example given in the docs
> doesn't work because blk_describe raises a DatabaseError if the column
> number is greater than the number of columns in the table (rather than
> returning CS_FAIL).  One solution might be to update the example as
> follows...
>
>    def alloc_bufs(self, num):
>        bufs =3D []
>        try:
>            while 1 :
>                status, ofmt =3D self.blk.blk_describe(len(bufs) + 1)
>                ofmt.count =3D num
>                bufs.append(DataBuf(ofmt))
>        except Sybase.DatabaseError:
>            pass
>        self.bufs =3D bufs
>
> Finally, we found that blk_describe reports the wrong maxlength for
> numeric types.  We resolved this for our purposes by hacking databuf.c as
> follows but I don't think that this is a good solution.  I think it would
> be better to do something to blk_describe itself instead.
>
> --- databuf.c   2002-12-24 03:23:39.000000000 +0000
> +++ /tmp/databuf.c      2006-09-14 11:43:28.000000000 +0100
> @@ -57,14 +57,15 @@
>         self->fmt =3D ((CS_DATAFMTObj*)obj)->fmt;
>         if (self->fmt.count =3D=3D 0)
>             self->fmt.count =3D 1;
> -#ifdef HAVE_FREETDS
> +//#ifdef HAVE_FREETDS
>         /* Seems like FreeTDS reports the wrong maxlength in
>          * ct_describe() - fix this when binding to a buffer.
>          */
> +    /* Seems like Sybase's blk_describe has the same problem - PCP */
>         if (self->fmt.datatype =3D=3D CS_NUMERIC_TYPE
>             || self->fmt.datatype =3D=3D CS_DECIMAL_TYPE)
>             self->fmt.maxlength =3D sizeof(CS_NUMERIC);
> -#endif
> +//#endif
>         if (allocate_buffers(self) =3D=3D NULL) {
>             Py_DECREF(self);
>             return NULL;
>
> Hope this is of use.
>
> Regards,
>
> Phil
>
> --
> Phil Porter
>
>

Re: [python-sybase] Sybase module 0.38pre1 released

[Phil P. <pyt...@ph...>]

> Sorry about resending this - I didn't send it from my registered email
address first time.

Hi,

Thanks very much for taking this over.

Like Paul, I posted a patch a while ago that doesn't seem to have made it
into 0.38.  Any chance you could add the following fix as well?

It looks like there are some missing braces in the implementation of
blk_describe.  At the moment it always returns (status, None).  Here is a
patch:

--- blk.c.old   2006-09-09 15:41:49.520844800 +0100
+++ blk.c.new   2006-09-09 15:42:56.657382400 +0100
@@ -86,10 +86,11 @@
         return NULL;
     }

-    if (status != CS_SUCCEED)
+    if (status != CS_SUCCEED) {
        if (self->debug)
            debug_msg(", None\n");
        return Py_BuildValue("iO", status, Py_None);
+    }

     fmt = datafmt_alloc(&datafmt, 0);
     if (fmt == NULL) {

Another point is that blk_describe doesn't seem to behave in the way that
the documentation describes.  The alloc_bufs example given in the docs
doesn't work because blk_describe raises a DatabaseError if the column
number is greater than the number of columns in the table (rather than
returning CS_FAIL).  One solution might be to update the example as
follows...

   def alloc_bufs(self, num):
       bufs = []
       try:
           while 1 :
               status, ofmt = self.blk.blk_describe(len(bufs) + 1)
ofmt.count = num
               bufs.append(DataBuf(ofmt))
       except Sybase.DatabaseError:
           pass
       self.bufs = bufs

Finally, we found that blk_describe reports the wrong maxlength for
numeric types.  We resolved this for our purposes by hacking databuf.c as
follows but I don't think that this is a good solution.  I think it would
be better to do something to blk_describe itself instead.

--- databuf.c   2002-12-24 03:23:39.000000000 +0000
+++ /tmp/databuf.c      2006-09-14 11:43:28.000000000 +0100
@@ -57,14 +57,15 @@
        self->fmt = ((CS_DATAFMTObj*)obj)->fmt;
        if (self->fmt.count == 0)
            self->fmt.count = 1;
-#ifdef HAVE_FREETDS
+//#ifdef HAVE_FREETDS
        /* Seems like FreeTDS reports the wrong maxlength in
         * ct_describe() - fix this when binding to a buffer.
         */
+    /* Seems like Sybase's blk_describe has the same problem - PCP */
        if (self->fmt.datatype == CS_NUMERIC_TYPE
            || self->fmt.datatype == CS_DECIMAL_TYPE)
            self->fmt.maxlength = sizeof(CS_NUMERIC);
-#endif
+//#endif
        if (allocate_buffers(self) == NULL) {
            Py_DECREF(self);
            return NULL;

Hope this is of use.

Regards,

Phil

-- 
Phil Porter



-- 
Phil Porter

Re: [python-sybase] Can I get the underlying connection object?

[<sab...@gm...>]

Hi Skip,

you can't do that at the moment.

you would have to extend the following struct in conn.c in order to
expose the 'conn' attribute:
static struct memberlist CS_CONNECTION_memberlist[]

regards

--
S=E9bastien Sabl=E9

2006/12/12, sk...@po... <sk...@po...>:
> Is it possible to get the underlying CS_CONNECTION object from the
> ConnectionType object somehow?  We have applications where both Python co=
de
> and wrapped C++ code make SQL queries and would like to make just a singl=
e
> connection to the database (modulo connection locking issues of course).
>
> --
> Skip Montanaro - sk...@po... - http://www.mojam.com/
> "The hippies and the hipsters did some great stuff in the sixties,
> but the geeks pulled their weight too." -- Billy Bragg
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ww...
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
>

Re: [python-sybase] Sybase module 0.38pre1 released

[<sab...@gm...>]

Hi Paul,

the Sybase documentation is very poor about CS_LONG, it doesn't seem
to appear anywhere (in sybase 12.5 and 15 reference manual). I only
found it in cstypes.h where it is defined as a long and not a long
long.

So I have modified your patch in order to use a long (see attached
patch). Please check that it works as expected.

Also there is now a CS_BIGINT type in Sybase 15 which is a "long
long". I will make a modification in coming days so that with sybase
15, the CS_BIGINT type is used by default instead of CS_LONG when
passing long Python objects to DataBuf.

regards

--
S=E9bastien Sabl=E9

2006/12/12, Paul Rensing <pau...@ve...>:
> Sebastien,
>
> Thanks for taking this over.
>
> I sent in a small patch a long time ago dealing with handling 8-byte ints=
. I
> checked and it is not included in the 0.38pre1 package, so here it is aga=
in
> (agaist 0.37 code). I apologize that this is not a complete patch for the
> problem. I only included the read operation and there may be other data
> types that should be added.
>
> Paul Rensing
>
>
>
> On 12/12/06, S=E9bastien Sabl=E9 <sab...@gm...> wrote:
> >
> > 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.
> >
> > MAJOR CHANGES SINCE 0.37:
> >
> > * This release works with python 2.5
> >
> > * It also works with sybase 15
> >
> > * It works with 64bits clients
> >
> > * It can be configured to return native python datetime objects
> >
> > * The bug "This routine cannot be called because another command
> > structure has results pending." which appears in various cases has
> > been corrected
> >
> > * It includes a unitary test suite based on the dbapi2.0 compliance
> > test suite
> > _______________________________________________
> > Python-sybase mailing list
> > Pyt...@ww...
> >
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
> >
>
>
>

[python-sybase] Re: Sybase module 0.38pre1 released

[<sab...@gm...>]

By the way, I forgot to say that new releases can now be downloaded
from this page:

https://sourceforge.net/project/showfiles.php?group_id=3D184050

regards

--
S=E9bastien Sabl=E9

2006/12/12, S=E9bastien Sabl=E9 <sab...@gm...>:
> 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.
>
> MAJOR CHANGES SINCE 0.37:
>
> * This release works with python 2.5
>
> * It also works with sybase 15
>
> * It works with 64bits clients
>
> * It can be configured to return native python datetime objects
>
> * The bug "This routine cannot be called because another command
> structure has results pending." which appears in various cases has
> been corrected
>
> * It includes a unitary test suite based on the dbapi2.0 compliance
> test suite
>

[python-sybase] Can I get the underlying connection object?

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

Is it possible to get the underlying CS_CONNECTION object from the
ConnectionType object somehow?  We have applications where both Python code
and wrapped C++ code make SQL queries and would like to make just a single
connection to the database (modulo connection locking issues of course).

-- 
Skip Montanaro - sk...@po... - http://www.mojam.com/
"The hippies and the hipsters did some great stuff in the sixties,
but the geeks pulled their weight too." -- Billy Bragg

[python-sybase] Sybase module 0.38pre1 released

[<sab...@gm...>]

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.

MAJOR CHANGES SINCE 0.37:

* This release works with python 2.5

* It also works with sybase 15

* It works with 64bits clients

* It can be configured to return native python datetime objects

* The bug "This routine cannot be called because another command
structure has results pending." which appears in various cases has
been corrected

* It includes a unitary test suite based on the dbapi2.0 compliance
test suite

Re: [python-sybase] The python-sybase module has been moved to sourceforge.net.

[<sab...@gm...>]

Thank you Dave; I will try to keep python-sybase as good as it is now.

I have released a first pre-release 0.38pre1 on sourceforge. It
includes most of the patchs provided recently on this mailing-list.

I would appreciate if people on this mailing-list could test it on as
many environments as possible.

You can download it there:
http://sourceforge.net/project/showfiles.php?group_id=3D184050

MAJOR CHANGES SINCE 0.37:

* This release works with python 2.5

* It also works with sybase 15

* It works with 64bits clients

* It can be configured to return native python datetime objects

* The bug "This routine cannot be called because another command
structure has results pending." which appears in various cases has
been corrected

* It includes a unitary test suite based on the dbapi2.0 compliance test su=
ite

2006/12/12, Dave Cole <dj...@ob...>:
> S=E9bastien Sabl=E9 wrote:
> > 2006/7/6, Andrew McNamara <an...@ob...>:
> >> ...
> >> That raises the question - should the project be moved to Sourceforge?
> >> I'm not convinced the move would solve anything: it would still requir=
e at
> >> least one developer with C skills and the time to review and test
> >> patches, cut releases, and reply to queries - is there anyone on the l=
ist willing
> >> to commit to that?
> >
> > I would like to volunteer to do that. We are using python-sybase in a
> > few tools at the company where I work and so we would like to
> > contribute to this project and ensure it is properly tested.
>
> In response to this message we asked S=E9bastien if he would be prepared
> to create a sourceforge project and move our code onto the site.
>
> S=E9bastien agreed to create the project on sourceforge and he then
> converted our CVS module to subversion and loaded it up at:
>         http://sourceforge.net/projects/python-sybase/
>
> We have been hoping someone would make an offer like this for quite some
> time now, and it is a great relief to see the code be taken over by
> someone who not only has an ongoing interest in the success of the
> project, but also has the ability to ensure that success.
>
> Thank you S=E9bastien.
>
> - Dave
>
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ww...
> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase
>

[python-sybase] The python-sybase module has been moved to sourceforge.net.

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

Sébastien Sablé wrote:
> 2006/7/6, Andrew McNamara <an...@ob...>:
>> ...
>> That raises the question - should the project be moved to Sourceforge? 
>> I'm not convinced the move would solve anything: it would still require at
>> least one developer with C skills and the time to review and test 
>> patches, cut releases, and reply to queries - is there anyone on the list willing
>> to commit to that?
> 
> I would like to volunteer to do that. We are using python-sybase in a
> few tools at the company where I work and so we would like to
> contribute to this project and ensure it is properly tested.

In response to this message we asked Sébastien if he would be prepared 
to create a sourceforge project and move our code onto the site.

Sébastien agreed to create the project on sourceforge and he then 
converted our CVS module to subversion and loaded it up at:
	http://sourceforge.net/projects/python-sybase/

We have been hoping someone would make an offer like this for quite some 
time now, and it is a great relief to see the code be taken over by 
someone who not only has an ongoing interest in the success of the 
project, but also has the ability to ensure that success.

Thank you Sébastien.

- Dave

[python-sybase] Sybase and sqlalchemy?

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

Re-asking a question I first posed in September that went unanswered...  Has
anyone looked at how hard it would be to write a python-sybase driver for
sqlalchemy?

-- 
Skip Montanaro - sk...@po... - http://www.mojam.com/
"The hippies and the hipsters did some great stuff in the sixties,
but the geeks pulled their weight too." -- Billy Bragg

Re: [python-sybase] Re: This routine cannot be called because another command structure has results pending

[<sab...@gm...>]

Hi Andrew,

2006/7/6, Andrew McNamara <an...@ob...>:
> ...
> As to whether it make it into a future release, I can certainly apply
> it to the repository, but neither Dave nor I have a Sybase installation
> to test it against at the moment (and neither of us can really spare
> the time).
>
> That raises the question - should the project be moved to Sourceforge? I'=
m
> not convinced the move would solve anything: it would still require at
> least one developer with C skills and the time to review and test patches=
,
> cut releases, and reply to queries - is there anyone on the list willing
> to commit to that?

I would like to volunteer to do that. We are using python-sybase in a
few tools at the company where I work and so we would like to
contribute to this project and ensure it is properly tested.

Actually I have already done most of the work:
* I merged most of the patches provided on this list
* I added some corrections of my own
* I added a unit test suite based on the DB API 2.0 driver compliance
unit test suite + extra
* this unit test suite has been added to our automated testing
framework so that it runs frequently on the following platforms and
sybase clients:
   i686-pc-linux-gnu - Sybase ASE 12.5.1 and 15.0 (32bits)
   sparc-sun-solaris2.10 - Sybase ASE 12.5.1 and 15.0 (32bits and 64bits)
   sparc-sun-solaris2.8 - Sybase ASE 12.5.1 and 15.0 (32bits)
   powerpc-ibm-aix5.3.0.0 - Sybase ASE 12.5.1 and 15.0 (32bits)
   powerpc-ibm-aix5.2.0.0 - Sybase ASE 12.5.1 and 15.0 (32bits)
   alphaev68-dec-osf5.1 - Sybase ASE 12.5.1 and 15.0 (32bits)

I join a patch which includes the modifications and the unit test
suite. If that is OK with you and Dave, I would be happy to help you
"review and test patches, cut releases, and reply to queries" for
coming versions of python-sybase.

regards

--
S=E9bastien Sabl=E9
SunGard GP3 - Runtime

Re: [python-sybase] problem with python-sybase 0.37 and OCS 15.0

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

RGlkIHlvdSBwYXRjaCBzZXR1cC5weSB1c2luZyBteSBwYXRjaCBwb3N0ZWQgb24gdGhpcyBsaXN0
LCBvciAKc29tZXRoaW5nIGVsc2U/CgpCZWNhdXNlIEkgc3VzcGVjdCBteSBwYXRjaGVzIHdvdWxk
IHdvcmsuLi4KCi1IYXJyaQoKT24gVGh1cnNkYXkgMTIgT2N0b2JlciAyMDA2IDE5OjM5LCBUYXJh
IEhlcm5hbmRleiB3cm90ZToKPiBXZSBoYXZlIGJlZW4gcnVubmluZyAwLjM2IGFnYWluc3QgT0NT
IDEyLjUgbGlicmFyaWVzIG9uIEZlZG9yYSBmb3IKPiBhIHdoaWxlIHdpdGggbm8gcHJvYmxlbSwg
YnV0IG9ubHkgd2l0aCBhIDMyIGJpdCBjb25maWd1cmF0aW9uLiAgV2UKPiBmaW5hbGx5IGdvdCA2
NCBiaXQgbGlicmFyaWVzIHZpYSBhIG5ldyBTeWJhc2UgT0NTIDE1LjAgcGFja2FnZSAsCj4gYW5k
IG9uY2UgSSBwYXRjaGVkIHVwIHRoZSBzZXR1cC5weSB0byB1c2UgdGhlIGNvcnJlY3QgbGlicmFy
aWVzLAo+IGV2ZXJ5dGhpbmcgYnVpbHQgb3V0IGFuZCBJIHdhcyBhYmxlIHRvIGRvIGFuICJpbXBv
cnQgU3liYXNlIi4KPgo+IEhvd2V2ZXIsIGlmIEkgYWN0dWFsbHkgdHJ5IHRvIG1ha2UgYSBjb25u
ZWN0aW9uIHRvIHRoZSBkYiwgSSBnZXQgYQo+IHJlYWxseSB3ZWlyZCBlcnJvciB0aGF0IEkgZG9u
J3QgdW5kZXJzdGFuZCAob2J2aW91c2x5IHRoaXMgd29ya3MKPiB3aXRoIHRoZSBvbGQgc2V0dXAp
Ogo+Cj4gdGVzdCBjb2RlOgo+Cj4gaW1wb3J0IG9zCj4gb3MucHV0ZW52KCdTWUJBU0UnLCcvdXNy
L3N5YmFzZScpCj4gaW1wb3J0IFN5YmFzZQo+IHVzZXIgPSAnaGl0ZWNoJwo+IHBhc3N3b3JkID0g
J2hpdGVjaCcKPiBjb25uID0gU3liYXNlLmNvbm5lY3QoJ0RCU0VSVkVSJyx1c2VyLHBhc3N3b3Jk
LGF1dG9fY29tbWl0PTEpCj4KPiBlcnJvcjoKPgo+IFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2Fs
bCBsYXN0KToKPiAgIEZpbGUgIjxzdGRpbj4iLCBsaW5lIDEsIGluID8KPiAgIEZpbGUKPiAiL3Zh
ci90bXAvcHl0aG9uLXN5YmFzZS1yb290L3BpeGFyL2QyL3NldHMvdG9vbHMtMzEvbGliL3B5dGhv
bjIuNC9zCj5pdGUtcGFja2FnZXMvU3liYXNlLnB5IiwgbGluZSAxMDA1LCBpbiBjb25uZWN0Cj4g
ICAgIHN0cmlwLCBhdXRvX2NvbW1pdCwgZGVsYXlfY29ubmVjdCwgbG9ja2luZykKPiAgIEZpbGUK
PiAiL3Zhci90bXAvcHl0aG9uLXN5YmFzZS1yb290L3BpeGFyL2QyL3NldHMvdG9vbHMtMzEvbGli
L3B5dGhvbjIuNC9zCj5pdGUtcGFja2FnZXMvU3liYXNlLnB5IiwgbGluZSA4NjcsIGluIF9faW5p
dF9fCj4gICAgIHNlbGYuY29ubmVjdCgpCj4gICBGaWxlCj4gIi92YXIvdG1wL3B5dGhvbi1zeWJh
c2Utcm9vdC9waXhhci9kMi9zZXRzL3Rvb2xzLTMxL2xpYi9weXRob24yLjQvcwo+aXRlLXBhY2th
Z2VzL1N5YmFzZS5weSIsIGxpbmUgODg2LCBpbiBjb25uZWN0Cj4gICAgIHN0YXR1cyA9IGNvbm4u
Y3RfY29ubmVjdChzZWxmLmRzbikKPiAgIEZpbGUKPiAiL3Zhci90bXAvcHl0aG9uLXN5YmFzZS1y
b290L3BpeGFyL2QyL3NldHMvdG9vbHMtMzEvbGliL3B5dGhvbjIuNC9zCj5pdGUtcGFja2FnZXMv
U3liYXNlLnB5IiwgbGluZSAyMDAsIGluIF9zZXJ2ZXJtc2dfY2IKPiAgICAgcmFpc2UgRGF0YWJh
c2VFcnJvcihfZm10X3NlcnZlcihtc2cpKQo+ICAgRmlsZQo+ICIvdmFyL3RtcC9weXRob24tc3li
YXNlLXJvb3QvcGl4YXIvZDIvc2V0cy90b29scy0zMS9saWIvcHl0aG9uMi40L3MKPml0ZS1wYWNr
YWdlcy9TeWJhc2UucHkiLCBsaW5lIDE2NywgaW4gX2ZtdF9zZXJ2ZXIKPiAgICAgX2N0eC5kZWJ1
Z19tc2codGV4dCkKPiBUeXBlRXJyb3I6IGFyZ3VtZW50IDEgbXVzdCBiZSBzdHJpbmcgd2l0aG91
dCBudWxsIGJ5dGVzLCBub3Qgc3RyCj4KPiBBbnlib2R5IHNlZW4gYW55dGhpbmcgbGlrZSB0aGlz
Pwo+Cj4gVGhhbmtzLAo+IC1UYXJhCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPiBQeXRob24tc3liYXNlIG1haWxpbmcgbGlzdAo+IFB5dGhvbi1zeWJh
c2VAd3d3Lm9iamVjdC1jcmFmdC5jb20uYXUKPiBodHRwczovL3d3dy5vYmplY3QtY3JhZnQuY29t
LmF1L2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9weXRob24tc3liCj5hc2UKCgpQcml2aWxlZ2Vk
IG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBtYXkgYmUgY29udGFpbmVkIGluIHRoaXMgbWVz
c2FnZS4gIElmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUgb2YgdGhpcyBtZXNzYWdlIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gYW5kIHRoZXJlYWZ0ZXIgZGVsZXRlIHRoZSBt
ZXNzYWdlLCBhbmQgeW91IG1heSBub3QgdXNlLCBjb3B5LCBkaXNjbG9zZSBvciByZWx5IG9uIHRo
ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gaXQuIEludGVybmV0IGUtbWFpbCBtYXkgYmUgc3Vz
Y2VwdGlibGUgdG8gZGF0YSBjb3JydXB0aW9uLCBpbnRlcmNlcHRpb24gYW5kIHVuYXV0aG9yaXNl
ZCBhbWVuZG1lbnQgZm9yIHdoaWNoIFdhbGwgU3RyZWV0IFN5c3RlbXMgZG9lcyBub3QgYWNjZXB0
IGxpYWJpbGl0eS4gV2hpbHN0IHdlIGhhdmUgdGFrZW4gcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0
byBlbnN1cmUgdGhhdCB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGhhdmUgYmVlbiBz
d2VwdCBmb3IgdmlydXNlcywgV2FsbCBTdHJlZXQgU3lzdGVtcyBkb2VzIG5vdCBhY2NlcHQgbGlh
YmlsaXR5IGZvciBhbnkgZGFtYWdlIHN1c3RhaW5lZCBhcyBhIHJlc3VsdCBvZiB2aXJ1c2VzLiAg
U3RhdGVtZW50cyBpbiB0aGlzIG1lc3NhZ2Ugb3IgYXR0YWNobWVudHMgdGhhdCBkbyBub3QgcmVs
YXRlIHRvIHRoZSBidXNpbmVzcyBvZiAgV2FsbCBTdHJlZXQgU3lzdGVtcyBhcmUgbmVpdGhlciBn
aXZlbiBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkgb3IgaXRzIERpcmVjdG9ycy4NCgo=

[python-sybase] Stored procedure do not work if they require chainedMode to be off

[<fra...@nx...>]

Ensemble, faisons un geste pour l'environnement : n'imprimons nos mails que=
 si n=E9cessaire.

L'integrite de ce message n'etant pas assuree sur internet, Natexis
Banques Populaires ne peut etre tenu responsable de
son contenu. Toute utilisation ou diffusion non autorisee est
interdite. Si vous n'etes pas destinataire de ce message, merci de le
detruire et d'avertir l'expediteur.


Let us mind the environment : let's print our mails only when necessary

The integrity of this message cannot be guaranteed
on the Internet. Natexis Banques Populaires can not therefore be
considered responsible for the contents.Any unauthorized use or=
 dissemination is prohibited.
If you are not the intended recipient of this message, then please delete=
 it and=0D
notify the sender.

Re: [python-sybase] Coredumps with Python 2.5 / Solaris 10

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

T24gRnJpZGF5IDIwIE9jdG9iZXIgMjAwNiAwNToyMiwgQW5kcmV3IE1jTmFtYXJhIHdyb3RlOgo+
ID5BbGwgb2Ygd2hpY2ggaXMgdGVsbGluZyBtZSBzb21ldGhpbmcgaXMgY29ycnVwdGluZyBoZWFw
IG1lbW9yeS4gCj4gPiBTb21lIG5vdGVzIGluIHRoZSAyLjUgcmVsZWFzZSBub3RlcyBpbmRpY2F0
ZSB0aGUgbWVtb3J5IG1nbXQgZm9yCj4gPiBDIGV4dGVuc2lvbnMgaGFzIGJlZW4gYWx0ZXJlZCBi
dXQgYXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlIHN5YmFzZQo+ID4gbW9kdWxlIGRvZXNuJ3QgdXNl
IHRpZWhyIHRoZSBQeU1lbV9NYWxsb2Mgb3IgUHlPYmplY3RfTWFsbG9jCj4gPiBjYWxscyBkaXNj
dXNzZWQgdGhlcmUuCj4KPiBXaGF0IG1ha2VzIHRoZXNlIGZhaWx1cmVzIGRpZmZpY3VsdCB0byBk
ZWJ1ZyBpcyB0aGF0IHRoZSBjcmFzaAo+IGhhcHBlbnMgYXdheSBmcm9tIHRoZSBzb3VyY2Ugb2Yg
dGhlIGNvcnJ1cHRpb24sIHNvIGFueXRoaW5nIHRoYXQKPiBjbG9zZXMgdGhhdCBnYXAgd2lsbCBo
ZWxwIGlzb2xhdGUgdGhlIHNvdXJjZS4KPgo+IEluIHRoZSBwYXN0LCBJJ3ZlIHVzZWQgdGVjaG5p
cXVlcyBzdWNoIGFzIGEgImNhbmFyeSIgZnVuY3Rpb24gdGhhdAo+IHBlcmZvcm1zIGEgc2VyaWVz
IG9mIHJhbmRvbWx5IHNpemVkIGFsbG9jYXRpb25zIGFuZCB0aGVuIGZyZWVzCj4gdGhlbSwgaW4g
dGhlIGhvcGUgdGhhdCB0aGlzIHdpbGwgdHJpcCB1cCBvbiB0aGUgY29ycnVwdGlvbi4gSSB0aGVu
Cj4gc3RyYXRlZ2ljYWxseSBsaXR0ZXIgdGhlIGNvZGUgd2l0aCBjYWxscyB0byB0aGlzIGZ1bmN0
aW9uLiBJdCBtaWdodAo+IGFsc28gaGVscCBpZiB0aGUgY2FuYXJ5IGZ1bmN0aW9uIHdyaXRlcyBh
ICJoYXJkIHRvIHN3YWxsb3ciCj4gcGF0dGVybiwgc3VjaCBhcyAweEE1QTVBNUE1LCB0byB0aGUg
bWVtb3J5IGl0IGFsbG9jYXRlcyBwcmlvciB0bwo+IGZyZWVpbmcgaXQuCgpJZiB5b3UgYXJlIG9u
IExpbnV4LCB2YWxncmluZCAoaHR0cDovL3ZhbGdyaW5kLm9yZy8pIGlzIHlvdXIgZnJpZW5kLgpC
dXQgSSBzZWUgdGhhdCBHcmVnb3J5IGFscmVhZHkgcGF0Y2hlZCB0aGlzIG9uZS4uLiB0aGFua3Mh
CgpIYXJyaQoKClByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBj
b250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiAgSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBv
ZiB0aGlzIG1lc3NhZ2UgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBhbmQgdGhl
cmVhZnRlciBkZWxldGUgdGhlIG1lc3NhZ2UsIGFuZCB5b3UgbWF5IG5vdCB1c2UsIGNvcHksIGRp
c2Nsb3NlIG9yIHJlbHkgb24gdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBpdC4gSW50ZXJu
ZXQgZS1tYWlsIG1heSBiZSBzdXNjZXB0aWJsZSB0byBkYXRhIGNvcnJ1cHRpb24sIGludGVyY2Vw
dGlvbiBhbmQgdW5hdXRob3Jpc2VkIGFtZW5kbWVudCBmb3Igd2hpY2ggV2FsbCBTdHJlZXQgU3lz
dGVtcyBkb2VzIG5vdCBhY2NlcHQgbGlhYmlsaXR5LiBXaGlsc3Qgd2UgaGF2ZSB0YWtlbiByZWFz
b25hYmxlIHByZWNhdXRpb25zIHRvIGVuc3VyZSB0aGF0IHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0
YWNobWVudHMgaGF2ZSBiZWVuIHN3ZXB0IGZvciB2aXJ1c2VzLCBXYWxsIFN0cmVldCBTeXN0ZW1z
IGRvZXMgbm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBkYW1hZ2Ugc3VzdGFpbmVkIGFzIGEg
cmVzdWx0IG9mIHZpcnVzZXMuICBTdGF0ZW1lbnRzIGluIHRoaXMgbWVzc2FnZSBvciBhdHRhY2ht
ZW50cyB0aGF0IGRvIG5vdCByZWxhdGUgdG8gdGhlIGJ1c2luZXNzIG9mICBXYWxsIFN0cmVldCBT
eXN0ZW1zIGFyZSBuZWl0aGVyIGdpdmVuIG5vciBlbmRvcnNlZCBieSB0aGUgY29tcGFueSBvciBp
dHMgRGlyZWN0b3JzLg0KCg==

[PATCH] Re: [python-sybase] Coredumps with Python 2.5 / Solaris 10

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

On 20/10/06 12:46 PM, "Gregory Bond" <gn...@it...> wrote:

> I'm really struggling with making the 0.37 module work with Python 2.5.  I'm
> getting some SIGSEGVs buried deep in the Python core, usually in the
> realloc/free calls, in all sorts of internal Python objects (e.g.
> PyList_Append(), PyDict_SetItem() etc) that really orta be very well tested
> and debugged!
> 
> If I configure Python with either --with-pydebug or --without--pymalloc
> options (i.e. Changing the way objects/mallocs work) then the resulting
> Python version works fine with the Sybase module.  SunPro or GCC compiled,
> both fail.
> 
> Python 2.4.4 works fine with no special config options.
> 
> All of which is telling me something is corrupting heap memory.  Some notes
> in the 2.5 release notes indicate the memory mgmt for C extensions has been
> altered but as far as I can see, the sybase module doesn't use tiehr the
> PyMem_Malloc or PyObject_Malloc calls discussed there.

Found it. (I think..... Still a bit new to the Python extending caper.)

The varous *_dealloc() functions in sybasect were using PyMem_DEL() to
release memory.  Under 2.5, this needs to be PyObject_DEL() as the default
2.5 Python allocator keeps these in separate pools.

Patch attached!

Re: [python-sybase] Coredumps with Python 2.5 / Solaris 10

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

>All of which is telling me something is corrupting heap memory.  Some notes
>in the 2.5 release notes indicate the memory mgmt for C extensions has been
>altered but as far as I can see, the sybase module doesn't use tiehr the
>PyMem_Malloc or PyObject_Malloc calls discussed there.

What makes these failures difficult to debug is that the crash happens
away from the source of the corruption, so anything that closes that
gap will help isolate the source.

In the past, I've used techniques such as a "canary" function that
performs a series of randomly sized allocations and then frees them, in
the hope that this will trip up on the corruption. I then strategically
litter the code with calls to this function. It might also help if the
canary function writes a "hard to swallow" pattern, such as 0xA5A5A5A5,
to the memory it allocates prior to freeing it.

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

[python-sybase] Coredumps with Python 2.5 / Solaris 10

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

I'm really struggling with making the 0.37 module work with Python 2.5.  I'm
getting some SIGSEGVs buried deep in the Python core, usually in the
realloc/free calls, in all sorts of internal Python objects (e.g.
PyList_Append(), PyDict_SetItem() etc) that really orta be very well tested
and debugged!

If I configure Python with either --with-pydebug or --without--pymalloc
options (i.e. Changing the way objects/mallocs work) then the resulting
Python version works fine with the Sybase module.  SunPro or GCC compiled,
both fail.

Python 2.4.4 works fine with no special config options.

All of which is telling me something is corrupting heap memory.  Some notes
in the 2.5 release notes indicate the memory mgmt for C extensions has been
altered but as far as I can see, the sybase module doesn't use tiehr the
PyMem_Malloc or PyObject_Malloc calls discussed there.

Has anyone else succeeded in using the Sybase module with Python 2.5?

Sparc / Solaris 10 
Sybase 12_5_3 libraries

[python-sybase] problem with python-sybase 0.37 and OCS 15.0

[Tara H. <ta...@pi...>]

We have been running 0.36 against OCS 12.5 libraries on Fedora for a 
while with no problem, but only with a 32 bit configuration.  We finally 
got 64 bit libraries via a new Sybase OCS 15.0 package , and once I 
patched up the setup.py to use the correct libraries, everything built 
out and I was able to do an "import Sybase".

However, if I actually try to make a connection to the db, I get a 
really weird error that I don't understand (obviously this works with 
the old setup):

test code:

import os
os.putenv('SYBASE','/usr/sybase')
import Sybase
user = 'hitech'
password = 'hitech'
conn = Sybase.connect('DBSERVER',user,password,auto_commit=1)

error:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File 
"/var/tmp/python-sybase-root/pixar/d2/sets/tools-31/lib/python2.4/site-packages/Sybase.py", 
line 1005, in connect
    strip, auto_commit, delay_connect, locking)
  File 
"/var/tmp/python-sybase-root/pixar/d2/sets/tools-31/lib/python2.4/site-packages/Sybase.py", 
line 867, in __init__
    self.connect()
  File 
"/var/tmp/python-sybase-root/pixar/d2/sets/tools-31/lib/python2.4/site-packages/Sybase.py", 
line 886, in connect
    status = conn.ct_connect(self.dsn)
  File 
"/var/tmp/python-sybase-root/pixar/d2/sets/tools-31/lib/python2.4/site-packages/Sybase.py", 
line 200, in _servermsg_cb
    raise DatabaseError(_fmt_server(msg))
  File 
"/var/tmp/python-sybase-root/pixar/d2/sets/tools-31/lib/python2.4/site-packages/Sybase.py", 
line 167, in _fmt_server
    _ctx.debug_msg(text)
TypeError: argument 1 must be string without null bytes, not str

Anybody seen anything like this?

Thanks,
-Tara

[python-sybase] datetime and 64 bit patch

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

Hi,

Please find attached the patches I use over vanilla sybase-0.37 to 
make it work on 64 systems, using python's native datetime type.

I've tested it on Sybase 12.5

Mandriva 2006 32 and 64 bit, python 2.4.1, gcc 4.0.1
RedHat ES 4 64 bit, python 2.3.4, gcc 3.4.3
HP-UX 11.23 Itanium 64 bit, python 2.4, gcc 3.4.3

Regards,

Harri




Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Wall Street Systems does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Wall Street Systems does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of  Wall Street Systems are neither given nor endorsed by the company or its Directors.

Re: [python-sybase] varchar(350) data getting truncated to 255 characters

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

V2hpY2ggVERTIHZlcnNpb24gYXJlIHlvdSB1c2luZz8KSWYgeW91IHB1dCAKICAgICAgICB0ZHMg
dmVyc2lvbiA9IDcuMAoKaW4gdG8geW91ciAuZnJlZXRkcy5jb25mIGZvciB0aGUgZGIgaW4gcXVl
c3Rpb24sIGRvZXMgaXQgc3RpbGwgZmFpbD8KCi1IYXJyaQoKCk9uIFNhdHVyZGF5IDIzIFNlcHRl
bWJlciAyMDA2IDE1OjUwLCBQeXRob24gd3JvdGU6Cj4gT24gRnJpLCAyMDA2LTA5LTIyIGF0IDE2
OjAyIC0wNDAwLCBQeXRob24gd3JvdGU6Cj4gPiBJIGFtIHJ1bm5pbmcgTGludXggKEZlZG9yYSAz
KSB3aXRoCj4gPiAJc3liYXNlIDAuMzcKPiA+IAlmcmVldGRzIDAuNjMKPiA+IHRvIGNvbGxlY3Qg
ZGF0YSBmcm9tIGEgcmVtb3RlIE1pY3Jvc29mdCBTUUwgc2VydmVyLiAgVGhlcmUgaXMgYXQKPiA+
IGxlYXN0IG9uZSBmaWVsZCB0aGF0IGlzIHRydW5jYXRlZCB0byAyNTUgY2hhcmFjdGVycyBhcyBJ
IHJlYWQgaXQ6Cj4gPiAoY3Vycy5mZXRjaG9uZSgpKQo+ID4KPiA+IFRoZSBjdXJzLmRlc2NyaXB0
aW9uIHNob3dzOgo+ID4gCSgnRmVhdHVyZXMnLCAxLCAwLCAyNTUsIDAsIDAsIDEpCj4gPiAJKCdS
ZW1hcmtzJywgMSwgMCwgMjU1LCAwLCAwLCAxKQo+ID4KPiA+IEhvd2V2ZXIsIHRob3NlIGZpZWxk
cyBhcmUgYWN0dWFsbHkgZGVmaW5lZCBhcyB2YXJjaGFyKDM1MCkuCj4gPgo+ID4gSXMgdGhpcyBh
IGxpbWl0YXRpb24gaW4gdGhlIG1vZHVsZXM/ICBBbSBJIGRvaW5nIHNvbWV0aGluZyB3cm9uZz8K
Pgo+IEkgdHJhY2tlZCBkb3duIHRoZSBpc3N1ZSB0byBmcmVldGRzLiAgSXQgbGltaXRzIHZhcmNo
YXIgZmllbGRzIHRvCj4gMjU1IGNoYXJzLiAgVGhlIGZyZWV0ZHMgc2l0ZSByZWNvbW1lbmRzIGNv
bnZlcnRpbmcgb3IgY2FzdGluZyB0aGUKPiBmaWVsZHMgdG8gdGV4dC4KPgo+IGh0dHA6Ly93d3cu
ZnJlZXRkcy5vcmcvdXNlcmd1aWRlL3Ryb3VibGVzaG9vdGluZy5odG0jS05PV05JU1NVRVMKPiBo
YXMgdGhlIGRldGFpbHMuCj4KPiA+IFNob3VsZCBJIGJlIHVzaW5nIGEgZGlmZmVyZW50IHNldCBv
ZiBtb2R1bGVzIHRvIGNvbm5lY3QgYSBQeXRob24KPiA+IHByb2dyYW0gdG8gYSByZW1vdGUgTWlj
cm9zb2Z0IFNRTCBzZXJ2ZXI/CgoKUHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRp
b24gbWF5IGJlIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UuICBJZiB5b3UgYXJlIG5vdCB0aGUg
YWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmV0
dXJuIGFuZCB0aGVyZWFmdGVyIGRlbGV0ZSB0aGUgbWVzc2FnZSwgYW5kIHlvdSBtYXkgbm90IHVz
ZSwgY29weSwgZGlzY2xvc2Ugb3IgcmVseSBvbiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu
IGl0LiBJbnRlcm5ldCBlLW1haWwgbWF5IGJlIHN1c2NlcHRpYmxlIHRvIGRhdGEgY29ycnVwdGlv
biwgaW50ZXJjZXB0aW9uIGFuZCB1bmF1dGhvcmlzZWQgYW1lbmRtZW50IGZvciB3aGljaCBXYWxs
IFN0cmVldCBTeXN0ZW1zIGRvZXMgbm90IGFjY2VwdCBsaWFiaWxpdHkuIFdoaWxzdCB3ZSBoYXZl
IHRha2VuIHJlYXNvbmFibGUgcHJlY2F1dGlvbnMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlLW1haWwg
YW5kIGFueSBhdHRhY2htZW50cyBoYXZlIGJlZW4gc3dlcHQgZm9yIHZpcnVzZXMsIFdhbGwgU3Ry
ZWV0IFN5c3RlbXMgZG9lcyBub3QgYWNjZXB0IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSBzdXN0
YWluZWQgYXMgYSByZXN1bHQgb2YgdmlydXNlcy4gIFN0YXRlbWVudHMgaW4gdGhpcyBtZXNzYWdl
IG9yIGF0dGFjaG1lbnRzIHRoYXQgZG8gbm90IHJlbGF0ZSB0byB0aGUgYnVzaW5lc3Mgb2YgIFdh
bGwgU3RyZWV0IFN5c3RlbXMgYXJlIG5laXRoZXIgZ2l2ZW4gbm9yIGVuZG9yc2VkIGJ5IHRoZSBj
b21wYW55IG9yIGl0cyBEaXJlY3RvcnMuDQoK

[python-sybase] Sybase and SQLAlchemy?

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

Has anyone looked at hooking up SQLAlchemy and the Python Sybase module?
SQLAlchemy doesn't currently support Sybase and there's no documentation to
guide me as far as I could tell.  Still, the MySQL adapter seems fairly
straightforward, and it also supports PostgreSQL, Oracle and PySQLite, so it
seems like it should be doable.

-- 
Skip Montanaro - sk...@po... - http://www.mojam.com/
"In China today, Bill Gates is Britney Spears.  In America today, Britney
Spears is Britney Spears - and that is our problem."  Thomas L. Friedman in
"The World is Flat"

Re: [python-sybase] varchar(350) data getting truncated to 255 characters (final resolution)

[Python <py...@ve...>]

On Sat, 2006-09-23 at 09:50 -0400, Python wrote:
> On Fri, 2006-09-22 at 16:02 -0400, Python wrote:
> > I am running Linux (Fedora 3) with
> > 	sybase 0.37
> > 	freetds 0.63
> > to collect data from a remote Microsoft SQL server.  There is at least
> > one field that is truncated to 255 characters as I read it:
> > 	(curs.fetchone())
> > 
> > The curs.description shows:
> > 	('Features', 1, 0, 255, 0, 0, 1)
> > 	('Remarks', 1, 0, 255, 0, 0, 1)
> > 
> > However, those fields are actually defined as varchar(350).
> > 
> > Is this a limitation in the modules?  Am I doing something wrong?
> 
> I tracked down the issue to freetds.  It limits varchar fields to 255
> chars.  The freetds site recommends converting or casting the fields to
> text.
> 
> http://www.freetds.org/userguide/troubleshooting.htm#KNOWNISSUES
> has the details.
> 
> > Should I be using a different set of modules to connect a Python program
> > to a remote Microsoft SQL server?

By configuring a server into the /etc/freetds.conf file, I was able to
specify a different protocol version and the varchar sizes are now
reported properly.  In summary, I did not use the CAST(column AS TEXT)
advice, but instead added a server definition to the freetds.conf file
using the following as a model.

# A typical Microsoft SQL Server 2000 configuration
;[MyServer2k]
;       host = ntmachine.domain.com
;       port = 1433
;       tds version = 8.0


-- 
Lloyd Kvam
Venix Corp

Re: [python-sybase] varchar(350) data getting truncated to 255 characters

[Python <py...@ve...>]

On Fri, 2006-09-22 at 16:02 -0400, Python wrote:
> I am running Linux (Fedora 3) with
> 	sybase 0.37
> 	freetds 0.63
> to collect data from a remote Microsoft SQL server.  There is at least
> one field that is truncated to 255 characters as I read it:
> 	(curs.fetchone())
> 
> The curs.description shows:
> 	('Features', 1, 0, 255, 0, 0, 1)
> 	('Remarks', 1, 0, 255, 0, 0, 1)
> 
> However, those fields are actually defined as varchar(350).
> 
> Is this a limitation in the modules?  Am I doing something wrong?

I tracked down the issue to freetds.  It limits varchar fields to 255
chars.  The freetds site recommends converting or casting the fields to
text.

http://www.freetds.org/userguide/troubleshooting.htm#KNOWNISSUES
has the details.

> Should I be using a different set of modules to connect a Python program
> to a remote Microsoft SQL server?

-- 
Lloyd Kvam
Venix Corp

[python-sybase] varchar(350) data getting truncated to 255 characters

[Python <py...@ve...>]

I am running Linux (Fedora 3) with
	sybase 0.37
	freetds 0.63
to collect data from a remote Microsoft SQL server.  There is at least
one field that is truncated to 255 characters as I read it:
	(curs.fetchone())

The curs.description shows:
	('Features', 1, 0, 255, 0, 0, 1)
	('Remarks', 1, 0, 255, 0, 0, 1)

However, those fields are actually defined as varchar(350).

Is this a limitation in the modules?  Am I doing something wrong?
Should I be using a different set of modules to connect a Python program
to a remote Microsoft SQL server?

-- 
Lloyd Kvam
Venix Corp

[python-sybase] Re: Python-sybase Digest, Vol 14, Issue 3

[Clinton J. <cj...@ca...>]

>> I have a patch for 64 bit machines.  Where is bug tracking? I can't seem 
>> to find it.
> 
> Seems to be right here on this list.  Post your patch if it's not too
> big.
> 
>         Greg
>

Sybase.py

188c188
<     mn = msg.msgnumber
---
 >     mn = msg.msgnumber & 0xFFFFFFFF


I saw 5701 + 0xFFFFFFFF come across as I tried to make a connection.  By 
masking it off I fixed the problem.  Not sure if this is the correct 
solution, but it worked for me.

Clinton