Before it can be used, you must set a few required settings.
- Connection - Set the server where the NAV databases reside. You can set up to 3 different servers, 1 for each environment.
- Database - Provide the name of the database for the Development, Test (optional), and Live environment.
- Authentication - You can either provide a Username/Password or check the Use trusted connection. For sake of simplicity, this value will be used for all connections.
- If the "Refresh grid from imported objects only." is checked then the Authentication settings are not required.
- NAV finsql.exe - To be able to transfer objects, this is a required application and is essentially your NAV Development IDE. The Objects Manager does not interact with NAV directly but, instead, will use NAV’s Development IDE command line tool to export and/or import objects from and to NAV. If not found, try installing the development IDE on the machine. If you will be refreshing from imported objects only, no automatic export/import options are checked, and you will not be transferring any objects, then this can be left blank.
- Automatically export and import Development environment codes before each transfer or comparison.
If checked, each time you open the Object Transfer or Code Comparison window, this application will automically call the NAV finsql.exe to export the selected object's code to a text file and then import but only if a difference in the object's modification date is detected. This will give you the most accurate representation of the code differences between each environment. This option will only take effect on the Development environment objects.
- Automatically export and import Test/Live environment codes before each transfer or comparison.
If checked, similar to the above option, this option will take effect on the Test and Live environment objects only. The reason this is a separate option is to allow Microsoft Partners and Independent Service Vendors (ISVs) to have their license uploaded to the Development environment, for a quicker and easier way to keep the codes in the Development environment in sync for comparison. Besides, if the proper protocol is followed, the Development environment should be the only environment where developers should be making changes, therefore, it's the only environment where an automatic sync needs to occur.
- Refresh grid from imported objects only.
If checked, this application will only refresh its data from its internal database. This is useful if you do not have the SQL permission to access the database directly but you must keep the imports up-to-date else the representation of the differences may not be accurate.
- Transfer History
The number respresents how many different versions of the object will be saved. Keep in mind that objects transferred on the same day will be overwritten and only 1 version of the object, for that date, is saved. Older versions will be discarded.
Note: In order to automatically export codes from any environment, you must have the proper license from Microsoft uploaded in the particular environment.
Loading from Database or Imported Objects
This application stores the imported objects in an SQL Server database but it allows you to refresh from 2 different sources, SQL Server (directly from a NAV database) or Imported Objects only. Refreshing from SQL Server, if available, is the best option for this can give you an accurate representation of what's really in your environments but, more importantly, the differences between your Development, Test, and Live environments. If loading from Imported Objects, only objects that have been imported will be displayed and, obviously, the data may be stale if the objects are not imported regularly.
Note: Refreshing from SQL Server will only retrieve the latest values from the Object table. You still need to export/import the objects in order to get an accurate representation of the object's code. If the Solution Developer license is available in the environment, this application can automatically do an export/import upon a Transfer or Code Comparison. This can provide an extra layer of convenience to Microsoft Partners or ISVs who do heavy developments.
Listing and Filtering Objects
Depending on the chosen source, the main screen will list all objects from the database or imported objects.
Users have the option to narrow the list by setting the primary filters:
List only objects that have the Modified flag set to True, in any environment. Note that this isn't always a good indicator of an object's modification status, especially in environments that have objects exported, modified, and re-imported without updating this value.
- Date Mismatched
The object's modified date is different between any environment. Can be used to determine what's under development but this is primarily for determining what's different among the 3 environments.
- Size Mismatched
Just because the object's Modified Date matches doesn't necessarily mean the objects are identical. This can happen if the object was modified outside of the NAV IDE, as text, and re-imported without manually updating the Modified Date value.
As a general rule, all developments should be done in the Development database only. Use this to determine what's under development and/or pending transfer. This option will only look at the difference between the Development and the Live database.
To use this option, you must specify all 3 databases: Development, Testing, and Live. An object is considered to be under Testing if the "Modified Date" under the Testing database matches the Development database but not the Live database.
- All, Table, Page, Report, Codeunit, Query, XMLport, MenuSuite
Objects in the Development environment will serve as the primary objects. If the Modified Date in the Test or Live environment differs from the Development environment's, then their corresponding cell will be highlighted to give a better visual on the difference between the environments.
This application utilizes 2 types of filtering mechanisms, soft and hard. A soft filter applies an immediately filter on the contents of the grid but will not hit the database. This is useful for a quick refinement as well as a secondary filter. Items that are not within the soft filter criteria are merely hidden. A hard filter, on the other hand, will query the database, effectively clearing out any other filter currently in effect. Objects that are not within the hard filter criteria will not be loaded and will not be visible to the soft filter, although the soft filter can still be applied for further refinement.
- Standard Filter
In addition to the standard Show and Type hard filters, the results can be further refined with a soft and hard filter on the Type, ID, Name, and Private Note fields. As you key a value into the Filter textbox, the application will immediately apply a soft filter on the contents of the grid, listing only objects that contain the Filter value. Although this is a soft filter, if you click on the search, magnifying glass icon, this will effectively make it a hard filter. This filter will be within the confines of the Show, Type, and Project filters.
- Project Filter
Refined by values from associated projects.
- Team Member
Only objects that are associated with a project which you are listed as a Team member.
Only objects that are associated with a project which you are listed as a Collaborator.
Only objects that are associated with a project and has the selected priority.
Note: Projects with no priority set are considered Low priority thus they will fall under this criteria if no priority is set.
- Specific Project
Only objects associated with this specific project.
This can be especially useful when transferring development that affect multiple objects. First, right-click the grid and choose "Clear All Marks" to clear all existing marks. Then, filter by the project and right-click the grid again to choose "Mark All Listed Objects". Right-click once more and choose Batch Transfer to open the Batch Transfer window.
Notes and Communication
This application provides multiple ways for users to save notes and communicate. Each object can have it's own note, public and private. In addition to the note, there are also projects and collaborations within the project. An object can be linked to more than 1 project at a time.
- Public Note
Public notes are separated by the owner of each note. To enter a note, just type into the corresponding text box. The application will automatically save the note when you tab out or click on some other control. This note can be as simple as "I'm working on this." to something as important as "CAUTION: Field XYZ will be removed upon transfer." It can be a reminder to yourself but also let everyone know, "IMPORTANT: Must run Report XYZ to convert data after transferring." or to pose a question to everyone, "Does anyone know who made the change on line 123 or why? It was not documented.", without it being part of any particular project. When the object is transferred to the Live environment, the note will be saved along with the object's version code, available under the Transfer History. It will also be cleared out at the same time.
- Private Note
A private is visible only to the owner of the note. It can be a simple reminder to do something about the object, where you are on the development, something of interest or value, a memo for an upcoming meeting, etc. Unlike the public note, this note will not be transferred or cleared, when the object is transferred to the Live environment. It will be up to the owner to maintain this note.
- Project Note or Description
This note, as the name implies, is related to the project itself, not any particular object. However, multiple objects can be tied to the same project hence the objects can share a common note. In addition to the note is the collaboration tab, where users can publicly communicate with each other using a group text messaging style of communication.
Projects and Collaboration
In a busy environment or during the initial stages of implementation, for example, modifications can easily overlap. When more than 1 developer are modifying the same object, related to different projects, it's hard to tell which change was for which project. When the development is ready to be transferred to the Live environment, we can be wasting valuable time figuring out which object could or couldn't be moved due to the overlapping developments. This application aims to address that with a built-in project management system that allows multiple objects to be linked to multiple projects. When it comes time to transfer, we can easily tell when an object has overlapping development by looking at the project(s) it is linked to.
Click on this icon to open the project thats linked to the selected object. If it has not been linked to a project, a new one can be created and linked at the same time. If the object has been linked to more than 1 project, this icon will appear instead and a dropdown selection of linked projects will appear for you to choose from.
Click on this icon to open the Project Browser window, where you can view and manage all projects in your environment.
Click on this icon or anywhere within the bar to bring up the list of open projects to link the selected object to. The list is set to save as soon as you check or uncheck a project from the list.
|This application provides multiple ways for you to filter. Aside from the standard Show, Type, and Filter, you have the option to filter by the project associations. When you click on the icon, you'll be presented with several options. The first 5 options are static and will always be available while the remaining are based on the list of open projects in your environment.
- Team Member
List only objects associated to a project where you're listed as a Team member.
List only objects associated to a project where you're listed as a Collaborator.
- High, Medium, Low Priority
List objects based on project association and their priority.
Note: A project with no priority or objects that are not associated with a project are considered low priority thus will show under the Low Priority filter.
Source Control and Transfer History
Every time an object is transferred from the Development environment to the Live environment, a backup of the Live environment's code will be made. No need to check the source code in and out, and only codes that are valid and ready to be used are saved. To keep it even cleaner, all transfers within a day will be treated as a single transfer. For example, if an object was transferred to Live in the morning but a mistake was found or an additional, quick change was requested later in the day. When the object is transferred, within the same day, it will not be considered a new transfer and a new backup will not be created for the existing object for it's considered a minor, quick change that's not worth keeping history of.
A quick overview of the recently transferred object(s) is available on the lower right corner of the screen. Click on this icon to expand the list and to collapse it back to its normal size. To open the history window, double-click the object from the mini-history grid or right-click the object from the main grid and choose "View Transfer History".
In the Transfer History window, click on this button to compare the selected object's code to a version right before it. Similarly, click on this button to compare the selected object's code to that of the current, Development environment's version.
If an error was found and it couldn't be quickly fixed or you simply want to revert to the previous version of an object, click on this button to transfer the selected object to the Live environment, effectively restoring it to the selected version. Use precaution when doing this but also keep in mind that the restore will not restore data that may be lost if the change involves a table, with distructive changes, such as a column being dropped and was forcibly transferred.
There are 2 ways to transfer development codes to the Test and Live environments.
Single Object Transfer
To transfer each object, individually, you can either double-click the object from the main grid or select it and click on the button to open the Single Transfer window. In a single transfer, you can quickly and easily tell if the documentation of changes may be missing by looking at the Documentation area. This area will only show the differences that exist between the documentation in the Development vs. the Live environment. Nevertheless, it's still a good idea to use the Navigate Differences to quickly skim through the changes, to see if documentation may be missing for certain changes or if there were overlapping developments that may have been overlooked.
The button provides a comparison of the raw version of the code, without the need to export/import. For environments that do not have the Solution Developer license uploaded in the database, this provides a convenient way to do a quick compare without having to manually export and import changes first. In order to use this option, the DB connection settings must be present.
The button, on the other hand, provides a convenient way to import the latest code while in the Transfer window. For a cleaner comparison and better respresentation of the code, this is the preferred method. If your environment has the Solution Developer license uploaded, it's recommended that you check the "Automatically export and import..." options under Settings. By checking this box, the application will automatically check and import codes if changes were detected.
If the object being transferred is a table, you will be given the option to Synchronize Schema Changes. Similar to when the object is compiled from the IDE, Yes means Now - with validation, No means you will do this later, and Force has the same meaning. This option will always be visible under a Batch Transfer, however, it will only apply if the object being transferred is a table.
For every transfer, the object will be recompiled to ensure it is valid. Some objects may rely on others, therefore, you must transfer them in the correct order or use the Batch Transfer option. If there was an error during the transfer, you will have the option to undo or revert the transfer.
Multiple Objects / Batch Transfer
To transfer several objects at the same time, check mark each object to transfer then right-click and choose Batch Transfer. All objects that were checked will show up under the Batch Transfer window and all objects will be transferred together, separated by type. Once all objects have been transferred, they will be recompiled to ensure all objects are valid. Before transferring, be sure to check each object's documentation of changes and ensure there are no unintentional, overlapping developments.
Where Used and Advance Find
This application gives you the ability to find where an object is used or referenced by other objects in the code library. However, please keep in mind that this search may not yield results for objects that are dynamically referenced within NAV, such as reports that are defined within the Report Selection or Role Centers that are defined within the Profiles. To use, just right-click any object and choose Where Used.
The Advance Find, on the other hand, will search through the entire content of each object's code. When the Advance Find option is selected, the selected object's code (if available) will also be loaded into a code viewer window. As you type a value into the Advance Find textbox the application will immediately apply the search on the object's code and highlight the matching values. You'll be given the option to navigate to each area where the matching text was found. Click on the "Find in All Objects" button, or "Find in Where Used" if the Where Used is in effect, to begin the search through other objects as well. This is a very powerful and useful feature to find where an object's public function, for example, may be referenced. However, this isn't perfect since the find is for everything that matches the text. Use it in conjunction with the "Where Used" to limit the results to where the function by the same name exists and the object was referenced. On the other hand, you can use it to find anything, where a DotNet variable (System.IO.Compression.ZipArchive) or a Control Add-in (Microsoft.Dynamics.Nav.Client.WebPageViewer) for example, is referenced.
Note: Both features will only apply to objects that have been imported from the development environment, therefore, it is recommended that you do an initial text dump of all objects from your development environment and import it into this application before using these features.
To display the Context Menu, right-click anywhere on the main grid.
This option will display the text from the grid cell the mouse was right-clicked on. Selecting this option will copy the selected text to the clipboard.
Open the comparison window to compare the Development's code against the Live environment's code.
Open the comparison window to compare the Development's code against the Test environment's code.
Open the Transfer History window for the selected object. This is where you will be able to see the transfer history, compare version codes, download the fob, and restore the object.
Open the "Import text objects exported from NAV" window. This is where you can import and synchronize code from the 3 different environments. This is typically needed for environments that do not have the "Solution Developer" option in the license that's uploaded in the corresponding environment.
Generate a list of filters for objects that are not in sync between the imported object's modified date and the Development environment's modified date, from the database. This option is only available if the database connection is set. Use this option to easily create a filter for objects with stale code that needs to be reimported for an accurate comparison.
Check mark all visible objects in the grid. This is similar to the development IDE except, it will be saved until cleared by the user.
List only objects that have been marked.
Clear check mark from all objects, regardless if currently visible or not.
Open the Batch Transfer window for all check marked objects.
Generate an Excel spreadsheet of all listed objects.
Create a list of object ID filters that can be applied in the development IDE. A set will be generated for each type but, due to character limitations, if the number of objects exceed the limitation then additional sets will be generated to accommodate.
Use this option split a text export from NAV, containing multiple objects, into individual objects. The individual objects will have a file name in the format of "Type" "ID" "Name" and saved in the same folder where the selected file resides.
The application will attempt to find all areas in code that may be referencing the selected object. Keep in mind, however, that dynamically referenced objects, such as reports from within NAV's Report Selections will not be searched.
Show the Advance Find window and load the code for the selected object, if available.
Opens a standalone window to view the selected object's code.
The SS edition replaces SQLite with the more power SQL Server database engine thus it is faster and is more suitable for a multi-user environment.
The first time you run this application, you'll be prompted to log in with the option to create a new Config File or select from an existing, shared Config File. This setting is for the Objects Manager Database, where the codes are imported and *.fob files are stored when objects are transferred from the Development to the Live environment.
Please note that all users, even collaborators, will need to have read/write access to this database. You can use the same Username and Password for all users because this will only be used to interact with the database. The Objects Manager users are managed separately within the application itself. The config file is encrypted for your protection.