Copy/Move Data placed in Surrogate Key Based tables

An example of how to do things very generically when using the Surrogate Keys Design Pattern is when you need to copy or move data attached to one record to another record.

Looking at classic design you often see different functions created to copy or move data in Subsidiary Tables between different master records. Take an area like Comments (My favorite example) where we have 29 different implementations of it (at least if I can count correctly). Let’s say I would like to copy or move the comments between any of these 29 implementations to any other of them. Now with 29 tables in play I would need to create a function from the first table and to all the other 28 tables. Than do it again for Table 2, 3, … & 29.

Yes that is a lot of functions and not exactly a small task.

So what is the difference if I had used a Surrogate Key and created only one generic implementation of Comments?

Well my copy function could look like this:

Because I am always using the same record to store my Subsidiary Table Data it is very easy to copy from one Master Record to another.

To make is even more generic and because I am lazy by nature I also added this function.

So now I can copy between 2 Records, 2 RecordRefs or a combination of a Record and a RecordRef without knowing anything about them.

This last function relies on a few other functions in the same codeunit.

These 2 functions in turn relies on my RecordRefLibrary Codeunit and the function

And my SurrogateKey Management Codeunit with this function.

Yes I use a fixed Field No for all my Surrogate Keys and no it is not 59999, but I had to create an example for this blog.

Before you ask why I use a fixed number I better address it.

There are 3 reasons for it:

  1. It is the easiest
  2. Once (Not when or if) Microsoft gets around to make their own version of a surrogate key in NAV it would make the most sense they did something similar
  3. It makes (at least that is my hope) for an easy and generic upgrade script once this finds its way to the standard platform

Let’s get back to the real issue here. Basically in a few lines of code we have resolved all our coding needs for copying comments between any master records and it doesn’t matter how many Master Tables comments are added to in the future. This will always work.

Creating repeatable implementations starts with creating repeatable code.

 

 

Find your Table ID

Using many hours programming with my favorite Design Pattern “Surrogate Keys” I often need to know simple things that can be a little hard to find at times.

One of these is to know the Table ID of any record I might be handling at any given time.

All the tables that use the surrogate key pattern use a primary key based on “Table ID”, a “Surrogate Key Reference” & maybe a “Line No.” or “Code” depending on what the table is hosting of data. In other words I often need to know the Table ID to filter correctly based on the record I am calling from.

I handle this with the following Code:

The ReturnTableID function takes a Variant as Parameter and calls Variant2RecRef to get it transformed to a Record Ref no matter if a Record or a Record Ref was passed to it. After that the function Returns the RecRef.Number which is the Table ID of whatever was passed to it.

This way I can call the first function with any Record or RecordRef and get the Table ID returned.

This creates a completely generic function that always returns your Table ID.

This is a fixed part of my RecordRef Library Codeunit and now hopefully of yours too.

Social Listening

While on MSDN I came across some new Help Content for Dynamics NAV 2015 talking about Social Listening.

Now while Social Listening might not be on everybody’s “must have list” it is still a great way to show the power of Dynamics NAV and the application stack from Microsoft.

I look very much forward to see what these new topics mean for the product.

Have a look here:

https://msdn.microsoft.com/en-us/library/dn889763(v=nav.80).aspx

Update:

I was made aware by Vjeko that there is an “How Do I” YouTube video on the topic too…

https://www.youtube.com/watch?v=8QO9U1h921c

Mixing concepts – code vs. translations

In my little miniseries here of things we can do better I would like to put focus on another conceptual issue that we really need to deal with too.

Code and Translations are 2 very different things and they should never be mixed. Okay I said it and maybe I will get a little verbal beating for doing so, however it doesn’t make it less true.

The way we deal with translations today by putting them into the compiled objects has its roots a very long time back in the application. Long before Dynamics NAV had a service tier. Long before we had even considered SQL as a database platform and maybe it is time to rethink that again. I am not saying that they did it wrong when they created translations the way the work today, but I am simply saying that the times has changed and so should the product.

Purely form a conceptual point of view Code and Translations should never be mixed. It is simply a bad practice.

Now we can technically already do this as we can host the translations on the service tier and not include them in the code, however this is not the standard way and unless you work with a country that needs this, we hardly ever see this in any install.

You can read all about how this is done on MSDN here:http://msdn.microsoft.com/en-us/library/dn479852%28v=nav.80%29.aspx

Now at this point Microsoft doesn’t recommend this unless needed because it is slightly slower than using the translations when compiled into the objects. So you have been warned… J

In a side note when it comes to this discussion: “Why do we handle translations the way we do?”

Take a word like “Customer”. The word is translated many times because it exist in many locations across the code, but why do it that way? This is not a very efficient way of handling the translations and it would be far more efficient if we stored this translation once and pointed to it many times based on need. This would also greatly help when a given translation needs to be changed by a partner for a given vertical as I am sure many of you have tried.

I want to see our great product become even better than today. We need to constantly improve to stay in the lead. Removing these simple inefficiencies, so partners and developers can concentrate on building great products, will surely benefit us all.

Fixed text format

If you are working with NAV and Source Code Management you will know how easy it is to get a text file exported in the wrong format. The formatting of dates and numbers is done differently from country to country and even inside some countries causing issues with your source code management if everybody in your team don’t make sure to export with the agreed regional settings.

