python-sybase-misc Mailing List for Sybase module for Python (Page 19)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

<html><body>

<br>
</body></html>

<html><body>
<img src="cid:eijwhhnmik.bmp"><br>
</body></html>

> I'm using SunOS 5.8, Sybase ASE 12.5.1, and Python-Sybase 0.36
> with Python 2.3, and am finding that queries which cause Python
> exceptions often also result in segmentation faults.  Has anyone
> else seen this problem?

Yes, I see it frequently though I can't get your precise example to
choke at the moment.  I had chalked it up to the rather weird environment
I'm using (Solaris/Intel, with the Sybase include files copied over from
a SPARC setup because Sybase refused to provide any <harrumph>), but perhaps
that's not the cause.

Skip Montanaro
sk...@po...

Paul Rensing wrote:

>Hi. I recently updated to FreeTDS 0.62.3 and Sybase 0.36 (used to have
>0.36pre6 installed). Now, I am suddenly having a problem reading tables
>I could read before. 
>
>The culprit is a column which is of type CS_LONG_TYPE. There is no
>conversion method in databuf.c DataBuf_item() for that type. I fixed it
>(correctly?) by adding at line 183:
>
>    case CS_LONG_TYPE:
>	return PyLong_FromLongLong(*(long long *)item);
>
>Note I could not use "(CS_LONG *)" because the header file from FreeTDS
>lists CS_LONG as an int (4 bytes) instead of a long long (8 bytes).
>
>Does this make sense, or am I missing something?
>  
>
You should probably also add code that allows you to copy Python longs 
into a CS_LONG_TYPE buffer in the DataBuf_ass_item() function.  Without 
doing this you will not be able to pass CS_LONG values back to Sybase.  
This is not really such a big deal as Sybase will convert from other types.

- Dave

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

I'm using SunOS 5.8, Sybase ASE 12.5.1, and Python-Sybase 0.36
with Python 2.3, and am finding that queries which cause Python
exceptions often also result in segmentation faults.  Has anyone
else seen this problem?

Here's a sample traceback/core dump:

-----------------------------------------------------------------------
$ python ~/demo_sybase_segfault.py
Traceback (most recent call last):
   File "/home/mitch/demo_sybase_segfault.py", line 4, in ?
     cursor.execute("SELECT COUNT(*) FROM NonexistentTable")
   File "/usr/local/pkg/python/lib/python2.3/site-packages/Sybase.py", 
line 687, in execute
     self.description = fetcher.start(self.arraysize)
   File "/usr/local/pkg/python/lib/python2.3/site-packages/Sybase.py", 
line 442, in start
     return self._start_results()
   File "/usr/local/pkg/python/lib/python2.3/site-packages/Sybase.py", 
line 546, in _start_results
     status, result = self._cmd.ct_results()
   File "/usr/local/pkg/python/lib/python2.3/site-packages/Sybase.py", 
line 161, in _servermsg_cb
     raise DatabaseError(_fmt_server(msg))
Sybase.DatabaseError: Msg 208, Level 16, State 1, Line 1
NonexistentTable not found. Specify owner.objectname or use sp_help to 
check whether the object exists (sp_help may produce lots of output).

Fatal Python error: unexpected exception during garbage collection
Abort (core dumped)
-----------------------------------------------------------------------

Here's the script which produces the above output:

-----------------------------------------------------------------------
import Sybase
db = Sybase.connect("server", "username", "passwd", "db")
cursor = db.cursor()
cursor.execute("SELECT COUNT(*) FROM NonexistentTable")
db.close()
-----------------------------------------------------------------------

I can collect more info (gdb tracebacks, etc.) if anyone needs it.

Thanks for any help.

--
Mitch

Hi. I recently updated to FreeTDS 0.62.3 and Sybase 0.36 (used to have
0.36pre6 installed). Now, I am suddenly having a problem reading tables
I could read before. 

