No I don't have any fear of uncertainty. I just have a lot of experience with bad things happening when people start messing around with NAV system tables.
Do what you want, I could care less if you screw up your system, just be aware that a lot of experienced people around here offer a more common alternative (make your modifications to table 79 - Company Information). Everything else is at your own risk, although there are people here who will help in return for proper compensation
Does this also has anything to do with record size? Company Information table is much larger than Company table. Is it better to only load smaller table if only one field was needed?
Does this also has anything to do with record size? Company Information table is much larger than Company table. Is it better to only load smaller table if only one field was needed?
How many times per second do you think to request the record in this table?
There is only 1 record, so before you start your procedure to check/post/process/... 1.000 or 1.000.000, you do a get on that table and you don't need to do it anymore.
If it is in some trigger launched by some user-action, I wouldn't worry neither.
Regards,Alain Krikilion No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
I have done this once for a client in 3.7.
We needed a cross reference number for every company, and the company independent table. So that every company needed to know what other company cross reference was.
Client didn't want to create a new table to be maintained.
They have upgraded to 4.0 and 5.0.
I've seen User table 2000000002 Name field being increased because of overflow.
I would follow better safe then sorry motto.
Ahmed Rashed Amini
Independent Consultant/Developer
My answer to questions like this are similar to the guy that goes in to the Rolls Royce dealer.
He asks the sales man "How much is this Rolls Royce"
The salesman replies "If you have to ask then you can't afford it".
I know it does not make sense to say this, but basically if you are not sure, then you really shouldn't be experimenting.
I have often added new fields to the NAV system tables. For example I had a project that required a highly integrated inventory system between multiple companies. Fields added to the company table controlled the creation of new items, and their distribution to the other companies. The solution made good sense and works fine.
But messing up any of those tables can be disastrous.
Comments
RIS Plus, LLC
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
RIS Plus, LLC
Thanks.
Do what you want, I could care less if you screw up your system, just be aware that a lot of experienced people around here offer a more common alternative (make your modifications to table 79 - Company Information). Everything else is at your own risk, although there are people here who will help in return for proper compensation
RIS Plus, LLC
There is only 1 record, so before you start your procedure to check/post/process/... 1.000 or 1.000.000, you do a get on that table and you don't need to do it anymore.
If it is in some trigger launched by some user-action, I wouldn't worry neither.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
We needed a cross reference number for every company, and the company independent table. So that every company needed to know what other company cross reference was.
Client didn't want to create a new table to be maintained.
They have upgraded to 4.0 and 5.0.
I've seen User table 2000000002 Name field being increased because of overflow.
I would follow better safe then sorry motto.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
He asks the sales man "How much is this Rolls Royce"
The salesman replies "If you have to ask then you can't afford it".
I know it does not make sense to say this, but basically if you are not sure, then you really shouldn't be experimenting.
I have often added new fields to the NAV system tables. For example I had a project that required a highly integrated inventory system between multiple companies. Fields added to the company table controlled the creation of new items, and their distribution to the other companies. The solution made good sense and works fine.
But messing up any of those tables can be disastrous.