(For more resources on Microsoft Dynamics, see here.)

The NAV tools and techniques that you use to determine what code to modify and to help you debug modifications are essentially the same. The goal in the first case is to focus on your modifications, so that you have the minimum effect on the standard code. This results in multiple benefits. Smaller pieces of well focused code are easier to debug, easier to document, easier to maintain, and easier to upgrade.

As of NAV’s relatively tight structure and unique combination of features, it is not unusual to spend significantly more time in determining the right way to make a modification than it actually takes to code the modification. Obviously this depends on the type of modification being made. Unfortunately, the lack of documentation regarding the internals of NAV also contributes to an extended analysis time required to design modifications. The following sections review some of the tools and techniques you can use to analyze and test.

Developer’s Toolkit

To paraphrase the introduction in the NAV Developer’s Toolkit documentation, the Toolkit is designed to help you analyze the source code. This makes it easier to design and develop application customizations and to perform updates. The Developer’s Toolkit is not part of the standard product distribution, but is available to all Microsoft Partners for NAV for download from the Partner website. While it takes a few minutes to set up the Developer’s Toolkit for the database on which you will be working, the investment is worthwhile. Follow the instructions in the Developer’s Toolkit manual for creating and loading your Toolkit database. The Help files in the Developer’s Toolkit are also useful. As of late 2009, the current NAV Developer’s Toolkit is V3.00. V3.00 does not deal with the new features of NAV 2009 associated with the Role Tailored Client or three tier functionality.

The NAV Developer’s Toolkit has two major categories of tools—the Compare and Merge Tools, and the Source Analyzer:

• The Compare and Merge Tools are useful anytime you want to compare a production database’s objects to an unmodified set of objects to identify what has been changed. This might be in the process of upgrading the database to a new version or simply to better understand the contents of a database when you are about to embark on a new modification adventure.
• The Source Analyzer tools are the more general purpose set of tools. Once you have loaded the source information for all your objects into the Developer’s Tools database, you will be able to quickly generate a variety of useful code analyses. The starting point for your code analyses will be the Object Administrator view as shown in the following screenshot:

  

When you get to this point, it’s worthwhile experimenting with various menu options for each of the object types to get comfortable with the environment and how the tools work. Not only are there several tool options, but multiple viewing options. Some will be more useful than others depending on the specifics of the modification task you are addressing as well as your working habits.

Relations to Tables

With rare exceptions, table relations are defined between tables. The Toolkit allows you to select an object and request analysis of the defined relations between elements in that object and various tables. As a test of how the Relations to Tables analysis works, we will expand our Table entry in the Object Administrator to show all the tables. Then we will choose the Location table, right-click, and choose the option to view its Relations to other Tables with the result shown in the following screenshot:

If we want to see more detail, we can right-click on the Location table name in the right window, choose the Expand All option, and see the results as shown in the following screenshot:

This shows us the Relations to Tables, with the relating (from) field and the related (to) field both showing in each line.

Relations from Objects

If you are checking to see what objects have a relationship pointing back to a particular table (the inverse of what we just looked at), you can find that out in essentially the same fashion. Right-click on the table of interest and choose the Relations from Objects option. If you wanted to see both sets of relationships in the same display, you can right-click on the table name in the right window and choose the Relation to Tables option.

At that point your display will show both sets of relationships as shown in the following screenshot for the table Reservation Entry:

Source Access

On any of these screens you could select one of the relationships and drill down further into the detail of the underlying C/AL code. There is a search tool, the Source Finder. When you highlight one of the identified relationships and access the Code Viewer, the Toolkit will show you the object code where the relationship is defined.

Where Used

The Developer’s Toolkit contains other tools that are also quite valuable to you as a developer. The idea of Where Used is fairly simple: list all the places where an element is used within the total library of source information. There are two different types of Where Used.

• The Toolkit’s first type of Where Used is powerful because it can search for uses of whole tables or key sequences or individual fields. Many developers also use other tools (primarily developer’s text editors) to accomplish some of this. However, the Developer’s Toolkit is specifically designed for use with C/AL and C/SIDE.
• The second type of “Where Used” is Where Used With. This version of the Toolkit Where Used tool allows you to focus the search. Selecting the Where Used With Options brings up the screen in the following screenshot. As you can see, the degree of control you have over the search is extensive.

  

  Screenshots of the other three tabs of the Where Used With Options form follow:

  

  

  