The culprit is a column which is of type CS_LONG_TYPE. There is no
conversion method in databuf.c DataBuf_item() for that type. I fixed it
(correctly?) by adding at line 183:

    case CS_LONG_TYPE:
	return PyLong_FromLongLong(*(long long *)item);

Note I could not use "(CS_LONG *)" because the header file from FreeTDS
lists CS_LONG as an int (4 bytes) instead of a long long (8 bytes).

Does this make sense, or am I missing something?

	Paul Rensing

-- 
Paul Rensing <pre...@ci...>
Cimetrics, Inc.
-- 
Paul Rensing <pau...@ve...>

Hi. I recently updated to FreeTDS 0.62.3 and Sybase 0.36 (used to have
0.36pre6 installed). Now, I am suddenly having a problem reading tables
I could read before. 

The culprit is a column which is of type CS_LONG_TYPE. There is no
conversion method in databuf.c DataBuf_item() for that type. I fixed it
(correctly?) by adding at line 183:

    case CS_LONG_TYPE:
	return PyLong_FromLongLong(*(long long *)item);

Note I could not use "(CS_LONG *)" because the header file from FreeTDS
lists CS_LONG as an int (4 bytes) instead of a long long (8 bytes).

Does this make sense, or am I missing something?

	Paul Rensing

-- 
Paul Rensing <pre...@ci...>
Cimetrics, Inc.

I'm not able to use multiple open cursors.  For example, if I execute
a SQL statement on one cursor and then try to execute another SQL
statement on a second cursor I get a DatabaseError exception:

    >>> c1 = conn.cursor()
    >>> c1.execute("select 1")
    >>> c2 = conn.cursor()
    >>> c2.execute("select 2")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/opt/python/lib/python2.3/site-packages/Sybase.py", line 688, in execute    self.description = fetcher.start(self.arraysize)
      File "/opt/python/lib/python2.3/site-packages/Sybase.py", line 440, in start
	status = self._cmd.ct_send()
      File "/opt/python/lib/python2.3/site-packages/Sybase.py", line 158, in _clientmsg_cb
	raise DatabaseError(_fmt_client(msg))
    DatabaseError: Layer: 1, Origin: 1
    ct_send(): user api layer: external error: This routine cannot be called because another command structure has results pending.

If I call nextset() to discard results or explicitly close the cursor
I can execute a statement in another cursor.  Most of my past
Python+SQL experience is with MySQLdb which does allow this sort of
thing.  This is probably a lack of understanding on my part.  Am I not
able to have multiple active cursors?

Thx,

-- 
Skip Montanaro
sk...@po...

<html><body>

<br>
</body></html>

<html><body>

<br>
</body></html>

Dave et al,

Attached is an updated mod to Sybase.py which implements the type converters
idea I posted earlier today.  Mostly it just fixes bugs in parts of the code
I hadn't exercised previously.

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://www.spambayes.org/
sk...@po...

    >> I'm trying to get the Object Craft Sybase module used at work instead
    >> of a homegrown hack.  Based upon a lot of use of the homegrown
    >> module, one requirement is that dates be represented as floating
    >> point seconds since the Unix epoch.  It appears that Sybase returns
    >> some sort of DateTime object....

    >> Can I cleanly get from a DateTime object to a float or do I have to
    >> inject a new version of _column_value() into Sybase.py?  ('Twould be
    >> nice if there was a standard way to establish type converters on a
    >> per-connection basis.)

    ...

    >>  Error: Layer: 2, Origin: 1
    >>  cs_convert: cslib user api layer: external error: Conversion between 12 and 10 datatypes is not supported.

    Dave> That is strange.  Looking into the Sybase include files this seems
    Dave> to be saying that it will not convert from CS_DATETIME_TYPE to
    Dave> CS_FLOAT_TYPE.  I am fairly sure that this should work.  What
    Dave> version of the Sybase client libraries are you using?

We're using 12.5 I believe.  At least SYBASE refers to 12.5:

