Menu
▾
▴
#26 using FIELD_SPEC.RDB$FIELD_PRECISION
Win32
Interbase5.5(using dialect=1)
3.0 was working okay. I tried using 3.0.2, 3.0.1, and
3.2pre2 and they all attempted to access
FIELD_SPEC.RDB$FIELD_PRECISION which from what I can
tell is an Interbase 6.0 feature.
I don't know if you will deem this worthwhile to fix
for 3.2 or not. It depends on whether compatibility
with old Interbase servers is a priority for
kinterbasdb. I'm in the process of trying to get
Firebird installed for the next rollout in the months
ahead. I can probably survive with 3.0 until then.
arthur
Logged In: YES
user_id=414645
Thanks for reporting this, Arthur.
The IB API does not expose a field's precision by default,
yet the Python DB API requires it. kinterbasdb retrieves
the required figure from the FIELD_SPEC system table via a
query (it caches the result in a dictionary, so performance
is no problem).
To suppress this behavior, you can simply change
_kinterbasdb.h so that the symbol DETERMINE_FIELD_PRECISION
is no longer defined (I'm speaking of version 3.1-preX).
When I release 3.1_pre3, I'll try to ensure that it compiles
out of the box with Interbase 5.5 (though I don't actually
have IB 5.5 to test against, so my bug reports such as this
one will be my only hints). Specifically, I'll use
conditional compilation to suppress field precision
retrieval when compiling against IB 5.x. However, official
*binary* releases will be compiled against Firebird, meaning
that the field precision retrieval will be enabled.
P.S. *Even* if you're on Windows, compiling kinterbasdb
yourself is easy and free (see the "Compiler-Specific Notes"
section of the installation guide for source distributions).
Logged In: YES
user_id=414645
The CVS changes I committed today should fix this particular
problem (using FIELD_SPEC.RDB$FIELD_PRECISION with < IB
6.0), though I don't know whether I've run afoul of other
features lacking in IB 5.x in the process.
Logged In: YES
user_id=414645
Fixed in 3.1_pre3.