If, like me, you’ve committed yourself to a world of source control for your NAV projects, you’ve probably got repository upon repository just filled with text files, each one representing one of the 4,500 – 6000 objects within NAV, plus all those wonderful third party add-ons, custom solutions & other assorted dross with which we fill a database.
When it comes to migrating or upgrading these changes, you may decide you only want to start reviewing or processing those objects which have been modified. For my part, I’m in the process of converting a modification from 2017 to an extension ready to go on BC. Fortunately, this was always planned to be a stand-alone product, so was developed & kept in it’s own branch in our TFVC repo.
However, as per our standard process, this repo includes all nav objects for the database it was developed upon.
I now wanted to load those objects into a clean, shiny database (created in a docker container, using the standard MS images, of course) and rather than load all of those objects & suffer the tedium that follows, I wrote a script to identify objects within the branch which have been modified, and then I only need to load those objects into my base application.
Now, this is not the neatest or most efficient way to do this, and I’m certainly not the powersell guru that @waldo1001 is, but it works nicely with the setup I already have, and gives me the option to either run this for a single file containing all text objects, or a folder with one object per file.
In short, you provide a file path, the system identifies if this is a file or a directory, and then creates a variable filled with all the text files.
It then creates a nice clean target folder, runs through the objects & identifies if they have a ‘Time’ element that is equal to ’12:00:00′ or does not have a ‘Modified’ property tag. If both of those conditions are not met, then the file will be moved to the copy directory.
It should also be noted that this work is building upon works done by my undauntable colleague & confident James Pearson to split text files into individual files, so I could not take sole credit.
I expect to find quite a lot of use for this as we transition from C/Al to extension, and hopefully it will be of some help to you too!
Jack Mallender 
Hi,
I wrote a similar script, you just supply it with the following:
– One folder location which contains all standard objects, not modified.
– Then one folder containing all objects from the system you are working on.
– A folder location for the output
The script will then iterate through each Custom Object and find the related Standard Object using the filename (eg TAB167.txt).
It then uses “Compare-NAVApplicationObject” to see if these files are different i.e if the result of “Compare-NAVApplicationObject” is a Delta, then you can assume they are different.
You can then control the output to either just place the modified objects in a folder, or write the results to a .txt file. I just thought you might be interested as this goes a bit deeper than just using the date and modified flag.
LikeLike
We’ve done similar in the past, as well as using beyond compare to compare the two versions.
There are, as they say, many ways to skin a cat. I think it depends upon what you’re using it for – if I was doing an upgrade then I’d want to be more fastidious and would therefore take, compare & merge all objects.
But with the sorts of projects we’re working on currently, I can pretty much guarantee that this process works, and we have automated tests included so if it fails I’m certainly going to find out early. So in this case, I prefer to be quick and probably accurate, rather than slower and guaranteed accurate!
Thanks for contributing though – This sort of conversation is one of the reasons I’ve started this blog
LikeLike