Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Emulate how a DBISAM Currency field would convert using ElevateDB decimal(19,2)
Mon, Jul 2 2012 12:55 AMPermanent Link

IQA

Hi All,

This should be simple...

After converting my program from DBISAM to ElevateDB I have a problem on
a particular set of data I write to a temp table for a report.

Basically I'm trying to emulate how posting the following 2 amounts into
a DBISAM table that uses Currency fields..

Comm: 4.685. Payment: 232.315

That shows

Comm: $4.68  Payment: $232.31

Could be done in an ElevateDB table that uses Decimal (19,2).

The abouts being calculated before posting are identical in both
programs (i.,e the Currency vars being used are showing Comm: 4.685.
Payment: 232.315)

Really I'm trying to emulate how DBISAM would take those figures and
store as a Currency.

It's not as simple as it sounds, cause looking at the 2 original figures
I would of thought they would of showed as $4.69 and $232.23 as 99% of
the DBISAM currency amounts in the original table appear to work, but
obviously there's some other stuff going on behind the scenes in DBISAM
that I'm unaware of. (or at least it seems that way).

So if I could somehow emulate the process DBISAM would apply on the
Comm: 4.685. Payment: 232.315 amounts prior to storing that should work.

Any help you could provide would be helpful.

Thanks,

Phil.
Mon, Jul 2 2012 1:33 AMPermanent Link

IQA

Actually... What I've done is changed the temp tables amounts fields to
decimal(19,4) just for the that one table and it works. So I'll leave it
at that for now, unless there's something obvious you can
Tue, Jul 3 2012 8:14 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Phil,

<< Really I'm trying to emulate how DBISAM would take those figures and
store as a Currency.

It's not as simple as it sounds, cause looking at the 2 original figures I
would of thought they would of showed as $4.69 and $232.23 as 99% of the
DBISAM currency amounts in the original table appear to work, but obviously
there's some other stuff going on behind the scenes in DBISAM that I'm
unaware of. (or at least it seems that way). >>

There's nothing special going on in DBISAM or EDB.  More than likely the
floating-point (Currency) values that you're viewing have more digits after
the decimal point.  If you store a value in a DECIMAL(19,2) column in EDB
that has more than 2 digits in the scale, then EDB will round the value to
the scale specified for the column.

How are you determining what the exact values are in the IDE/debugger after
calculating them ?

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Jul 4 2012 10:06 AMPermanent Link

Adam Brett

Orixa Systems

Phil

I transferred my DBISAM Currency amounts to DECIMAL(19,4) in EDB with big no problems at any point, so you should be fine with this.

Adam
Thu, Jul 5 2012 7:02 AMPermanent Link

IQA

Thanks Tim and Adam!

All the data in my actual database table is DECIMAL(19,2) and even using
the old DBISAM data that was Currency fields after migration is fine, I
want to keep with just 2 decimal places to keep it simple and real in
monetary terms...

For this report only I've just used a decimal (19,4) and that gets
around the problem, the actual formula the report uses is pretty
impossible to be 100% as it uses a payment and commission amount split
across several records balances, so it would be near impossible to be
100% as we can only break down the money to cents anyway.

Thanks again, this workaround will be fine for what I wanted.
Image