datDecimal

Delphi 2007, Delphi XE2 update 2. RODA 6.0.53.935 on both. Relativity Server. Firebird 2.5. FB.NET connection in Relativity.

I am trying to move an app from 2007 to XE2. In my table, I have defined several Decimal fields as Decimal(7,4).

Under 2007, the data from these fields displays as expected. (7.45, 2.25, etc.)

When I recompile the app under XE2, 32 bit they display as as .E1 or .E0.

If I edit the field and set it DecimalPrecision and DecimalScale to the appropriate numbers and set the table active in design time, the fields display as expected. However, in runtime, I get the .E1 or .E0.

Under Schema modler, I attempted to set the Decimal Scale and Decimal Precision data, but it will not save or retain the settings.

Obviously something is different between 2007 and XE2 concerning Decimal fields.

Any ideas appreciated.

Mike

I have installed the latest RODA Gamma and still have the same results.

Attached are two png files. One show what it looks like at design time, the other at runtime.

I can access the fields in code and get the proper values, but hooking up to the DBGrid gives me the bad results.

Mike

ANybody from RO want to comment?

Hello Mike,

Sorry for belated answer.

There was such probem, but it was fixed in the last Winter 2011 version. It will be available in a day or two.

Best regards.

I downloaded and installed the Winter 2011 version.

I get the same results. Ok in design time, but the “.E1, .E0…” errors at run time.

Works as expected under D2007.

Mike

Hello Mike,

My appologies, some confusion has occured.
The issues was logged as #52071 and #52072. We will inform you when they will be fixed.

Best regards.

in XE2 they were changed BcdToStrF that is called from TFMTBCDField.GetText. As a result, BcdToStrF produces “E#” values…
function BcdToStrF(const Bcd: TBcd; Format: TFloatFormat;
const Precision, Digits: Integer; FS: TFormatSettings): string;
var
LBcd: TBcd;
DecPos: Integer;
begin
LBcd := Bcd;
Result := BcdToStr(LBcd, FS); //<<<< there is correct Result
RoundPrecision(Result, FS.DecimalSeparator, Precision);

DecPos := Pos(FS.DecimalSeparator, Result);
case Format of
ffGeneral: if ((DecPos = 0) and (Length(Result) > Precision)) or (DecPos - 1 > Precision) then
BcdExponentString(Result, Format, FS.DecimalSeparator, Precision, Digits); // Fallback if to big
ffExponent: BcdExponentString(Result, Format, FS.DecimalSeparator, Precision, Digits);
ffFixed,
ffNumber,
ffCurrency: BcdNumberString(Result, Format, Precision, Digits, FS);
end;
end;

Thanks.

Let me know when you have the fix as I have a major project waiting for it.

Mike

pls drop email to support@ in which specify your login for my.remobjects.com.
We’ll include link in your downloads to new Relativity in which problem with DecimalPrecision/DecimalScale was fixed.

Thanks.

Sent.

Mike

Same problems with the new Relativity server you provided. Still unusable.

Mike

Did you do these steps
a) specify DecimalScale & DecimalPrecision in schema inside Relativity
b) refetch schema on client?

I did all the above.

On refetch schema on the client, I verified that DecimalScale and DecimalPrecision were set on the client.

I still have the “E0, E1…” displayed.

Again, this is only with XE2. It has always worked fine on D2007.

Mike

hmm, I can’t reproduce original problem with “Relativity - 6.0.54.962-VULCAN-stable 20111209-073543” which was put to your downloads.

I’ve updated DecimalScale&DecimalPrecision for Price and Total fields in OrderDetails table (Relativity|PCTrade Sample domain->PCTrade schema).
After this I’ve created XE2 client from scratch for OrderDetails table

Could you reproduce original problem with this table if you repeated my steps?

I finally got it to work.

I was using a TableRequestInfoV6 and had IncludeSchema set to true. I set it to false and it works.

Is this a mistake on my part (setting it true) or is it a bug? In D2007, it works with it set to true.

Mike

Thanks.
it is a bug in Relativity. logged as #52365.
as a workaround, you can use IncludeSchema set to false

Has bug 52365 been fixed in the Dec 23 beta?

Thanks,

Mike

6.0.56.967 contains the fix for #52365

The new beta appears to fix the problems discussed in this thread.

I believe you can close this thread.

Thanks, Mike