formatted nav patterns

content/NAVPatterns/1-patterns/implementation-of-surrogate-keys-using-autoincrement-pattern/index.md

@@ -4,7 +4,7 @@ weight = 630
 +++
 _By [Soren Klemmensen][anchor0], [_Partner-Ready-Software_ ][anchor1] & [360 Visibility][anchor2]_
 
-## **Abstract**
+## Abstract
 
 This Pattern is meant to create generic & reusable links between tables. The goal is to have an easy generic way to link a generically designed sub table to a record on a main table which can be used for other links too.
 
@@ -13,7 +13,7 @@ To minimize the impact of customizations and to keep modules as generic and reus
 * To create a generic and reusable auto generated link (A Surrogate Key), Immune to natural key data & requirement changes, on a main table with minimum impact on the table. 
 * To create generic and reusable sub tables that effortless can be reused anywhere in the application.
 
-## **Description**
+## Description
 
 Over years of development many things are repeated across different implementation and even inside the same application. A typical example could be adding comments to an area just as it is done in Microsoft Dynamics NAV multiple times. There can be reasons for doing this again and again, but not only does this need to be maintained and upgraded over the years, but all the implementations of comments also needs to be tested separately. If a standard and generic comment could be developed and a generic way of connecting it to a main table this could be resolved. This is exactly what this pattern is trying accomplish.
 
@@ -21,25 +21,19 @@ Over years of development many things are repeated across different implementati
 
 _Figure 1: Table structure for linking a Document Header and Line Table with a Document Comment Table._
 
-__
-
-_[![ ][image1]][anchor4]_
+[![ ][image1]][anchor4]
 
 _Figure 2: Table Structure for linking a Master Data Table with a Master Data Comment Table_
 
-__
-
 A typical way of linking a table to master data or to a document has been to use the primary key of the table being linked to. This causes some issues as the linked table now is designed specifically for the main table and it functionality cannot be reused. In case of renames the linked table needs to be renamed too which is costly in processing. Code also needs to be added on the delete trigger of the table to ensure that the attached records get removed if needed which increases the over all footprint of any change.
 
-_[![ ][image2]][anchor5]_
+[![ ][image2]][anchor5]
 
 _Figure 3: A Generic Way of creating a Comment table and linking it in a generic way to the main table no matter what this table might be. The Unique Record Identifier on the main tables is an Integer with AutoIncrement set to yes._
 
-__
-
 It is recommended using this pattern in all tables which need sub tables unless specific reasons exists for not doing this.
 
-## **Usage**
+## Usage
 
 **Step 1**: Create a generic Unique Record Identifier in the main table
 
@@ -77,13 +71,10 @@ Let's assume we would like to create comment for a larger number of very differe
 
 **Update the Customer table (Step 1)**: Go to table 18 Customer and add Field 50000 Unique Record Identifier. Set the Property Data Type to Integer, Editable to No & AutoIncrement to Yes. Save the changes. 
 
-_[![ ][image3]][anchor6]_
+[![ ][image3]][anchor6]
 
-__
+_[![ ][image4]][anchor7]
 
-_[![ ][image4]][anchor7]_
-
-__
 
 **Create Comment table (Step 2)**: Create a new table called Comment. Add 3 fields Table No., Unique Record Identifier & Line No. all of Data Type Integer. Make these 3 fields into the primary key for the table. Add a 4 field called Comment with Data Type Text(80). Save the changes.
 
@@ -91,34 +82,24 @@ __
 
 **Create the Comments page (Step 3)**: Start the page wizard and create a Page based on table comment created above as a List only showing the Comment field. Set AutoSplitKey property to Yes on the page.
 
-__
-
 _[![ ][image6]][anchor9]_
 
-__
-
 **Update the Customer Card (Step 4)**: Add an action to the Customer Card to open the Comments. Go to Actions and create an action called Smart Comment. Populate the properties RunObject, RunPageView and RunPageLink as see in the picture below.
 
 [![ ][image7]][anchor10]
 
-__
-
 **Create a hook OnDatabaseDelete (Step 5)**:
 
 Create a codeunit 50000 called "ApplicationManagement Hook" with one function called OnAfterOnDatabaseDelete taking the parameter RecRef of Data Type RecordRef. Add it as a global variable to Codeunit 1 ApplicationManagement and call the function as the last line in OnDatabaseDelete. Please read about the hook pattern before implementing it.
 
 [![ ][image8]][anchor11]
 
-__
-
 **Create the code needed to delete comments linked to a deleted record (Step6)**:
 
 Create a DeleteComments function taking the RecRef of Data Type RecordRef and add the code as shown blow.
 
 [![ ][image9]][anchor12]
 
-__
-
 It is assumed in this example for simplicity that the Field 50000 is reserved across the entire application for the Unique Record Identifier as defined in Step 1\.
 
 The comments are now fully working if we look away from the fact that we did not deal with a few things specific to Sales orders like RecreateSalesLines function, Archiving and Copy Document. All of which can easily be dealt with.
@@ -133,24 +114,22 @@ Upgrade wise there can be an impact if data is moved out of tables to be reinser
 
 Other risks could be if Transfer Fields are used and data is being copied unintentionally.
 
-## **NAV Usages**
+## NAV Usages
 
 This is a new pattern not currently used in Microsoft Dynamics NAV.
 
-## **Ideas for improvement**
+## Ideas for improvement
 
 The reason for doing it this way is that you now can reuse your code again and again with only creating the same link on other tables instead of building it from scratch each time reducing testing needed and improving the quality of the overall product.
 
-## **Consequences (When it should not be used)**
+## Consequences (When it should not be used)
 
 This can be used on any table when linking anything to it that can be considered a generic module which can be reused. That said it should not be used in cases where there is a risk of tables growing so much that performance could be impacted. There are ways to reduce performance impact when using high volume tables, but that is outside the scope of this pattern.
 
-## **Related Topics** 
+## Related Topics
 
 This is related to the hook pattern as far as they both try to reduce the footprint changes have on the standard application, by creating reusable ways to interact with the standard code. That said the hook pattern is more about hooking the functionality to existing while this pattern is more about creating reusable ways of creating functionality.
 
-__
-
 
 
 [anchor0]: http://mvp.microsoft.com/en-us/mvp/Soren%20Klemmensen-5001002 "Soren Klemmensen"