471,310 Members | 1,108 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

kinterbas db column type

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

Jul 18 '05 #1
6 1689
> 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

Jul 18 '05 #2
Gandalf wrote:
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

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

Jul 18 '05 #3
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_FIELDS - connects relations to fields

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()?
Jul 18 '05 #4
Gandalf wrote:
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_FIELDS - connects relations to fields

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()?

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

Jul 18 '05 #5
>
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()?

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


Jul 18 '05 #6
Uwe Grauer wrote:

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...13&atid=109913

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

Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Peter Foti | last post: by
1 post views Thread by aspnetpal | last post: by
6 posts views Thread by Robert Schuldenfrei | last post: by
3 posts views Thread by Bob Day | last post: by
6 posts views Thread by Balin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.