changing a option field on a line table

kikkoman
Member Posts: 57
hello everyone,
i was wondering if there was a way to delete some values that were tied to an option variable on a line table? ok, i know you should not do this b/c it will cause major headaches later on when doing upgrades or whatever else. i was just curious if there was a "Correct" way of doing this. for example, removing some values and replacing them with a new option for, lets say a variable called Type.
i know that you have to go through the whole line table and however many codeunits to correctly number the option variable to what you want, but this does not seem to be a good way of doing it b/c you don't know which codeuints are effected?
i have talked to another programmer and was told to NEVER remove option values, just append to them. i agree with this 100% b/c trying to do so will cause major problems.....so i was just curious if anyone had tried this before or got it to work?
its probably a navision standard to NOT remove any option values, but only append to them, but i probably forgot it while reading all of those freaking manuals :shock:
hmmm...is there a way to leave the options the way they are and then add a new one to the end, but then on the form itself, maybe just allow the option variable display the options you want them to select?
like you have 5 options and then add a new one, so you have 6. but lets say you only want to let users see 3 of those options?
but like i said before, i am just curious...the answer is probably NO, which is what i think, but i wanted to hear from everyone on their experiences with this issue.
thanks for your input!
i was wondering if there was a way to delete some values that were tied to an option variable on a line table? ok, i know you should not do this b/c it will cause major headaches later on when doing upgrades or whatever else. i was just curious if there was a "Correct" way of doing this. for example, removing some values and replacing them with a new option for, lets say a variable called Type.
i know that you have to go through the whole line table and however many codeunits to correctly number the option variable to what you want, but this does not seem to be a good way of doing it b/c you don't know which codeuints are effected?
i have talked to another programmer and was told to NEVER remove option values, just append to them. i agree with this 100% b/c trying to do so will cause major problems.....so i was just curious if anyone had tried this before or got it to work?
its probably a navision standard to NOT remove any option values, but only append to them, but i probably forgot it while reading all of those freaking manuals :shock:
hmmm...is there a way to leave the options the way they are and then add a new one to the end, but then on the form itself, maybe just allow the option variable display the options you want them to select?
like you have 5 options and then add a new one, so you have 6. but lets say you only want to let users see 3 of those options?
but like i said before, i am just curious...the answer is probably NO, which is what i think, but i wanted to hear from everyone on their experiences with this issue.
thanks for your input!

0
Comments
-
There is a pretty easy workaround for it.
Just create a new option-field with your optionstring. In code, synchronize it with the default existing option-field (e.g.-type), with calling the OnValidate-trigger.
Only show this field on the subform... not the default field.
That should be all...0 -
thanks for the reply Waldo, but there seems to still be a problem.
if i create a new option-field and place the string i want for it, then use the code in the Type OnValidate trigger and place that into my new fields Onvalidate trigger, i will still have a problem b/c my new option-field optionstring will still be numbered and conflict with the native navision Type field. like if you go into the "No." field and look at the OnValidate trigger, it will still have Type::"0", Type::"1"...etc.
but those Types are tied to the original option field and i will have to still go into the code and replace each one so that i doesnt conflict with my new option field.
e.g. original G/L Account (0), Item (1), FA (2) and Charge (3)
new G/L Account (0), Mynewoption(1)
so everytime there is a Type::"1", the code will run as if the type was Item and NOT Mynewoption.
the way i have it now is that i just append to the original option-field
G/L Account (0), Item (1), FA (2), Charge (3), Mynewoption (4)
this will work b/c nowhere in the code does it reference Type::"4", so I just add that part of the code, but since i would like to remove some of the optionstrings b/c the users will never use them, it would look much nicer!
i hope i understood what you were saying Waldo, but if not, please correct me
thanks for the help....0 -
I don't think you got what I meant.
Just create a new field with the wanted options.
OnValidate of your NEW field: Write code to change the Type-field as well.
E.g.
Your new field has two options: Item,Resource
OnValidate of your new field:CASE NewField OF NewField::Item: VALIDATE(Type, Type::Item); NewField::Resource: VALIDATE(Type, Type::Resource); END;
This way, you change the Type-field along with your new field, plus, you're calling the validate trigger of the Type-field, which is necessary to call the standard code ... .
Hope this is more clear...0 -
You easily limit the number of options displayed on the form by putting the desired ones in "OptionString".Property of the TextBox. You'll just have to remember this every time when designing new forms where this field is included. :roll:Kai Kowalewski0
-
One way around: Modify your CaptionML on the Option field = replace all values you do not want to show with empty string and they will be not showed. But do not change the OptionString...
for example Type from sales line:Before: ,G/L Account,Item,Resource,Fixed Asset,Charge (Item) After: ,,Item,Resource,,Charge (Item) In the list will be: <empty option> Item Resource Charge (Item)
0 -
hm,
I did not know that... . This is a nice workaround, but to be really honest ... is this clear for someone who is (for instance) upgrading the database and did not implement the change...? I find it rather ambiguous to change functionality ... by changing the multilanguage-stuff ...
just an opinion... :oops:0 -
If you change only the CaptionML, it is only visual change, not functionality... functionality is still same... only user do not see all option values... And if you forget to merge this change in upgrade, it means, that user will see all values... but no functionality will be touched. 8)
Problem with upgrade is same as if you change some FlowField definition... of course you must documentate this...0 -
thanks for the input everyone!
i really appreciate it....good stuff0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions