[DB-SIG] DCOracle number handling still broken?
Christopher Petrilli
petrilli@amber.org
Thu, 6 Apr 2000 10:50:05 -0400
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