Here is something for you all to try at home. Use an unmodified CRONUS database and pick any table, for the purposes of this we will use 287 Customer Bank Account. Run the table and count the size of the text in the field ‘Bank Account No.’ The answer is 9 by the way for all rows. Now design the table and change the size of the field to Text 8, and save the table. Are alarms bells ringing![:0] Run the table. There is your Text 9 data happy in its Text 8 column definition. [:0] You cannot add 9 characters to the field, nor cut and paste existing data. [:(!] Now call me old-fashioned, but is this acceptable behaviour in a database? I have checked this with fields of type code and back to version 2.5 I suspect I know why it is happening, but shouldn’t this bug get fixed ASAP? [:(!] Anybody else come across this?? Regards David
[:D] Actually it’s very unsafe to descrease field length as you can lose information. But if you need it you should delete all data from table or PADSTR for this field. Nice bug but as far as I know nobody decreases field length for table with data [;)]
The reason is that Navision aligns buffers for its fields to 4-bytes. Which means that there is physically enough room for more data than your user-defined length should allow. But database checks for values exceeding the allowable length are normally against the internal length - not your defined length. Only the UI is respecting the defined length. A Code field of length 8 and 9 are both using 12 bytes. That is: 1 byte for field length indicator (prefix) 1 byte for value zero terminator Either 8 or 9 bytes for the maximum value = 10 or 11. This is 4-byte rounded up to 12. Internal checks, for example when redesigning the table, will be against data fitting into 12 bytes which they both do, so no error is raised. The reason for using the internal size and not the defined length for checking is that the internal size is always available a record layout, but the defined length must be accessed indirectly in the table description, thereby giving a performance hit. I agree with you that this is wrong though, and can lead to problems, especially where C/FRONT is pumping data into fields and will not receive errors - but the full data from Navision will effectivley be unavailable. It has been this way a long time, although in various versions the user-defined check has been done instead to the internal check in certain areas.
Thank you, Robert, for such a rational and calming answer. We don’t like to know there are errors in our product, but when they are found we like to be able to deal with them logically and not be fearing the unknown. You’ve done us all a service on this one.
As long as you stick to the C/Side database everything is ok. Restoring this kind of data in SQL however will fail. Another nice one: Create a dataport and try to import the value ´2´ in a boolean field. The dataport will import this value without any message but your database will be corrupt.