kinterbas db column type

[Uwe Grauer]

Hi,

i need to know the database column types returned by kinterbasdb.
Implicit type conversion is i nice thing to have, but it hides the real
types in the database.
So how could i get this information?

Thanks,
Uwe

 

[Gandalf]

i need to know the database column types returned by kinterbasdb.

Implicit type conversion is i nice thing to have, but it hides the
real types in the database.
So how could i get this information?

If you use InterBase only, you can get that information from the
metadatabase.
Try this:

RDB$RELATIONS - this stores table information
RDB$FIELDS - this is for the fields (here you have the RDB$FIELD_TYPE field)
RDB$RELATION_FIELDS - connects relations to fields

you can figure out the others. (Oh, it is for InterBase 6.0 but the
others are similar or the same)

Cheers,

L 1.0

 

[Uwe Grauer]

If you use InterBase only, you can get that information from the
metadatabase.
Try this:

RDB$RELATIONS - this stores table information
RDB$FIELDS - this is for the fields (here you have the RDB$FIELD_TYPE
field)
RDB$RELATION_FIELDS - connects relations to fields

you can figure out the others. (Oh, it is for InterBase 6.0 but the
others are similar or the same)

Cheers,

L 1.0

Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?

 

[Gandalf]

Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?

It is DB-API 2.0 compilant. I'm sorry, maybe I misunderstood you. This
is a way
to get the column types in InterBase inside. Do you want to know the
Python types
in the row returned by .fetch()?

 

[Uwe Grauer]

It is DB-API 2.0 compilant. I'm sorry, maybe I misunderstood you. This
is a way
to get the column types in InterBase inside. Do you want to know the
Python types
in the row returned by .fetch()?

Sorry Gandalf,

more explanation:

It's different from other modules cause it does a implicit type
conversion to the Python-types.
So for a DATETIME-column in mysql you get a type_code 12 (which is
indeed DATETIME in MySQLdb) but in kinterbasdb you get t_tuple. This
does not help me very much since the information i need is different
from what i get.

Uwe

 

[Gandalf]

Sorry Gandalf,

more explanation:

It's different from other modules cause it does a implicit type
conversion to the Python-types.
So for a DATETIME-column in mysql you get a type_code 12 (which is
indeed DATETIME in MySQLdb) but in kinterbasdb you get t_tuple. This
does not help me very much since the information i need is different
from what i get.

Okay, I created this table (InterBase 6.01):

create table PV_TEST
(
ID integer not null,
PT_TEST_ID integer not null,
INTVALUE integer,
BOOLVALUE integer,
FLOATVALUE double precision,
DATETIMEVALUE timestamp,
DATEVALUE timestamp,
TIMEVALUE timestamp,
TEXTVALUE blob sub_type text segment size 80,
PERSISTENTVALUE blob segment size 80
)

This is what I got from a cursor's description:

(('ID', <type 'int'>, 12, 4, 0, 0, False), ('PT_TEST_ID', <type 'int'>,
12, 4, 0, 0, False), ('INTVALUE', <type 'int'>, 12, 4, 0, 0, True),
('BOOLVALUE', <type 'int'>, 12, 4, 0, 0, True), ('FLOATVALUE', <type
'float'>, 17, 8, 0, 0, True), ('DATETIMEVALUE', <type 'tuple'>, 22, 8,
0, 0, True), ('DATEVALUE', <type 'tuple'>, 22, 8, 0, 0, True),
('TIMEVALUE', <type 'tuple'>, 22, 8, 0, 0, True), ('TEXTVALUE', <type
'str'>, 0, 8, 0, 1, True), ('PERSISTENTVALUE', <type 'str'>, 0, 8, 0, 0,
True))

The tuple type is really a tuple. Try this:

import time
time.gmtime()

This will give you a tuple. Well, you can ask for a separate DATE and
TIME type.
Well, in dialect 1, only TIMESTAMP supported.

Cheers,

L

 

[Uwe Grauer]

more explanation:

It's different from other modules cause it does a implicit type
conversion to the Python-types.
So for a DATETIME-column in mysql you get a type_code 12 (which is
indeed DATETIME in MySQLdb) but in kinterbasdb you get t_tuple. This
does not help me very much since the information i need is different
from what i get.

Uwe

Got the answer in db-sig, thought i should share it:

David Rushby wrote:

This is a known problem in 3.1_pre6 and earlier. It's fixed in the CVS
version, which I plan to release soon as 3.1_pre7. Here's the relevant
SF bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=814276&group_id=9913&atid=109913

If you're not compiler- or CVS- constrained, use the CVS version right
now; it's quite stable.