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

premanathkumaragepremanathkumarage Member Posts: 4
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

  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    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
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • krikikriki Member, Moderator Posts: 9,115
    [Topic moved from 'NAV 2009 (formerly NAV 5.1/'6.0')' forum to 'NAV/Navision' forum]
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • KarenhKarenh Member Posts: 209
    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_SingletonDavid_Singleton Member Posts: 5,479
    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
  • David_SingletonDavid_Singleton Member Posts: 5,479
    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.
    David Singleton
  • davmac1davmac1 Member Posts: 1,283
    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_SingletonDavid_Singleton Member Posts: 5,479
    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:
    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?
    David Singleton
  • KarenhKarenh Member Posts: 209
    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_SingletonDavid_Singleton Member Posts: 5,479
    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.
    David Singleton
Sign In or Register to comment.