The active fields in a record cannot take up more than 4000

premanathkumarage

When I try to create a new field on the Sales Header Table I receive an error message saying 'The active fields in a record cannot take up more than 4000 bytes. The active fields in the Sales Header table take up 4012 bytes. You must reduce the number or the length of the active fields.'

Please note that my database can be considered as a highly customized one and I have already created more than 40 new fileds under 50000 series. When I read the error message it sounds like I have come to maximum limit to the customization. Is this conclusion correct?

Can somebody explain me the logic behind this restrction ? Is there any method I can go beyond this 4000 bytes maximum limit.

Actually I am in middle of an upgrade and the previously somebody has been able to create the these huge no of customized fields under 50000 series in Navision 3.7 database. Now I am in trouble and I can not take those customized filelds into the NAV 2009 version and now I am getting the above error message.

Can somebody help me on this and your valueble suggestions would be greatly appreciated.
PK

Slawek_Guzek

There is no special logic behind it. It is just a technical limitation imposed by maximum database page size, which is 4000 bytes in case of NAV native database, and 8062 in case of SQL, but NAV application must retain lover limit to maintain application compatibility between different types of databases.

There is not much you can do about is. You have to keep length of all your fields in any single table below 4000 bytes limit.
If you really need to store more data related to Sales Header move some of your fields from Sales Header to some new auxiliary table, but this of course requires quite big number of changes across system to keep things working seamlessly. A lot of programming to keep tables in sync, update both tables in forms, reporting from 2 tables...

The best solution in my opinion is to reconsider if all added the fields are really necessary on Sales Header. Perhaps you can remove some unused, perhaps you can make others shorter. 4000 bytes per single record it is really a lot.

My guess is you probably store some additional descriptions or comments (long text type data) - perhaps standard Comment functionality can be used for that ?



Regards,
Slawek

kriki

[Topic moved from 'NAV 2009 (formerly NAV 5.1/'6.0')' forum to 'NAV/Navision' forum]

Karenh

I ran into this for a client company. I then inactivated some of the standard fields that were not used, and was able to proceed. You can't deactivate a field used in a key.

David_Singleton

Karenh wrote:

I ran into this for a client company. I then inactivated some of the standard fields that were not used, and was able to proceed. You can't deactivate a field used in a key.

Nooooooooo!!!!!!! [-X


Never ever do this unless the person telling you to do this is standing behind you with a loaded pistol pointed at your head and you know from previous experience that they definitely will pull the trigger and are not just bluffing.

David_Singleton

premanathkumarage wrote:

When I try to create a new field on the Sales Header Table I receive an error message saying 'The active fields in a record cannot take up more than 4000 bytes. The active fields in the Sales Header table take up 4012 bytes. You must reduce the number or the length of the active fields.'

Please note that my database can be considered as a highly customized one and I have already created more than 40 new fileds under 50000 series. When I read the error message it sounds like I have come to maximum limit to the customization. Is this conclusion correct?

Can somebody explain me the logic behind this restrction ? Is there any method I can go beyond this 4000 bytes maximum limit.

Actually I am in middle of an upgrade and the previously somebody has been able to create the these huge no of customized fields under 50000 series in Navision 3.7 database. Now I am in trouble and I can not take those customized filelds into the NAV 2009 version and now I am getting the above error message.

Can somebody help me on this and your valueble suggestions would be greatly appreciated.
PK

Hi Premenath,
What exactly are you doing here? Are you taking over from another partner; or are you upgrading for another partner or was that "other somebody" someone else in your company?
I ask, because you are taking totally the wrong approach to this upgrade. Upgrading does not mean "compare objects" "merge" "Compile".

Upgrading is about giving the client a BETTER solution than they had before. If the new system is not better than the old one then don't upgrade.

So depending on who's client this is, someone needs to review all the bad modifications (4,000 bytes in one table = bad modifications, there is no doubt about that), and review them with the client. Then look at how to repair the damage make good business decisions WITH the client and work on a process to implement the system properly. Maybe even throw out the old system and start again might be the best solution.

The system needs to be redesigned and simplified.

davmac1

David: How would you know from previous experience they would pull the trigger? You would be dead!

Sometimes there are good reasons for adding text descriptions to a table. High volumes and SQL Server using varchar to keep the actual size down are reasons for limiting number of rows created.

However, when doing an upgrade, all the customizations have to be evaluated. Plus NAV usually adds new fields. New NAV functionality can obsolete or old customized funtionality.

Plus if you are upgrading your own work, you can revisit your old methods and logic and make improvements.

David_Singleton

davmac1 wrote:

David: How would you know from previous experience they would pull the trigger? You would be dead!

Opps you are right, that was pretty silly of me, I should correct that: it should read:

David Singleton wrote:

Never ever do this unless the person telling you to do this is standing behind you with a loaded pistol pointed at your head and <edit>the dead body of the programmer that refused is still lying on the ground next to you with a bullet hole in the head ,<edit>.

Better?

Karenh

Opps you are right, that was pretty silly of me, I should correct that: it should read:

David Singleton wrote:
Never ever do this unless the person telling you to do this is standing behind you with a loaded pistol pointed at your head and <edit>the dead body of the programmer that refused is still lying on the ground next to you with a bullet hole in the head ,<edit>.

Can you please explain why you think this is such a bad idea?

These were unused fields (client did not have manufacturing, job cost granules). I think they were flowfields. There have been no errors as a consequence.

David_Singleton

Karenh wrote:

Opps you are right, that was pretty silly of me, I should correct that: it should read:

David Singleton wrote:
Never ever do this unless the person telling you to do this is standing behind you with a loaded pistol pointed at your head and <edit>the dead body of the programmer that refused is still lying on the ground next to you with a bullet hole in the head ,<edit>.

Can you please explain why you think this is such a bad idea?

These were unused fields (client did not have manufacturing, job cost granules). I think they were flowfields. There have been no errors as a consequence.

They weren't flowfields. Flowfields do not count towards the 4,000 bytes, so deactivating them would not help. Thus my guess is you deactivated some standard fields.

If there have not been any errors, then it looks like you have done a lot of testing or been very lucky. So in your case you survived, but to advise someone else to do this as a matter of course is not a good thing.