An overview of tables

There is a distinction between the table (data definition and data container) and the data (the contents of a table). The table definition describes the identification information, data structure, validation rules, storage, and retrieval of the data that is stored in the table (container). The definition is defined by the design and can only be changed by a developer. The data is the variable content that originates from user actpities. The place where we can see the data explicitly referenced independently of the table as a definition of structure is in the Permissions setup data. In the following screenshot, the data is formally referred to as Table Data:

The table is not the data, it is the definition of data contained in the table. Even so, we commonly refer to both the data and the table as if they were one and the same. That is what we will do in this book.

All permanent data must be stored in a table. All tables are defined by the developer working in the Development Environment. As much as possible, critical system design components should be embedded in the tables. Each table should include the code that controls what happens when records are added, changed, or deleted, as well as how data is validated when records are added or changed. That includes functions to maintain the aspects of referential integrity that are not automatically handled. The table object should also include the functions commonly used to manipulate the table and its data, whether for database maintenance or in support of business logic. In the cases where the business logic is either a modification applied to a standard (out-of-the-box) table or also is used elsewhere in the system, the code should be resident in a function library codeunit and called from the table.

The Table Designer in C/SIDE provides tools for the definition of the data structure within tables. We will explore these capabilities through examples and analysis of the structure of table objects. We find the approach of embedding control and business logic within the table object has a number of advantages:

• Clarity of design
• Centralization of rules for data constraints
• More efficient development of logic
• Increased ease of debugging
• Easier upgrading