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]

Re: kinterbas db column type

> i need to know the database column types returned by kinterbasdb.[color=blue]
> 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?[/color]


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_FI ELDS - 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]

Re: kinterbas db column type

Gandalf wrote:
[color=blue][color=green]
>> 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?[/color]
>
>
>
> 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_FI ELDS - 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
>
>
>[/color]
Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?

[Gandalf]

Re: kinterbas db column type

[color=blue][color=green][color=darkred]
>>> 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?[/color]
>>
>>
>> RDB$RELATIONS - this stores table information
>> RDB$FIELDS - this is for the fields (here you have the RDB$FIELD_TYPE
>> field)
>> RDB$RELATION_FI ELDS - connects relations to fields
>>[/color]
> Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?
>[/color]
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]

Re: kinterbas db column type

Gandalf wrote:
[color=blue]
>[color=green][color=darkred]
>>>> 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?
>>>
>>>
>>>
>>> RDB$RELATIONS - this stores table information
>>> RDB$FIELDS - this is for the fields (here you have the RDB$FIELD_TYPE
>>> field)
>>> RDB$RELATION_FI ELDS - connects relations to fields
>>>[/color]
>> Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?
>>[/color]
> 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()?
>
>[/color]
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]

Re: kinterbas db column type

>[color=blue]
>[color=green][color=darkred]
>>> Does this mean, that the kinterbasdb isn't DB-API 2.0 compliant?
>>>[/color]
>> 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()?
>>
>>[/color]
> 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.[/color]

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), ('PERSISTENTVAL UE', <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]

Re: kinterbas db column type

Uwe Grauer wrote:[color=blue]
>
> 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
>[/color]

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.