As with any system where we can do development work, careful attention to documentation and backing up our work is very important. C/SIDE provides a variety of techniques for handling each of these tasks.
When we are working within the Object Designer, we can back up individual objects of any type or groups of objects by exporting them. These exported object files can be imported in total, selectively in groups or individually, to recover the original version of one or more objects.
NAV 2017 introduces Windows PowerShell Cmdlets that support backing up data to NAVData files. Complementary Cmdlets support getting information or selectively retrieving data from previously created NAVData files. Although these tools promise to be very handy for repetitive development testing, they are challenging (or worse) to use in an environment of changing table or field definitions.
When objects are exported to text files, we can use a standard text editor to read or even change them. If, for example, we wanted to change all the instances of the Customer field name to Patient, we might export all the objects to text and execute a mass Find and Replace. Making such code changes in a text copy of an object is subject to a high possibility of error, as we won't have any of the many safety features of the C/SIDE environment to limit what we can do.
Internal documentation (that is, inside C/SIDE) of object changes can be done in three areas. First is the object version list, a field attached to every object, visible in the Object Designer screen. Whenever a change (or set of changes) is made in an object, a notation should be added to the version list.
The second area for documentation is the Documentation trigger that appears in every object type except MenuSuites. The Documentation trigger is at the top of the object and is the recommended location for noting a relatively complete description of any changes that have been made to the object. Such descriptions should include a brief description of the purpose of the change as well as technical information.
The third area we can place documentation is in line with modified C/AL code. Individual comment lines can be created by starting the line with double forward slashes, //. Whole sections of comments (or commented out code) can be created by starting and ending the section with a pair of curly braces { }. Depending on the type of object and the nature of the specific changes, we should generally annotate each change inline with forward slashes rather than with curly braces wherever the code is touched, so all the changes can be easily identified by the next developer Although the use of curly braces is permitted by the software, Microsoft warns of potential conflicts with Powershell upgrade processes.
In short, when doing development in NAV C/SIDE, everything we have learned earlier about good documentation practices applies. This holds true whether the development is new work or modification of existing logic.
