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
Comments
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
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
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.
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.
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.
http://mibuso.com/blogs/davidmachanick/
Opps you are right, that was pretty silly of me, I should correct that: it should read:
Better?
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.