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:
- It is the easiest
- 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
- 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.