>>> os.environ.get("SYBASE")
'/opt/sybase-12.5'

Our current environment is a bit weird though.  We're running mostly Solaris
on Intel.  The most recent update from Sybase included libraries but no
include files.  (Sybase indicated this was intentional - apparently you're
not supposed to be able to write clients which run on Solaris/Intel!)  One
of the admins copied the include files from the SPARC platform.  There were
mismatches between the features the include files announced and those the
.so files actually implemented, so I wound up writing a Makefile based upon
the output of the distutils build and started stripping off -DHAVE_... flags
until it would compile, link and import without failure.  I'm left with
these CPPFLAGS:

    CPPFLAGS = -fno-strict-aliasing -DNDEBUG -DHAVE_CT_CURSOR \
               -DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA \
               -DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP \
               -I$(SYBDIR)/include -I$(PYTHONDIR)/include/python2.3

Would any of those -DHAVE... options be related to the error I saw?
(Thankfully we are moving toward Linux, so will hopefully get marginally
better support from Sybase in the future.)

At any rate, I took a first stab yesterday afternoon at adding type
converters to Sybase.py.  The attached context diff against 0.36 is the
current state.  It adds an optional converters argument to the Connection()
call.  If given, it should be a mapping object of some sort which maps a
given Sybase type to a converter function.  I'm hopeful the only slightly
controversial aspect is my inclusion of the standard library's datetime type
at the head of the list of possible date/time types and that the notion of
type converters per se is uncontroversial.  In our environment I'll simply
initalize Connection objects in a wrapper library with a converter like
this:

    >>> import Sybase
    >>> import time
    >>> def dt_as_float(dt):
    ...   return time.mktime(Sybase._convert_datetime(dt).timetuple())
    ... 
    >>> db = Sybase.Connection(..., converters={
    ...               Sybase.DateTimeType: dt_as_float})
    >>> c = db.cursor()
    >>> c.execute("""select date from ... where ...""")
    >>> c.fetchone()
    (919317600.0,)

Skip

<html><body>

<br>
</body></html>

<html><body>

<br>
</body></html>

Skip Montanaro wrote:

>I'm trying to get the Object Craft Sybase module used at work instead of a
>homegrown hack.  Based upon a lot of use of the homegrown module, one
>requirement is that dates be represented as floating point seconds since the
>Unix epoch.  It appears that Sybase returns some sort of DateTime object.
>Given a DateTime object, d, both int(d) and float(d) fail for me with this
>sort of message:
>
>    >>> float(d)
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>      File "/home/titan/skipm/local/lib/python2.3/site-packages/Sybase.py", line 154, in _cslib_cb
>        raise Error(_fmt_client(msg))
>    Error: Layer: 2, Origin: 1
>    cs_convert: cslib user api layer: external error: Conversion between 12 and 10 datatypes is not supported.
>
>Can I cleanly get from a DateTime object to a float or do I have to inject a
>new version of _column_value() into Sybase.py?  ('Twould be nice if there
>was a standard way to establish type converters on a per-connection basis.)
>  
>
That is strange.  Looking into the Sybase include files this seems to be 
saying that it will not convert from CS_DATETIME_TYPE to CS_FLOAT_TYPE.  
I am fairly sure that this should work.  What version of the Sybase 
client libraries are you using?

- Dave

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

Skip Montanaro wrote:

