NAV2016 adding custom fields "The active fields in a record cannot take up more than 8000 bytes"

rsaritzky

Hi all,

We're upgrading from NAV2009 to NAV2016. We have 2 addons (Lanham E-Ship and Chargelogic EFT) As I'm doing the merge of the custom fields, I received this error on Table 112 (Sales Invoice Line):

"The active fields in a record cannot take up more than 8000 bytes. The active fields in the Sales Invoice Header table take up 8056 bytes. You must reduce the number or the length of the active fields."

I'm a little baffled by this, because NAV2009's record size is only 4000 bytes, so all the custom fields fit within a 4K record. And, as far as I can tell, Standard NAV has only added 4 fields to this table:

710 Document Exchange Identifier Text 50
711 Document Exchange Status Option
712 Doc. Exch. Original Identifier Text 50
720 Coupled to CRM Boolean

So, if the NAV2009 record length was, say 3999 bytes even with all our custom fields, the NAV2016 record should be more than 3999 + (50+4+50+2) = 4110 (approx) - nowhere close to 8000.

Now, let me also say what I'm doing is importing the 2009 table in an FOB using the "Merge" option - this is the only way I've been able to figure out how to get the addon fields into the table (license limitation.) I can't go "the other way" because I also can't add NAV's new fields to the old table.

Because of all the BLOB fields in the table, I haven't been able to calculate a record size. SQL reports a record length of only 1640 (approx). Same if I create a page in NAV2016 that displays the virtual table "Table Information", it displays a similar number. And if I try to manually calculate the record length by assigning 2 bytes to booleans, 4 bytes to options, and 8 bytes to dates and 0 for BLOB's, I get 4146 bytes for the total record size.

Is it the "Merge" method that is causing my pain?

Thanks

Ron

JonasA

As far as I'm aware, the merge option in the developer environment is somewhat broken. I haven't seen anyone use it. So if you can, try to merge the objects in TXT format, by hand.

Also your calculation of the size of text and boolean is wrong.
Read this topic: https://msdn.microsoft.com/en-us/library/dd301350(v=nav.90).aspx
Please note that it rounds up to nearest 4 bytes when calculating the size.

Your text variables take 104 bytes each, the boolean takes 4 bytes and the option (correctly) takes 4 bytes. You end up with 216 instead of your 110.

Please note that the primary key will also take some space, but I don't really know how much.
These sites mentions the problem, but doesn't go into much detail about the problem.
https://msdn.microsoft.com/en-us/library/dd301433(v=nav.90).aspx
https://msdn.microsoft.com/en-us/library/dn479849(v=nav.90).aspx

kriki

Create 2 empty DB's with only the objects without data of both your versions.
The fields you know are not in use in the application can be shrunk to 1 char (bode Code and text fields) freeing up a lot of space.
Export the table in both DB's as text and merge them manually. Keep that version ready.
Export the table in one DB as fob and MERGE it into the other. If you saved enough space, it will be possible. After this, import the merged text file and compile the object.

JonasA

As far as I'm aware, the merge option in the developer environment is somewhat broken. I haven't seen anyone use it. So if you can, try to merge the objects in TXT format, by hand.

Also your calculation of the size of text and boolean is wrong.
Read this topic: https://msdn.microsoft.com/en-us/library/dd301350(v=nav.90).aspx
Please note that it rounds up to nearest 4 bytes when calculating the size.

Your text variables take 104 bytes each, the boolean takes 4 bytes and the option (correctly) takes 4 bytes. You end up with 216 instead of your 110.

Please note that the primary key will also take some space, but I don't really know how much.
These sites mentions the problem, but doesn't go into much detail about the problem.
https://msdn.microsoft.com/en-us/library/dd301433(v=nav.90).aspx
https://msdn.microsoft.com/en-us/library/dn479849(v=nav.90).aspx

rsaritzky

I, too, over the years, practically NEVER used the "Merge-existing" function. However, I am limited because:

(a) NAV2016 has new fields that I cannot add by importing a text file
(b) Our Developer license will not allow us to add new addon fields either.

This is a well-known issue being discussed by the developer community. We're all hopeful that a real solution will be forthcoming. But for now, all I can figure out to do is to import the old table structure via FOB into the new NAV2016 table using the "Merge" option. Then, at least I have the fields in the table. Then, I can create an object text file that has all the necessary C/AL code embedded in to the table.

Thank you also very much for the MSDN reference that explains the space taken by various NAV field datatypes. I did try to find this information, but it seems to explain why the record has doubled in size. Comparing the NAV2016 datatypes and NAV2009 (https://msdn.microsoft.com/en-us/library/dd301350(v=nav.60).aspx) explains the difference (which you also mentioned). For TEXT and CODE field types in NAV2016, the field length is:
1 byte + ((Number of characters + 1 character) * 2

In NAV2009, TEXT and CODE fields have a length of:
Maximum string length + 1 byte

I haven't done all the field length calculations, but I do know that this table has many text/code fields, so it appears to explain why the recordsize is calculated to be 8000-ish.

Thanks very much for the MSDN reference.

Ron

kriki

Create 2 empty DB's with only the objects without data of both your versions.
The fields you know are not in use in the application can be shrunk to 1 char (bode Code and text fields) freeing up a lot of space.
Export the table in both DB's as text and merge them manually. Keep that version ready.
Export the table in one DB as fob and MERGE it into the other. If you saved enough space, it will be possible. After this, import the merged text file and compile the object.

rsaritzky

Thanks, Alan - interesting idea...
Ron

kriki

These are the steps necessary to merge to add-ons and you have a license that does not enable editing the add-on fields.
The extra step here is to make the unused fields smaller so they fit in a record. I also have had to do that a few times.