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 4: Seminars
Seminars : There is no standard functionality in Microsoft Dynamics NAV 2013 that handles Seminar Management requirements. You must develop a completely new application area. A standard application area in Microsoft Dynamics NAV 2013 consists of a setup table, master tables and pages, and any necessary subsidiary or supplemental tables with their pages.
The core master record of the Seminar Management functionality is the seminar. All master tables share some common characteristics, and any new master tables that you develop must also have the same functionality.
All master pages are accompanied by a card page and a list page. Both pages provide a similar, intuitive, and consistent functionality that you must also provide in any master pages that you develop.
Setup Table and Page
Setup table is one of the core tables of a application area in Microsoft Dynamics NAV 2013. The setup table provides the settings that define the behavior of the business logic in a specific application area of the application. The business logic frequently depends on various configuration settings. Every time that the code makes a decision about how to handle a specific situation, it must check the appropriate setting in the setup table.
For example, when users post invoices, the business decision may be that the posting is only allowed in a specific period. Instead of hard coding the starting and ending dates in the code, you should add the Allow Posting From and Allow Posting To dates to a setup table. Then you can change the logic of the code to check whether the Posting Date of the invoice falls between the dates that are specified in the table. This makes it easy for users to change the periods of allowed posting. This is exactly how the General Ledger Setup table controls the posting behavior of any kinds of documents that affect the General Ledger application area.
At a minimum, setup tables contain the fields for configuring the number series that control the assignment of numbers to master records, documents, and posted documents of the application area. The more master record and document types, the more fields the setup table contains. There can only be one setup record for a application area. That is why the table has a single primary key field which is called Primary Key.