Module 1: DATA AND PROCESS MODEL
Module 2: MASTER TABLES AND PAGES
Module 3: DOCUMENTS
Module 4: POSTING
Module 5: FEATURE INTEGRATION
Module 6: REPORTING
Module 7: STATISTICS
Module 8: DIMENSIONS
Module 9: ROLE TAILORING
Module 10: INTERFACES
Module 11: WEB SERVICES
Module 12: TESTING AND DEBUGGING
Module 13: SQL SERVER OPTIMIZATION
- Lesson 1: SQL Server for Microsoft Dynamics NAV
- Lesson 2: Representation of NAV Tables and Indexes in SQL Server
- Lesson 3: Collation Options
- Lesson 4: SQL Server Query Optimizer
- Lesson 5: SQL Server Query Optimizer
- Lesson 6: Data Access Redesign
- Lesson 7: C/AL Database Functions and Performance on SQL Server
- Lesson 8: Bulk Inserts
- Lesson 9: Locking, Blocking, and Deadlocks
- Lesson 10: SIFT Data Storage in SQL Server
- Lesson 11: SQL Server Profiler
Lesson 2: Standard Data Model
Standard Data Model
Every application area in Microsoft Dynamics NAV follows the same principles and has a similar data model. Master, subsidiary, document tables, journal, ledger, and other tables all have the same role. There are certain patterns that are applied consistently across all application areas.
Depending on their types, there are certain code patterns that you can follow in all tables of the same type.
The consistency of data model and data flow patterns is important for both users and developers. When users master one application area and understand data model principles, they can also quickly understand other application areas. As a developer, when you understand the principles of data models and patterns, you can customize the standard application. You can also build new application areas and maintain a consistent experience in the standard application. This makes sure that users are as productive as possible.
Typical Data Triggers
In addition to maintaining data validity through data types and table relationships, Microsoft Dynamics NAV also contains data-related business logic. This makes sure that more complex data-related business rules are consistently applied as users insert, change, or delete information in the database.
These complex business rules are coded in table triggers as C/AL code. You can find the same patterns of code in the same types of tables, regardless of the application area where they belong.You must understand these principles, and make sure that the code that you write in the existing objects does not violate those principles. You must also apply the same principles when you create completely new application areas.
This table trigger executes when a user inserts a new record into a table. The code in the trigger executes before the record is actually inserted into the table. If the code in the trigger causes a run-time error to occur, then the insert operation is canceled.