[DB-SIG] Sybase module, DB-api description attribute

Peter Godman pgodman@halcyon.com
Tue, 14 Apr 1998 11:02:39 -0700 (PDT)

On Tue, 14 Apr 1998, Harri Pasanen wrote:

> Hi,
> What is the current status of Sybase module development?

I sent an email a few days ago stating the current status of module
development for me... not much, pending access to a Sybase database.  I'm
working on getting access, though.

> I've been testing Peter Godman's ctsybase module on SunOS 5.6 with
> Python 1.5, and my
> preliminary tests seem to have it functioning ok.
> But how is the description attribute supposed to be populated?   The
> current ctsybase module
> seems to fill it mainly with raw return values of Sybase, so the column
> description tuples look something
> like ('name', 0, 0, 255, 0, 0, 0)

Well, I tried to do what the spec said, with some amount of trepidation,
given the closing disclaimer.

        This read-only attribute is a tuple of 7-tuples. /* I did a list 
	                                                    of 7-tuples */
        Each 7-tuple contains information describing each result column:
        (name, type_code, display_size, internal_size, precision, scale, 
	null_ok). This attribute will be None for operations that do 
	not return rows or if the cursor has not had an operation invoked 
	via the execute() method yet.  The type_code is one of the dbi 
	values specified in the section below. 

        Note: this is a bit in flux. Generally, the first
        two items of the 7-tuple will always be present; the others may be
                        database specific. 

However, there is no available display length, and the data type is
returned, as you suspected, as a sybase constant.  I should add these
constants to the module.  

I will be able to do something a little more elegant when I add dbi types.  

> Has there been any talk about getting more detailed meta data out of
> databases, for instance where
> the DBI object types would be a union of all supported database types?

I think this is a good idea.  However, I think people are still going to
want to deal with native types where possible.  Furthermore, the range of
types supported by a database varies widely, making a union messy, and may
not even be known upon installation (user may install her own complex

> Thanks,
> Harri


> ------------------------------------------------------
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig