KInterbasDB

Logged In: YES
user_id=414645

In CVS rev 1.27 of _kinterbasdb.c, the bugfix handles the
extended cases mentioned below (table, view, stored
procedure, dynamically computed field).

Logged In: YES
user_id=414645

This is somewhat more complex than I originally thought.

In addition to ordinary table fields, which present no
problem, special cases must exist to handle dynamically
computed fields (e.g., SELECT x/2 FROM TBL), stored
procedure output parameters, and view "fields" (with
differences depending on what sort of query underlies the view).

It won't be realistically possible to determine field
precision in every one of these cases, but I'll handle those
which I reasonably can.

In the meantime, beware that CVS revisions 1.25 and 1.26 of
_kinterbasdb.c are incomplete and will not function properly.

Logged In: YES
user_id=414645

Fixed in CVS revision 1.25 of _kinterbasdb.c

Logged In: YES
user_id=414645

"not only precision, but also length of decimal and numeric
fields is not returned as it should."

I think we're referring to the same thing using different
words ("precision"/"length"). NUMERIC fields are
defined
with the syntax

NUMERIC[(precision [, scale])]

, which makes the "length" of a NUMERIC the same as its
"precision" (see the IB 6 Data Definition Guide page 64).
(Of course all of this also applies to DECIMAL fields.)

---------------------------------

Unlike the "precision" of a fixed decimal field, the
"scale"
*is* provided by the current implementation of kinterbasdb.
The scale returned in the cursor.description by kinterbasdb
is typically a negative value, though (e.g., in the case of
NUMERIC(10, 2)). kinterbasdb's scale values follow
Interbase conventions, and the Python DB API spec doesn't
make it clear whether the scale should be positive or
negative in a case such as the example above. This will
requires some investigation.

---------------------------------

The fix for bug #549982 (this bug) is no mystery; I've just
been dallying while I tried to find a faster solution than
running a separate query against the system tables for
*every output column of every ordinary query*.

Of course, I can settle for the slow solution at first and
then replace it with a faster implementation if one is
discovered. So I'll commit a fix for this bug to CVS in the
next few days.

Logged In: YES
user_id=537867

not only precision, but also length of decimal and numeric fields is not
returned as it should. so one has to query rdb$fields in order to get
right
values.

Logged In: YES
user_id=537867

not only precision, but also length of decimal and numeric fields is not
returned as it should. so one has to query rdb$fields in order to get
right
values.