Bin2_WriteVariantToStream with currency overflow

Data Abstract
1

I’ve had a user enter a massive number into something (the number is -922337203685478.00), which is saved in a DBISAM DB as currency. I notice that this is just slightly bigger than the largest EMB docs show as the max which I guess is causing this.

When DA opens it, it causes a problem converting it and I wonder what the right way to handle this is, or if there’s something that can be done to accept such a large number (it the DB accepts it, shouldn’t DA?).

I can open the dataset in SM and see it but when I try to open it in code (using BINAdapter.WriteDataset), Bin2_WriteVariantToStream then gets an overflow error when it tries Bin2_WriteCurrencyToStream.

Error is “Overflow while converting variant of type (Double) into type (Currency)” doing the check in VarToCurrencyViaOS

I have noticed that although it is defined as currency in the DB and in SM, it actually tries to convert it from a double.

In Bin2_WriteVariantToStream is is datCurrency, but then it goes to _VarToCurrency (in system.variants) and its type is double, not currency.

Thanks
I’m using Delphi 11 and DA 10.0.0.1577

2

Hi,

this value isn’t in currency interval
from https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.Currency :

so it has to raise overflow error.

try to declare this field as Decimal

3

I see that, I just thought it was odd that the DB allows it to be saved. I think I just need to limit the entry point so people can’t enter such values.

Thanks

4

This reminds me of an issue I had the other day. I had a Postgres table with a field for country flags, length set to 10. seemed reasonable. I out all the flags in, no issue. but when in loaded the table into DA, it blew in my face, claiming a value was too long for the field.

Took me forever to find out what the issue was.

Turns out that, unlike virtually all other flags, the English one (:england:) is not made of two unicode code points (4 UTF-16 chars in length) but several more (ending up with 14 UTC-16 chars in total – hence exceeding the length set in the schema… and the table?) But apparently Postgres counts the field length differently than DA (and .NETs data tables) did, having no issue holding the English flag in a field limited to 10 chars… Maybe they are counting UTF-32, who knows…

This might be a similar issue, where thebDB has a slightly different opinion of whats a valid range for a particular value than DA and/or the platform (Delphi in your case, I assume)