formatted nav patterns

content/NAVPatterns/1-patterns/read-once-initialization-and-validation/index.md

@@ -4,13 +4,11 @@ weight = 970
 +++
 _By Tim Grant_
 
-## **Abstract**
+## Abstract
 
 One time query and validation of a setup table. 
 
-****
-
-## **Description**
+## Description
 
 Firstly identifies if a setup table record is in memory, removing the need to execute and validate the re-query again within a code unit. (From NAV 2013+ service tier database caching exists).
 
@@ -18,7 +16,7 @@ If you need to query a setup table, but not sure if the table is yet in memory f
 
 Allows a central function to validate critical fields before processing automated code. **TESTFIELD** calls are added to the function and not the INIT call in order to ensure that critical functions do not run without this human check in place as these may rely on key configuration. If you have a design where specific field values are critical (custom or standard) for integrity, then INIT INSERT is a dangerous default which could result in the corruption of processes. This is separate automated INIT INSERT from a setup page.
 
-## **NAV Specific Example**
+## NAV Specific Example
 
 A global variable record and a global status indicator, but within the context of a local function.
 
@@ -28,7 +26,7 @@ A global variable record and a global status indicator, but within the context o
 
 ![ ][image2]
 
-## **NAV Usages**
+## NAV Usages
 
 A similar example of this is in Codeunit 80, but without any validation. 
 
@@ -40,9 +38,7 @@ E.g. If there is a bespoke change, then this existing **GetGLSetup** can be call
 
 This means that by the time the code reaches the original **GetGLSetup** code requirement, this record is already in memory as the status flag is set to True, eliminating another check. For such Patterns the setup record should never be cleared, it should be called once globally, initiated and left in memory for future checks. It should **not** be declared locally at the same time, review your code for matching local variable usage before implementing this.
 
-****
-
-## **Ideas for improvement**
+## Ideas for improvement
 
 Merge **Singleton Table** with dynamic validation field meta configuration. This removes the coding of **TESTFIELD** to a central setup check.
 
@@ -54,13 +50,11 @@ Example with the **Sales & Receivables Setup**
 
 [![ ][image7]][anchor7]
 
-****
-
-## **Consequences**
+## Consequences
 
 If in the circumstance that a field value in the setup table is expected to change within the life of the code component instance. e.g. If a CHANGECOMPANY is required to cross reference another Setup table, use a separate variable.
 
-## **Related Topics**
+## Related Topics
 
 This is related to the **Singleton Table** pattern.