Hello!
For sql replication I use first dbtool to fix sql widths (hopefully PSC will create a auto fix width option) and then run a simple EXPORT on every changed record/table.
This is the definition of one field: SQL schema:
(Pro SQL) decimal(19,4) DEFAULT 0 null
ABL schema: Decimal, deci-4 / ->>>,>>>,>>>,>>9.9999
The result of the export is: 25811,19999, It should be 25811,2000
Why there is one digit too much in the database?
EXPORT ignores format, as documented. The data that is exported is the data that as is in the database, so the data made into the database. Were the definitions changed at some point?
That sounds like the likely issue Fernando.
Stefan: What does it look like in the ABL/4GL when you override the format to show more decimal places?
Like ->>>,>>>,>>>,>>9.99999999
Why it's possible to store more than 4 decimals as defined for the field?
The question is: Shouldn't it be rounded by the database?
"Were the definitions changed at some point": I don't know I got the DB "as is".
This is because it's not the field format but the 'Default Display' format.
There is no option to define the field format in the OpenEdge Database for the ABL.
Note that there is a Decimals property of the field. What does that say. That controls the storage.
The reason I asked if the schema changed at some point is that the data that is already in the db will not be changed if you change the 'decimals' value of a field. The next time you update that field, then we will round it. While the data is in the db, it will not be changed. So you could write ABL code that updates the field and it will get rounded based on the current field definitions.
I had the same idea and asked the developer, reply: No, only the display format changed a few years ago.,
Do I really need the historical schema knowledge of the database to be sure having other data (decimals) in fields as expected?
Why this isn't updated by the database itself? Or during running dbtool which fixes length errors?
I opened a case at PSC to discuss these questions.
Do the abbreviations in your initial post mean that the Decimals property of the field is set to 4? If it is set to a higher value, that is the complete explanation. If it is set to 4, but previously was set to something more, that would also explain it. No, it isn't that you should need to know the schema history, but it means that when it was changed, actions should have been taken to update the data so that one wouldn't get these surprises later.
Yes. it's set to 4, development told me that there is no known change. (only the display format)
1.) it's a bug, rounding problem (,19999 instead of ,2)
2.) it was changed and nobody knows
I would like that dbtool would report/fix "problems" like this
What was the change in the display format? Did it involve showing a different number of decimals?
I have the df only, I don't know how it was before.
UPDATE FIELD "xx OF "xx"
FORMAT "->>>,>>>,>>>,>>9.9999"
The reason for asking is that one would tend to expect that a change in format to the right of the decimal point would be associated with a change in Decimals. There are exceptions, e.g., keeping data to four digits but displaying two by default. But, in general ...