We also noticed some wierd things with TIMESTAMP too, but have been
unable to
track it down. I don't know the inner workings, but taking a stab at
it, it looks like
it isn't converting the number properly from the 64bit Integer that it
gets restored to
internally back to a decimal for the client. The decimal place is off
by 6. The scale is 6.
Maybe it means something, maybe it doesn't.
Paul Reeves wrote:
> Thomas Miller wrote:
>
>> 1) When will the next snap shot be available?
>>
>> 2) We use NUMERIC(18,6) for all of our currency values. We use
>> Crystal.
>>
>> Problem.
>>
>> Actual Display
>> 100.01 100.01
>> 57.34 57,340,000
>> When ever the first decimal place does not hold a "0" zero, it
>> doesn't divide the value by the decimal places.
>>
>
> I've been looking at this issue (tangentially) and it looks to me that
> something is screwy somewhere, but I just can't nail it down. At the
> time (yesterday) I was trying to get the driver to work with Access
> and it looks as if NUMERIC and DECIMAL are converted to CHAR before
> being returned to the client app. In my Access test this seemed to
> cause problems because the CHAR size wasn't big enough to take large
> numbers.
>
> It also seems that TIMESTAMPS aren't always treated nicely, but that
> is another issue altogether.
>
> Next snapshot? Good question. I'd like to make some headway with the
> above issues first, but if I can't then I guess I'll wrap up what we have.
>
>
> Paul
--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
|
