DBFORMAT unusable !

In Poland we use a dot symbol as thousands separator and the comma symbol as decimal point separator, so the introduction of the DBFORMAT variable seemed great. If it only worked. But I must say with sorrow that it's unusable. 1. The definition in DBFORMAT (as it is said in the FM) works only in screen operations and in report printing. It does not work properly when assigning values to string variables with "using". The thousand delimiter and decimal point are as in the standard format. I think it's a fault because the same function (USING) should work in the same way regardless of the place it is used. I can see that there can be some problems with the constants in the code and conversion from characters to numerics. But if a constant is numeric then it should be written using only the fixed (standard) format. Code should not be changed if the dbformat is changed. And when converting from characters to numerics it should be assumed that the format in a string is the one defined in DBFORMAT because the string was created with the "USING". But that's not so harmfull, it can be worked around with some if'ing, case'ing or converting function. 2. A few days ago I found the worse. The construct clause and database engines don't work the same way when DBFORMAT is changed. The construct statement sees the DBFORMAT definition and the conditions that are created have the numbers (money, decimal, float) depicted with the decimal sign as defined in the DBFORMAT variable (comma). Some examples: 1 entered in the field is formated in the constructed string as "1,0" (the ",0" are added by the construct), 10 as "10,0"; 1,234 as "1,234" (all the trailing zeros are removed and if the value is a whole the ",0" is added). But the engins (SE 4.12.UE1 and OnLine 5.02.UE1/SCO) are interpreting the comma sign as a thousand's separator (they don't see the dbformat definition). So 1 ("1,0") means 10.0 (ten); "10,0" means 100.0 (a hundred); "1,234" means 1234.0 and so on. The more digits after the decimal point the greater the number for the engines. 3. It's even worse. The RDS version of 4gl working with the OnLine engine doesn't surround the numbers with the "" as in SE and this causes the syntax error in the where clause created by the construct statement. What's even more funny the ID runner does it and behaves as with the SE engine (incorrectly but without the syntax error). I can't understand why the behaviour of the construct in the debugger is diffrent while working with the SE engine and while working with the OnLine engine ? Every word of explanation (consolation) will be appreciated. Regards, Wlodek. +--------------------------------------------------------------------------+ | Wlodek Futrega, E-mail: wlodek@aquila.ichp.waw.pl | | SoftProdukt Ltd. Fax: +48 022 23-83-78 | | Warsaw, Poland. Phone: +48 022 33-27-16 | +--------------------------------------------------------------------------+