Lazy Programming: What text-based object files are good for ...

Last week, I had to do a considerably small change in one of our "Tools". Considerably ... I had to add 4 options to an option field ... and I had to put it in between other option values. First reaction: I don't like that. Second reaction: let's put it at the end to avoid problems (which cascade in other problems and so forth). I did not want to put it at the end of the option values, because the values just did not belong there... .

Exporting all (changed) objects to a text-based file, and start file/replace, can help you do this.

I'll try to explain:

First of all, internally (once you saved a compiled version of an object), NAV works with the integer values of an option (as well as fields, by the way). For example:

1. In table 27 (Item), we all know the Option Field: Costing Method with the Option String: FIFO,LIFO,Specific,Average,Standard.
2. Let's create a new codeunit with this code (and save and compile):

   IF lrecItem."Costing Method" = lrecItem."Costing Method"::"FIFO" THEN;

3. Now, let's add an option value to that field so that the Option String becomes: waldo,FIFO,LIFO,Specific,Average,Standard
4. Just open your codeunit again and you'll see your line of code has changed to:

   IF lrecItem."Costing Method" = lrecItem."Costing Method"::waldo THEN;

Internally, it was referring to option value 0, not "FIFO" ... and that's the main reason why adding options usually is a pain in the ass.

When you import a text file, it's the same as creating a new object, writing all the text that exists in your text file into the object, and save it (not compile). Let's try to do the same as above and see what happens. So we'll start with table 27 Costing Method field without the extra option:

1. Export table 27 and your codeunit to a text file.
2. Open the text file and replace "FIFO,LIFO,Specific,Average,Standard" by "waldo,FIFO,LIFO,Specific,Average,Standard". (You'll have to do this for all translations as well ... ).
3. Save the text file and import in NAV.
4. If you check the table and field, you'll see the options has been added. If you check the codeunit, you'll see the code is still correct!

So, using text files, you avoid working with the internal integer values.

What else it is useful for:

You can apply the same method when you work with automation, and you want to install a new version. In my experience, when upgrading my WaldoNavPad, a bunch of code was changed (some function names/properties/... changed to other function names). I'm not a real .NET expert, and I don't know why this is. But as I always write my automation code in one or two codeunits, this is my workaround for it:

1. Export the codeunit(s) to text
2. Install the new version of the NavPad
3. Import the codeunit(s) and compile

I would like to end with a few warnings:

• Be sure you export all objects where the options are used. This is rather easy for customizations, but quite difficult for standard option fields. For this, I recommend using the Developer's Toolkit or just export all objects .
• This solution will only work when you use options in code like:

  IF myOptionField = myOptionField::"The Option Value" THEN ...

  And not:

  IF myOptionField = 1 THEN ...

• Mind the translations.
• Update your data. (the values won't be updated when changing your objects, off course). This can have a huge impact, because one option field is usually used (copied) in multiple tables. You have to update your live system.

Keep these warnings in mind. I still recommend for just adding the options at the end of the string. Definitally in a live system.

Hope it's useful!

Ps, When writing this blog, I found a thread on Mibuso that already covered this topic. You can find it here.