Trying it out

To really appreciate the capabilities and flexibilities of the Developer’s Toolkit, you must work with it to address a real-life task. For example, what if your firm was in a market where the merger of firms was a frequent occurrence? In order to manage this, the manager of accounting might decide that the system needs to be able to merge the data for two customers, including accounting and sales history under a single customer number. If you do that, you must first find all the instances of the Customer No. referenced in keys of other tables. The tool to do this in the Developer’s Toolkit is the Source Finder.

Calling up the Source Finder, first you Reset all fields by clearing them. Then enter the name of the field you are looking for, in this case that is Customer No., as shown in the following screenshot:

Now specify you are only looking for information contained in Tables, as shown in the following screenshot:

Next, specify that the search should only be in Keys, as shown in the following screenshot:

Your initial results will look like those in the following screenshot:

This data can be further constrained through the use of Filters (for example to find only Key 1 entries) and can be sorted by clicking on a column head.

Of course, as mentioned earlier, it will help you to experiment along the way. Don’t make the mistake of thinking the Developer’s Toolkit is the only tool you need to use. At the same time, don’t make the mistake of ignoring this tool just because it won’t do everything.

Working in exported text code

As mentioned a little earlier, some developers export objects into text files, then use a text editor to manipulate them. Let us take a look at an object that has been exported into text and imported into a text editor.

We will use one of the tables that are part of our ICAN development, the Donor Type table, 50001 as shown in the following screenshot:

The general structure of all exported objects is similar, with differences that you would expect for the different objects. For example, Table objects have no Sections, but Report objects do. You can also see here that this particular table contains no C/AL-coded logic, as those statements would be quoted in the text listing.

You can see by looking at this table object text screenshot that you could easily search for instances of the string Code throughout the text export of the entire system, but it would be more difficult to look for references to the Donor Type form/page, Form50002. And, while you can find the instances of Code with your text editor, it would be quite difficult to differentiate those instances that relate to the Donor Type table from those in any other table. This includes those that have nothing to do with our ICAN system enhancement, as well as those simply defined in an object as Global Variables. However, the Developer’s Toolkit can make that differentiation.

If you were determined to use a text editor to find all instances of “Donor Type”.Code, you could do the following:

Rename the field in question to something unique. C/SIDE will rename all the references to this field. Then export all the sources to text followed by using your text editor (or even Microsoft Word) to find the unique name. You must either remember to return the field in the database to the original name or you must be working in a temporary “work copy” of the database, which you will shortly discard. Otherwise, you will have quite a mess.

One task that needs to be done occasionally is to renumber an object or to change a reference inside an object that refers to a no longer existing element. The C/SIDE editor may not let you do that easily, or in some cases, not at all. In such a case, the best answer is to export the object into text, make the change there and then import it back in as modified. Be careful though. When you import a text object, C/SIDE does not check to see if you are overwriting another instance of that object number. C/SIDE makes that check when you import a fob (that is a compiled object) and warns you. If you must do renumbering, you should check the NAV forums on the Internet for the renumbering tools that are available there.

Theoretically, you could write all of your C/AL code with a text editor and then import the result. Given the difficulty of such a task and the usefulness of the tools embedded in C/SIDE, such an approach would be foolish. However, there are occasions when it is very helpful to simply view an object “flattened out” in text format. In a report where you may have overlapping logic in multiple data items and in several control triggers as well, the only way to see all the logic at once is in text format.

You can use any text editor you like, Notepad or Word or one of the visual programming editors; the exported object is just text. You need to cope with the fact that when you export a large number of objects in one pass, they all end up in the same text file. That makes the exported file relatively difficult to use. The solution is to split that file into individual text files, named logically, one for each NAV object. There are several freeware tools to do just that, available from the NAV forums on the Internet.

Two excellent NAV forums are www.mibuso.com and www.dynamicsuser.net.