>I have a parameter dictionary filled in after a callproc() call:
>
>    >>> params
>    {'@e_year': <DataBufType object at 0x8138598>, '@e_month': <DataBufType object at 0x81384d0>, '@symbol': 'ZB', '@simulation_date': '20040527'}
>    >>> yr = params['@e_year']
>    >>> dir(yr)
>    ['count', 'datatype', 'format', 'maxlength', 'name', 'precision', 'scale', 'status', 'strip', 'usertype']
>    >>> yr.count
>    1
>    >>> yr.datatype
>    8
>    >>> yr.format
>    0
>    >>> yr.maxlength
>    4
>    >>> yr.name
>    '@e_year'
>    >>> yr.precision
>    0
>    >>> yr.scale
>    0
>    >>> yr.status
>    1024
>    >>> yr.strip
>    0
>    >>> yr.usertype
>    0
>    >>> yr[0]
>    2
>    >>> yr[1]
>    0
>    >>> yr[2]
>    IndexError: buffer index out of range
>    >>> len(yr)
>    1
>    >>> int(yr)
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>    TypeError: int() argument must be a string or a number
>
>but can't tell how to actually get the real value out of it.  The actual
>value for the '@e_year' parameter is supposed to be 104.  I don't see it
>anywhere obvious.  The description of DataBuf objects in the docs doesn't
>seem to jive with what I have.
>
The databuf object is just a chunk of memory that is used by the Sybase 
libraries to exchange data with the server.  You cannot do anything 
interesting with the buffer except read Sybase native types out of the 
buffer to create a Python object, and write Python objects into the 
buffer as a Sybase native type.

What this means is that you need to do something like this:

    >>> params
    {'@e_year': <DataBufType object at 0x8138598>, '@e_month': <DataBufType object at 0x81384d0>, '@symbol': 'ZB', '@simulation_date': '20040527'}
    >>> yr = params['@e_year']
    >>> # yr is a memory buffer containing an array of Sybase native datatypes.
    >>> # We need to retrieve element zero of the array to get a Python object
    >>> # for the column value.
    >>> # The DataBufType is an array in order to support array binding using the
    >>> # Sybase API.
    >>> e_year = yr[0]

I hope that clears some things up.  It is a little non-obvious, but if you look at the fetch_rows() code in the following page you will see that the DataBufType is being used as an array to fetch column values.

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

- Dave

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

I have a parameter dictionary filled in after a callproc() call:

    >>> params
    {'@e_year': <DataBufType object at 0x8138598>, '@e_month': <DataBufType object at 0x81384d0>, '@symbol': 'ZB', '@simulation_date': '20040527'}
    >>> yr = params['@e_year']
    >>> dir(yr)
    ['count', 'datatype', 'format', 'maxlength', 'name', 'precision', 'scale', 'status', 'strip', 'usertype']
    >>> yr.count
    1
    >>> yr.datatype
    8
    >>> yr.format
    0
    >>> yr.maxlength
    4
    >>> yr.name
    '@e_year'
    >>> yr.precision
    0
    >>> yr.scale
    0
    >>> yr.status
    1024
    >>> yr.strip
    0
    >>> yr.usertype
    0
    >>> yr[0]
    2
    >>> yr[1]
    0
    >>> yr[2]
    IndexError: buffer index out of range
    >>> len(yr)
    1
    >>> int(yr)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: int() argument must be a string or a number

but can't tell how to actually get the real value out of it.  The actual
value for the '@e_year' parameter is supposed to be 104.  I don't see it
anywhere obvious.  The description of DataBuf objects in the docs doesn't
seem to jive with what I have.

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://www.spambayes.org/
sk...@po...

I'm trying to get the Object Craft Sybase module used at work instead of a
homegrown hack.  Based upon a lot of use of the homegrown module, one
requirement is that dates be represented as floating point seconds since the
Unix epoch.  It appears that Sybase returns some sort of DateTime object.
Given a DateTime object, d, both int(d) and float(d) fail for me with this
sort of message:

    >>> float(d)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/home/titan/skipm/local/lib/python2.3/site-packages/Sybase.py", line 154, in _cslib_cb
        raise Error(_fmt_client(msg))
    Error: Layer: 2, Origin: 1
    cs_convert: cslib user api layer: external error: Conversion between 12 and 10 datatypes is not supported.

Can I cleanly get from a DateTime object to a float or do I have to inject a
new version of _column_value() into Sybase.py?  ('Twould be nice if there
was a standard way to establish type converters on a per-connection basis.)

