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 Indifferent.
  • 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.


Comment List
  • I wouldn't say - I still recommend for just adding the options at the end of the string.

    The best way is to set it to the End plus about 10 commas.

    So not




    The reason is very simple ... merging.

  • An extra remark for adding an option to an existing list of options:

    Not just add it to the end, but add some , before it.

    In general I start to use the 20th value for the next option. This way, you leave some space for future standard options.





    If tomorrow MS decided to do this:

    "FIFO,LIFO,Specific,Average,Standard,Some MS Value", you do not need to change the value of option "Waldo" in the database.

    Also use this in the option-captions.

    The beautiful thing is that the empty option-values are NOT shown between the possible option to choose from.

  • Yes that's correct. If you export an uncompiled object, then you only export the text. When you compile it you export both the executable object AND the text.

  • Thanks for sharing this, David.

    It actually makes we wonder.  If you save the object uncompiled ... and you export the object ... do you get the text file in stead of the fob file?


  • Yes Eric, very useful blog, I am sure it will help a lot of people.

    Just to add to this, you can also do this in the normal C/SIDE editor without every having to export anything. Like this:

    Find all the objects that have the Optin used.

    Open the object, and start to save it.

    At the prompt to save Yes/No de-select the object to compile.

    (So save the object un-compiled)

    Repeat for all objects.

    Now go back to the tables with the Options.

    Change the option string.

    Repeat for all the required tables.

    Now select all the objects that are un-compiled.

    Hit F11.

    Since the objects were saved in text format, its just like using a text editor, in that the integer value is not used.

  • Hey, that's cool Smile.

    I wrote the article, but I was doubting to put it online.  Glad I did though Wink.

  • Hi Waldo, nice blog-article. I will refer future students to this when explaining when to use the fob and when to use the txt format for objects.



    Microsoft Dynamics MCT