Which type will hold better a TBCDField value?

[Juan C.Cilleruelo 12]

#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?

[Uwe Raabe 2057]

What about TBcd?

[Juan C.Cilleruelo 12]

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.

[Fritzew 51]

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

 

[Juan C.Cilleruelo 12]

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. 

[Fritzew 51]

http://docwiki.embarcadero.com/Libraries/Tokyo/en/Data.DB.TBCDField

[Juan C.Cilleruelo 12]

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. 

[Attila Kovacs 629]

http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Data_Type_Mapping_(FireDAC)

[Juan C.Cilleruelo 12]

Attila: This is not the problem. The database is well defined. Read the previous entries, please.

[Attila Kovacs 629]

I'm sorry Juan, I'm always trying to help you but you always chose the hard way.

[Juan C.Cilleruelo 12]

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?

 

 

[Attila Kovacs 629]

:DDDD okay

[Lars Fosdal 1791]

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

[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

[Fritzew 51]

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.......

[Juan C.Cilleruelo 12]

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.

 

 

 

[Juan C.Cilleruelo 12]

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
 

 

 

 

[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.