Thanks,

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://www.spambayes.org/
sk...@po...

<html><body>

<br>Attached file is protected with the password for  security reasons.  Password is <img src="cid:ebtkttislp.bmp"><br>
<br>
</body></html>

<html><body>

<br>
</body></html>

Skip Montanaro wrote:

>I'm new to Sybase and the Object Craft Sybase module, but have used both
>MySQL and PostgreSQL from Python extensively.  Both the MySQLdb and psycopg
>packages allow users to get select results as lists of dictionaries instead
>of just as lists of tuples.  Predictably, since this behavior isn't
>specified in the Python DB API, the two wrappers implemented this feature in
>different ways.
>
>  
>
For a better method, please consider my db_row package at:

    http://opensource.theopalgroup.com/

It provides dictionary, object, and tuple style interfaces in a way that 
is both
fast and memory efficient.

-Kevin

I'm new to Sybase and the Object Craft Sybase module, but have used both
MySQL and PostgreSQL from Python extensively.  Both the MySQLdb and psycopg
packages allow users to get select results as lists of dictionaries instead
of just as lists of tuples.  Predictably, since this behavior isn't
specified in the Python DB API, the two wrappers implemented this feature in
different ways.

Something like the following only lightly tested extension seems like a
reasonable step in that direction for the Sybase module.  It's more akin to
the way MySQLdb does things (instantiate different cursors instead of
replicating the fetch* methods for list-of-dict), though to avoid messing
with Sybase.Connection.cursor() I simply sublcassed Sybase.Connection and
instantiate that.

    import Sybase

    class Connection(Sybase.Connection):
        def dictcursor(self):
            return DictCursor(self)

    class DictCursor(Sybase.Cursor):
        def row2dict(self, row):
            d = {}
            for i,elt in enumerate(row):
                d[self.description[i][0]] = elt
            return d

        def fetchall(self):
            rows = Sybase.Cursor.fetchall(self)
            result = [] 
            for row in rows:
                result.append(self.row2dict(row))
            return result

        def fetchone(self):
            return row2dict(Sybase.Cursor.fetchone(self))

        def fetchmany(self):
            rows = Sybase.Cursor.fetchmany(self)
            result = [] 
            for row in rows:
                result.append(self.row2dict(row))
            return result

While it's obviously not hard to implement lists of dicts results (and thus
all Sybase users could do it should they choose) manipulating lists of dicts
makes code so much more readable that I never use the lists of tuples form
anymore.  I think this would be a handy addition to the Sybase module.  If
it's deemed reasonable, I'd suggest just changing the signature of the
Connection.cursor() method to take an optional cursorclass argument which
would default to the current Sybase.Cursor class and add a DictCursor class
akin to the above to Sybase.py.

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://www.spambayes.org/
sk...@po...

Hi,

I am trying to compile the sybase python module on OS X and I am able=20
to get it to compile by using python 2.2 (from Fink) with FreeTDS 6.2,=20=

but as soon as I try to import the module, I get the following linking=20=

error. Any ideas? I have come through a few post referring to similar=20
problems but never with a solution.

Thank you in advance for your help.

 >>> import Sybase
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "Sybase.py", line 20, in ?
     from sybasect import *
ImportError: Failure linking new module: : dyld: python Undefined=20
symbols:
_cs_config
_cs_convert
_cs_ctx_alloc
_cs_ctx_drop
_cs_dt_crack
_cs_dt_info
_cs_loc_alloc
_cs_loc_drop
_cs_locale
_ct_bind
_ct_callback
_ct_cancel
_ct_close
_ct_cmd_alloc
_ct_cmd_drop
_ct_command
_ct_con_alloc
_ct_con_drop
_ct_con_props
_ct_config
_ct_connect
_ct_describe
_ct_exit
_ct_fetch
_ct_get_data
_ct_init
_ct_options
_ct_param
_ct_res_info
_ct_results
_ct_send

