String representations of Decimals

I have a bit of trouble with Dataphor and the peculiar Norwegian habit of using comma as the decimal symbol.

For one thing, a query with "where SomeDecimalColumn = 6.5" gets translated by OracleDevice to "where (T1.SomeDecimalColumn = 6,5), which is a syntax error. I have to work around it by writing "where SomeDecimalColumn = 65 / 10" instead.

A worse problem is something I dumped into recently. On my production server, the following script gives the results in the comments:

select 6.5; // 6,5
select ToString(6.5); // 6,5
select ToDecimal("6,5"); // 6,5
select ToDecimal("6.5"); // Error

This is consistent. But on my test server, which runs the same version of the Dataphor server, and has the same Regional and Language Options set (but runs Windows Server 2003 Enterprise instead of Standard) I get this:

select 6.5; // 6,5
select ToString(6.5); // 6.5 [sic]
select ToDecimal("6,5"); // 65 [sic]
select ToDecimal("6.5"); // 6,5

Two questions: What is it that determines what decimal symbol ToString() uses and ToDecimal() expects, other than Windows' Regional and Language Options? (Both result sets were obtained by running Dataphoria from a third computer, also with the same Norwegian regional options.) And the second results seem buggy no matter what setting you have...

Secondly, isn't it a better idea for ToString() and ToDecimal() to use a canonical format, i.e. independent of locale? That's what I'm used to from other programming languages. Formatting for display according to the user's preferences is normally done by some other mechanism (a Format() operator, for instance) -- and in any case, ToString() ignores other regional number formatting options, such as digit grouping.

Decimal Conversions

Hi Jon,

Apologies for the late reply. What version of Dataphor are you running? In the latest code-base, the decimal ToString() operator uses an explicit formatting string containing a period, so it should convert to the D4-accepted literal representation. The ToDecimal, however, is still using the .NET framework default conversion, which accepts strings using the culture-specific settings on the machine that is running the code.

I agree the string conversion operators should use a canonical format that is culture-independent, and steps have been taken in that direction in the latest code-base, but it is still not 100%. I am surprised that the version of the operating system affects the formatting, but that is a pass-through effect from the underlying .NET implementation. I have added a defect to correct this issue.

Bryn Rhodes
Database Consulting Group LLC

Decimal Conversions

Sorry, I'm still running 2.1.2711. Is the 3.0 release I see available, stable? It was released rather stealthily -- it's linked from the 2.1 section, and 3.0 is still spoken of in future tense on the front page of dataphor.org. :)

I guess it's different versions of .NET that causes the different behaviours, not the OS version. I didn't check that. Anyway, does the latest code-base fix the trouble with regard to Oracle?

Dataphor 3.0

Hi Jon,

Yes, Dataphor 3.0 is stable and in production, but we need to package the latest bits and make them available. Regarding Oracle, we have made some fixes, but I'm not sure that all your issues would be addressed.

Regards,
Bryn Rhodes
Database Consulting Group LLC

What do you mean by "package

What do you mean by "package the latest bits and make them available"? Is Dataphor 3.0 supposed to be usable?

I downloaded and installed it on my 64-bit Windows 7 system, but it seems to suffer from multiple issues -- some annoying, some critical:

1. Dataphoria needs to be run as administrator, or you get UnauthorizedAccessException ---> Access to the path is denied.

2. You need to stop the Dataphor service before connecting In Process, or you get IOException ---> The process cannot access the file because it is being used by another process.

3. Having stopped the service and run Dataphoria as administrator, you have to edit the In Process Instance Configuration to use C:\Program Files (x86)\Dataphor\Libraries instead of C:\Program Files (x86)\Libraries, or you get Application:113104 ---> Object "Frontend" not found.

4. I can't get DAE Config Utility to work at all. Running it normally gives the error message "Requested registry access is not allowed" the first time, and subsequent attempts fail silently. Running it as administrator just fails silently.

I haven't tested the client yet; I hope it doesn't require even more administrator privileges than it does in 2.1. I am very keen to have a Dataphor version that works on my 64-bit production servers (have you begun testing Dataphor on 64-bit systems now?), so I hope these issues can be prioritised. :)

I am also unable to repro

I am also unable to repro item 4. I run Dataphoria every day and the DAE Config Utility frequently, both on Windows 7.

Also, to answer the 64 bit question, there is a production 3.0 instance running 64 bit, with mostly 32 bit clients, but some 64 bit clients.

I'll try to repro items 2 and 3 tomorrow.

I started looking into these

I started looking into these and couldn't repro item 1. As far as I can tell, it's fixed in the latest 3.0 version.