[fdo-users] Wrong datatype mapping for oracle number(xx,0)

Orest Halustchak orest.halustchak at autodesk.com
Tue Dec 11 08:21:04 EST 2007

Hi Bruno,

FDO maps number(18,0) to fdo decimal(18,0). This constrains the result to be an 18 digit number. Mapping to int64 will cause problems since there are int64 values that will not fit into number(18,0). You would end up with insert or update errors with valid int64 values.

In C++, fdo decimal is represented using C++ doubles since there is no C++ decimal type.

The examples used in the trac is number(38,0), which also doesn't support all int64 values. There is a related issue that double doesn't have enough accuracy to support 38 digits.

There are some other alternatives that could be considered.

(i) Map number(n,0) to the int type that supports at least 'n' digits and include a range constraint on the property to restrict the value to +/- n digit numbers.

(ii) Instead of handling fdo decimal in C++ as double, define a Decimal class that will hold all necessary digits and implement custom handling of arithmetic operations within that class.

Note also that a config file could be used with MapGuide to override mapping of columns to other fdo types.


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Bruno Scott
Sent: Tuesday, December 11, 2007 2:42 AM
To: fdo-users at lists.osgeo.org
Subject: [fdo-users] Wrong datatype mapping for oracle number(xx,0)

As referring to Mapguide RFC43

They are fixing something that seems to me a FDO bug.
I think FDO should fix it.

FDO Should map NUMBER(18,0) to int64.

thread in the mapguide forum:

View this message in context: http://www.nabble.com/Wrong-datatype-mapping-for-oracle-number%28xx%2C0%29-tp14269200s18162p14269200.html
Sent from the fdo-users mailing list archive at Nabble.com.

fdo-users mailing list
fdo-users at lists.osgeo.org

More information about the fdo-users mailing list