S=E9bastien

I have a number of stored procedures that use raiseerror to report 
problems. I don't normally see those messages when executing these 
routines via the execute() method. I have seen them when there is a 
subsequent error exception raised in the python code. It would appear 
that the messages are being queued somewhere but not passed to the error 
handlers. 

A check of the mail archives shows some routines for adding custom 
error handles like I have done in the past with C language code. 
however these still don't seem to report the custom messages.

does any one know who to get these messages showing?

dave

(I'm not subscribed.  I just downloaded the sybase module today for the
first time to try it out and am passing along my findings.)

I downloaded 0.36 today to a Solaris 9/Intel system and built it.  GCC
complained:

    sybasect.c: In function `sybasect_sizeof_type':
    sybasect.c:311: error: `CS_USHORT_TYPE' undeclared (first use in this function)
    sybasect.c:311: error: (Each undeclared identifier is reported only once
    sybasect.c:311: error: for each function it appears in.)
    error: command 'gcc' failed with exit status 1

Noticing that there was an #ifdef CS_USHORT_TYPE later in the file I
#ifdef'd that usage as well.  The module build ran to completion after
that.  (I've yet to actually try it.)  A context diff for sybasect.c is
appended.

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://www.spambayes.org/
sk...@po...

*** /tmp/skipm/sybasect.c~      Wed Apr 21 08:57:28 2004
--- /tmp/skipm/sybasect.c       Wed Apr 21 08:57:28 2004
***************
*** 308,316 ****
--- 308,318 ----
      case CS_LONG_TYPE:
        size = sizeof(CS_LONG);
        break;
+ #ifdef CS_USHORT_TYPE
      case CS_USHORT_TYPE:
        size = sizeof(CS_USHORT);
        break;
+ #endif
  #ifdef CS_CLIENTMSG_TYPE
      case CS_CLIENTMSG_TYPE:
        size = sizeof(CS_CLIENTMSG);

2002	Jan	Feb	Mar (3)	Apr (26)	May (7)	Jun	Jul (12)	Aug	Sep (13)	Oct (6)	Nov (14)	Dec (14)
2003	Jan (31)	Feb (15)	Mar (6)	Apr (18)	May (11)	Jun (3)	Jul (7)	Aug (5)	Sep (6)	Oct (1)	Nov (2)	Dec (6)
2004	Jan (3)	Feb (3)	Mar (18)	Apr (4)	May (13)	Jun (32)	Jul (21)	Aug (22)	Sep (11)	Oct (2)	Nov (6)	Dec (5)
2005	Jan (4)	Feb (16)	Mar (21)	Apr (10)	May (1)	Jun (5)	Jul (3)	Aug (3)	Sep (13)	Oct (15)	Nov (20)	Dec
2006	Jan (3)	Feb (1)	Mar (3)	Apr (5)	May (4)	Jun (6)	Jul (23)	Aug (6)	Sep (5)	Oct (8)	Nov	Dec (12)
2007	Jan (2)	Feb (5)	Mar	Apr	May (9)	Jun (1)	Jul (6)	Aug (5)	Sep (3)	Oct	Nov (5)	Dec (6)
2008	Jan (1)	Feb (1)	Mar	Apr (3)	May	Jun (12)	Jul	Aug (1)	Sep	Oct (7)	Nov (1)	Dec (4)
2009	Jan	Feb (2)	Mar (16)	Apr	May	Jun	Jul (5)	Aug (21)	Sep (11)	Oct (4)	Nov	Dec
2010	Jan	Feb	Mar (1)	Apr (1)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec (3)
2011	Jan (9)	Feb (5)	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov	Dec (1)
2012	Jan (2)	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun (4)	Jul	Aug	Sep	Oct (5)	Nov (1)	Dec
2014	Jan	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec
2019	Jan	Feb	Mar	Apr	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec