[Devora Locke]

Hi!  Looking for experience-based advice with NAV 2016 on how to best resolve an issue around custom fields in tables not allowing an E-Ship add-on to be installed.

We did a fair amount of customization around the Quotes system before go-live, adding pages, adding fields to sales tables, etc. As is, the system works well for us.  However, we are moving to Ph2, trying to install E-Shipping, and the vendor’s consultant is saying we have ‘too many fields’. Looking into it, we don’t actually have too many fields so much as the size of the active fields is limiting us. On all tables which pose a problem we are average 750 bytes over limit and so cannot install the software. 

What is the best, least buggy solution when everything already built is still very much needed?  Is it possible to ‘de-activate’ out-of the-box fields in tables that we do not use (e.g. Fax No.), and make up the difference that way? Do we need to create sub-pages and divide out some of our data? Sounds daunting,..  and pricey.  Some other solution?

Thanks for advice from anyone who has faced this issue before.

——————————
Devora Locke
Phoenix AZ
——————————

[Suresh Kulla]

Yes, you can disable the standard fields by unchecking the enabled for that field on the table, but you need to test it thoroughly because you will get an error when processing that field, you need to comment the code where that field is being used. It is not a recommendation and it would be safe and easy to do that for the custom fields.

——————————
Thanks
Suresh Kulla [Designation]
NAV Technical Architect
Atlanta GA
——————————
——————————————-

[Franz Kalchmair]

deactivating unused std. fields can be a solution. if you do that, recompile all objects afterwards and make many tests. 

one solution could be to create subtables, which are linked with the base table (e.g. item) using the same key(s). in the subtable the custom fields are stored. that architecture is also used for upgrades. for you that would mean much work, but having so many fields in a table, that it’s not possible to add some more, then your structure is not very good and needs redisgn all along. so better redesign now instead of later. 

other solutions:
– e-ship makes a custom version of their software version, which works with your structure
– use another shipping addin
– add needed functionality as custom code developed by your nav partner

none is a good solution. i think, there is none in your situation. these are your options.

——————————
Franz Kalchmair
Microsoft MVP
Senior Consultant
Austria, Europe
——————————
——————————————-

[Jason Wilder]

Many of us have run into this problem.  I agree with everything above but I almost always will opt for this solution instead:
Keep all fields active and simply reduce the field lengths of the Text and Code fields to 1 for fields you do not use.  This works great because all code will still compile.  If you do this incorrectly you will get a run time overflow error which you would then fix by increasing the length back to the original length.  You can use SQL Server to check if you are using certain fields or not to know if you are reducing the correct fields.  Table 36 Sales Header is the table that most people will bump into this problem with.

I will add as well that if you have a custom field or 2 that is 250 characters you might want to consider moving to another table as Franz suggested.

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Marije Brummel]

You can upgrade to NAV2018 and start using Extensions with companion tables. You should be able to move your own mods to an extension and keep E-Ship as Add-On in C/Side.

——————————
Mark Brummel
NAVUG All-Star
–
ForNAV
Olst
——————————
——————————————-

[Devora Locke]

Yet another reason to plan for NAV 365. Thanks All!

 

-Devora

——Original Message——

You can upgrade to NAV2018 and start using Extensions with companion tables. You should be able to move your own mods to an extension and keep E-Ship as Add-On in C/Side.

——————————
Mark Brummel
NAVUG All-Star
–
ForNAV
Olst
——————————

[Jon Long]

Upgrade and use table extensions. All other solutions are a hack. I wouldn’t deactivate any base NAV or ISV fields or keys. That is just adding fuel to the fire for the next upgrade.

——————————
Jon Long
Director of ArcherPoint-Upgrades
ArcherPoint Inc.
GA
——————————
——————————————-

[David Singleton]

Personally I would never recommend deactivating fields, most of the code will still compile, but will crash at run time.

I would recommend a hybrid of the suggestions above.

1/ Since the issue is mostly with Sales Header and Line, many of these fields can be reduced in length to 1 (as suggested above), just make sure to find the source field and reduce that also. This should give you a short terms solution where you can now implement eShip. And yes, I have done this myself on an eShip database for the exact same reasons you are having. (More than once)

2/ Once you have got this working you can now begin the process of piece by piece moving what you can to extensions, rather than having to do a big bang and move every thing at once.

Also consider that if you have some very large text fields, to replace them with flow fields pointing to a different table, Lookup fields are quite fast and the code changes to get them working is not as complex as trying to restructure the data model.

——————————
David Singleton
Go Live International
SQL Perform Navision Performance Consultant
dsingleton@go-live.us
——————————
——————————————-