[DB-SIG] DCOracle number handling still broken?

[Christopher Petrilli]

Guenter Radestock [guenter@ubka.uni-karlsruhe.de] wrote:

> Some time last year I converted to DCOracle, version 1.2.1 and now I see
> this does not work anymore (doesn't give an error, either).  Aparantly,
> DCOracle returns every number truncated to an integer (again: this would
> work better with the old old oracledb.)  I found that where svrmgrl
> returns 1.30436094, DCOracle will return (1,) as a result to the same
> select.

Um, can you provide some insight into your schema?  We sniff at the
data types returned by Oracle, and try to do the right thing.  The
general number type format is:

	NUMBER(p,s)

where 'p' is the precision (total number of digits) and 's' is the
scale (or number of digits to the right of the decimal).  If 's' is
*not* zero, then we return a floating point, otherwise we try and get
Python int v. long right (basically if p > 9, then long).

I wonder if you just are using the Oracleism of NUMBER by itself,
which is hard to know what it will return.

> I have downloaded a newer version (DCOracle-1.3.0) some time ago but I
> am not sure if this is fixed.  Compiling DCOracle for a specific Oracle
> under AIX (4.2.1, Oracle 7.3.4) is no simple thing and I only managed to
> get a working version after throwing out shared library support and
> creating a giant python executable with all oracle libs statically
> linked.

Well, this is an Oracle issue, not a DCOracle issue.  Oracle 8/8i run
fine with shared libraries on: Linux, Solaris and HP-UX, we don't have 
an AIX box around here to test on, but I know that at some point in
the past, shared library support on AIX w/python was not correct.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org