I am working with a legacy app using DBISam, which uses floating points as PrimaryKeys.
This leads to rounding errors as DBISAM stores floats internally as doubles I believe. My
main problem is that I have an existing Database Model using NHibernate (.NET) which I
need to convert to using floats. NHibernate seems to work OK with DBIsam over odbc, with
ints & normal-looking database structure.

I have looked for a solution high & low one avenue I am thinking of is modifying the
database engine to store floats internally as floats, or truncate to floats (so as not to
muck with the table format).

THis is a bit pie-in-the-sky but I am kind of running out of options, bar dumping
nhibernate & my nice ORm Model. Hibernate and/or ADO.NET is being fairly trick in this
regard. I must admit the setup is fairly exotic.

Can you give any advice on the viability of this approach? I am only approaching it as a
last-resort. (that and regenerating the database on the fly to ints & convincing my boss
to convert the legacy app to ints, not likely)

Nick

Nick Hemsley <nick@phonecontrol.com.au> wrote in
news:955DC5EE-7702-40AB-93B0-A3BF730AD2B4@news.elevatesoft.com:

> I am working with a legacy app using DBISam, which uses floating
> points as PrimaryKeys. This leads to rounding errors as DBISAM stores
> floats internally as doubles I believe. My main problem is that I have
> an existing Database Model using NHibernate (.NET) which I need to
> convert to using floats. NHibernate seems to work OK with DBIsam over
> odbc, with ints & normal-looking database structure.
>
> I have looked for a solution high & low one avenue I am thinking of is
> modifying the database engine to store floats internally as floats, or
> truncate to floats (so as not to muck with the table format).
>

I converted all my Paradox MONEY fields to DBISAM DECIMAL(0,4) and that
avoided any rounding problems while maintaining Delphi float compatibility.
But I've never had to deal with floating-point indexes, let alone Primary
Keys. Good luck!

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Nick,

<< I am working with a legacy app using DBISam, which uses floating points
as PrimaryKeys. This leads to rounding errors as DBISAM stores floats
internally as doubles I believe. My main problem is that I have an existing
Database Model using NHibernate (.NET) which I need to convert to using
floats. NHibernate seems to work OK with DBIsam over odbc, with ints &
normal-looking database structure. >>

Let me just confirm this - are you saying that the application uses
floating-point values with non-integers in them and the numbers are not
being truncated or rounded to a known scale ?  If so, then I would first
suggest that you hunt down the original developer and slap him/her.  As
for solving the problem, it really is unsolvable without a lot of rounding,
truncation, etc. in your application to account for the floating-point scale
issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

I think the offender has long since left the building...

We do have a working solution that works for our legacy app:

select * from table where (cast id as varchar(30))='23432.234234)

this performs the necessary truncation. I am however having problems getting
nhibernate/ADO.net to handle this highly non-standard situation.

I think I will just have to keep bashing away until I find an appropriate solution on the
nhibernate side.

Nick



<< I am working with a legacy app using DBISam, which uses floating points
as PrimaryKeys. This leads to rounding errors as DBISAM stores floats
internally as doubles I believe. My main problem is that I have an existing
Database Model using NHibernate (.NET) which I need to convert to using
floats. NHibernate seems to work OK with DBIsam over odbc, with ints &
normal-looking database structure. >>

Let me just confirm this - are you saying that the application uses
floating-point values with non-integers in them and the numbers are not
being truncated or rounded to a known scale ?  If so, then I would first
suggest that you hunt down the original developer and slap him/her.  As
for solving the problem, it really is unsolvable without a lot of rounding,
truncation, etc. in your application to account for the floating-point scale
issues.

--
Tim Young
Elevate Software
www.elevatesoft.com