Jump to content
Juan C.Cilleruelo

Which type will hold better a TBCDField value?

Recommended Posts

#Delphi, #FMX, #FireDAC. 

 

I have a DB Field defined as DECIMAL(15, 3);

 

This produce permanent fields on my program of the type TBCDField.

 

All of this is correct. Sometimes I need to Assign the value of one of this fields to a local or class variable.

 

Which type do you recommend for this variable to assure I do not go to lost precision and the value is going to be near to an unaltered form?

Share this post


Link to post

TBcd is a complex data type. I think I can't make mathematical operations directly with two TBCD types

I'm thinking in Currency type. But this implies convert every TBCDField value to Currency and vice-versa to assign the value from database to my variables and returning the values to the database. 

It's complex. I think. 

 

Anyone knows a good solution?

 

Thanks in advance.

Share this post


Link to post

From the Docs:
 

Quote

TBCDField uses the currency (Delphi) or System::Currency (C++) type to manipulate BCD values. 
This is faster than storing and manipulating the value using a true BCD type, 
but limits the precision of the BCD values it can support to 4 decimal places and 20 significant digits. 

TBCDField converts the data from a BCD value to a currency value when it fetches the data from the database table, 
and converts it from a currency value to a binary-coded decimal value when it posts the data. 
If the underlying database table contains a value that requires greater precision, 
TBCDField raises an exception.

So I think Currency will the correct type to choose

 

  • Like 1

Share this post


Link to post

Where is this info?: 

TBCDField converts the data from a BCD value to a currency value when it fetches the data from the database table, 
and converts it from a currency value to a binary-coded decimal value when it posts the data. 

Share this post


Link to post

I understand that if instead use MyField.AsBCD, I use MyField.AsCurrency, I don't loss precision, because is his internal representation. 

 

Do you think?

 

I'm going to do some proves. 

Share this post


Link to post

Read the thread, please!   Your response is not related to the theme!  It's only the first thing you found in a google search. 

 

What kind of help is this?

 

What solves?

 

 

Share this post


Link to post

Currency can hold Decimal(50,4) if I remember correctly. Extended could have worked, but strangely it's not available on 64-bit.

Share this post


Link to post
Guest

I must say, at the beginning (20, 25 years ago) I fretted a lot about this. Then I had the pressure to driver so I ditched BCD. It has happened that a client became frustrated because a huge list had one unit of currency wrong. But seriously if you are for two extra precision, problem well be rare.

 

I know, this is a non-orthodix sentiment, but IMHO fretting about this is "premature optimization". Of course it's business treated, if you are into measurements, take care. If it's about money, do not fret.

 

HtH,

 

/d

Share this post


Link to post

If you are using TBCDField you can simply use Currency, because these Fieldtype is designed to work with currency as the internal DataType.
Look in the Source from Data.DB.......

  • Thanks 1

Share this post


Link to post
16 hours ago, Fritzew said:

If you are using TBCDField you can simply use Currency, because these Fieldtype is designed to work with currency as the internal DataType.
Look in the Source from Data.DB.......

 

Thank you all!  Working again!  

 

The final solution was finally, use Currency.  I can take this TFields AsCurrency and this works well.

 

The problem comes from a modify in all the program.

 

I had all the measures for the furniture in millimetres. This is a good thing for woodworking, but I have now a new customer that need my program for modelling complex things for 3D printing and he needs until hundredths of millimetres (two decimals).

Solved.

 

 

 

Capture OK again.PNG

  • Like 1

Share this post


Link to post
16 hours ago, Dany Marmur said:

I must say, at the beginning (20, 25 years ago) I fretted a lot about this. Then I had the pressure to driver so I ditched BCD. It has happened that a client became frustrated because a huge list had one unit of currency wrong. But seriously if you are for two extra precision, problem well be rare.

 

I know, this is a non-orthodix sentiment, but IMHO fretting about this is "premature optimization". Of course it's business treated, if you are into measurements, take care. If it's about money, do not fret.

 

HtH,

 

/d

 

In this case, if for measurements but is the same type of data I use for all economic values.

 

I read an EU document in which he explains how to treat with decimal values in operations with Euro.

 

It's easy: You always should take three decimals for all operations and finally show a "round half up" function to two decimals when you show or print the results. 

 

I can't remember where is this document, but if you need it you can search on the web. 


reference for "Round Half Up": https://en.wikipedia.org/wiki/Rounding#Types_of_rounding
 

 

 

 

Share this post


Link to post
Guest
47 minutes ago, Juan C.Cilleruelo said:

 

In this case, if for measurements but is the same type of data I use for all economic values.

 

I read an EU document in which he explains how to treat with decimal values in operations with Euro.

 

It's easy: You always should take three decimals for all operations and finally show a "round half up" function to two decimals when you show or print the results. 

 

I can't remember where is this document, but if you need it you can search on the web. 


reference for "Round Half Up": https://en.wikipedia.org/wiki/Rounding#Types_of_rounding
 

 

 

 

That is what I was trying to express from a phone and lacking the nomenclature. Yes.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×