What makes it even worse is if this code finds its way into your source code as you will most likely not be able to do your build from it. Because the dates and numbers now are formatted wrongly your import of the text files fails or even worse imports them incorrectly.

In any case that is not what you would want to see happen and as an avid Source Code Management advocate it bugs me.

The solution would be that we had a fixed format in the export/import that would be independent of your regional settings. What if text export always, without exception, exported in one format and imported in the same format. Would that cause problems? I don’t think many would have issues with that.

In other words a good suggestion to improve Source code management adoption would be to create exactly this.

Just saying 🙂

Codeunit 1 Merge Conflict Issue

If you have ever merged Codeunit 1 you will have noticed that you always get a merge conflict in the functions ApplicationVersion and ApplicationBuild at least if you have added your own versioning which most vertical solutions would have done.

Standard the 2 functions look like this depending on what Cumulative Update you are on

And typically I would add my own function call (Hook) inside the EXIT to call and add my version or build number.

The result of this is of course that in the next merge I have changed this line and so has Microsoft giving me a conflict, which I will get every single time I try to implement a Cumulative Update. Very annoying to say the least and with no good work around.

So what would the solution be?

Well if Microsoft would add a standard hook here to an empty function returning nothing we as partners would be able to add our hooks in this function and avoid the conflict.

Now that resolves the major part of the problem as long as we as partners also remember to add our code nicely here, so we don’t start getting conflicts when using each other’s add-ons.

Comments are evil

I have often had the discussion with somebody about commenting code.

I have heard all the arguments:

  • We need to comment code, so we can see what code we took out or changed.
  • We need to comment code, so we can see who did this, when and why.
  • We need to explain what this code does, so it is easy to understand for the next guy.

I am sure there are many others, but it doesn’t change my view that COMMENTS ARE EVIL.

First of all Comments can be 1 of 3 things:

  • Correct
  • Misleading
  • Out right wrong

Best case if of course that they are right. That is what we all strive for, but sadly rarely archive. In most cases they are misleading because the written language isn’t code and rarely clearly define what we really mean to say. It is simply too complex in many cases to say something described in the code in the written language without missing something. I guess that is why we write code and not novels. Then there is of course the case when comments are out right wrong because we forgot to update them or because we just wrote them down all wrong.

Generally Comments are just a way to hide bad code. The only true comment is the code and it should be written clearly and well-defined so it is easy for anybody else to read and understand. Always look back at your code. If it is hard to read and understand you should most likely rewrite it.

Then there are the arguments that we need to be able to see what we changed compared to the standard code form Microsoft. Just another excuse used by people that don’t use a proper source code management tool like Team Foundation Server or Visual Studio Online. The latter is free for up to 5 users and most of the job can be automated via PowerShell so there is really no excuse. The new tools we got to merge code from Microsoft in the form of PowerShell cmdlets also doesn’t need comments or the old code to work. More often these comments might actually confuse the tool.

Oh yes and then there of course is the arguments that we need to understand who did something and why. Again that is why you should use a complete tool like Team Foundation Server or Visual Studio Online where you can track and manage your development work. What exactly comes out of our development team? Track it both from your tasks and requirements to the code and back.

When it all comes down to it there is really no getting around it that COMMENTS ARE EVIL and we should try to do better.

Passing Records and RecordRefs via Variants

As developers in an ever more repeatable world we should strive to write code in ways that make it as flexible and generic as we possibly can. A trick I use is too pass things around in ever more generic ways by using Variants.

A good example can be seen below where the function ReturnRecordIDasText function takes either a Record or a RecordRef as input and then returns the RECORDID as text.

The important thing to notice here is of course that the function can take more than one datatype as input giving the function even greater usability.

Before anybody notice I better say that passing variables by reference is a limitation of the example above. Still a good trick though according to me.

Hopefully you find this trick useful too.

PS. I have seen Waldo use the same trick in a slightly different way, so credit should absolutely also go to him in this case.

Comment and Uncomment Selection – New feature in NAV 2015

One of the small features in Microsoft Dynamics NAV 2015 is the ability to comment a selection of code.

Now I am not a huge believer in putting comments in code. Actually I am of the school that think comments are evil, because code should be written so it explains itself. That aside I find the new feature handy when testing and you want to take something out just for a test run.

How does it work?

If you are in the code you can mark a few lines of Code like this

Then click “Comment Seletion…” under the Edit Menu or use the shortcut Shift+Ctrl+K and the marked lines will be commented out by setting 2 forward slashes in front of the code at the left margin.

There is also an “Uncomment Seletion…” with the shortcut Shift+Ctrl+O that will remove the comments again.

Absolutely a help to developers, but please consider how you use comments.

Comments should not be needed in the final version of great code.

How do I Videos

Back in April I posted an index of “How Do I” Videos on this blog. I felt there was a need to have them indexed somewhere, so everyone can find this great work in an easy way. It is such a great resource for so many things and I use them myself frequently.

Yesterday I noticed that all the videos are nicely indexed on MSDN and I thought that was worth a blog post to share.

http://msdn.microsoft.com/en-us/dynamics/nav/ff518990