- 10 Jul 2023
- 9 Minutes to read
- Print
- PDF
Define Table Characteristics
- Updated on 10 Jul 2023
- 9 Minutes to read
- Print
- PDF
Creating Table through Form Designer
While creating a Form using Form Designer, a corresponding table is created by default. You can drag and drop the controls to build a form and a corresponding table column is created for the same. It allows you to play with more designing options to provide a better look and feel to your form. You can do it easily with drag and drop interface rather than writing SQL queries
Figure: Create Table Using From Designer
Use Case User Persona: Application Designer | Solution |
ACME requires the app designer, Sam who has no SQL knowledge, to create a form named Employee Leave Request to process employee's leaves. It will allow the employees to request for leaves and to keep a track to planned absence leaves from work. The required controls on the form are as follows:
| For the above requirement, Sam can create the form easily with the help of Form Designer. By default, Employee_Leave_Request table will be created with following columns:
|
Figure: Employee Leave Request Form to Employee_Leave_Request Table
Create Table through Table Designer
Create a table from Table Designer a corresponding Form is created by default. Defined columns of this table are available as fields of the form. In this method you have less options to design the form with respect to look and feel.
Figure: Create Form using Table Designer
Use Case User Persona: Application Designer | Solution |
ACME requires App designer John to add one drop-down field to an already existing Patient Entry Details form as Disease Name drop-down which should display the list of all diseases.* | For the above requirement, John can create a table Diseases_Symptom_Details using Only Table? option in Table Designer, which is just a repository of different type of diseases in ACME, which will not create any form by default. John will create only a table called Diseases_Symptom_Details with the following columns:
The column Disease Name of the Diseases_Symptom_Details table will be the data source for the Disease Name drop-down values on Patient Entry Details form. This table should only be for back-end usage, and no front-end is needed. This table will work as repository. |
Figure: Disease_Symptom_Details Table as data source to Patient Entry Details Form
For every form a table must always exist, but for every table a form may or may not exist.
Extend Multiple Form or Table from a Table
Use Case User Persona: Application Designer | Solution |
Christie, an App designer with SQL background, creates a table called Newincident with the controls (attributes/columns in the table) – Incident, Symptom, Description, Attachment, Username, User ID, Time. The ‘Is Extensible’ option is enabled for Newincident table. Hence, she can reuse the controls (Incident, Symptom, Description, Attachment, Username, User ID, Time) in another Form/Table.* | Christie can create a second form/table named 'Newincidentforuser' and select 'Newincident' from the Extends from Table drop-down option. In this case, Christie has created a form/table with the controls – Incident, Symptom, Description, Attachment, Username. Further, she added controls like Impact, Urgency and Priority. For a third form/table named 'Incident Management’, Christie can select 'Newincident' from the Extends from Table drop-down option and choose the controls – Incident, Symptom, Time & User ID. Further, she can add controls like Assigned, Status and Comments. App designer Christie creates a fourth form/table called ‘IncidentAll’ by selecting 'Newincident' from the Extends from Table drop-down option. Along with the parent controls of Incident, Symptom, Description, Attachment, Username, User ID, Christie adds Location & Duration controls too. |
Figure: New_incident table is extended to create other tables.
Data Types
The data type is an attribute that is associated with a data storage format that can contain a specific type or a range of values. It ensures that data is collected in the preferred format and the value of each property is as expected. It stores data in variables and each variable must be assigned a specific data type.
An enterprise record for an asset may use a string data type for the asset name. Whereas, the asset’s procurement date would be stored in a date format, while the number of assets procured is stored in integer format. Uniformity of data types across multiple records can easily search, sort, and compare fields in different records.
Understanding the Data Types
The following table explains different data types available, along with examples:
Data Type | Description | Example |
---|---|---|
Number Box | It is the most common numeric data type used to store numbers without a fractional component. | The positive, negative, or zero. Any numbers such as -321, 497, 19345, and -976812 are valid integers. |
Text Box | It is a variable-length string data type and holds only the characters that assign to it. | A VARCHAR(100) data type = ‘Jen’, then it would take up 3 bytes (for J, E, and N) plus 2 bytes, or 5 bytes in all. |
Text Area | It is a sequence of characters and the commonly used data type to store text. Additionally, a string can also include digits and symbols, however, it is always treated as text. | The word "mobile" and the phrase "I use mobile for navigation" are both strings. Even "12345" could be considered a string. A phone number is usually stored as a string (+1-999-666-3333) but can also be stored as an integer (9996663333). |
Calendar | Stores a date in the YYYY-MM-DD format (ISO 8601 syntax). | Date values contain either absolute dates and times or time intervals. The valid Inputs formats are: mm/dd/yy mm/dd/yyyy dd-mmm-yyyy mm-dd-yyyy yyyy_mm_dd mmddyy mm-dd mm/dd |
Time | Stores a time in the hh:mm:ss format. Besides the time of the day, it can also be used to store the time elapsed or the time interval between two events which could be more than 24 hours. | The time elapsed since an event took place could be 72+ hours (72:00:59). |
No-Code experience
Prerequisites
User Persona: Application Designer with basic SQL knowledge
Table Designer is a No-Code experience for the app designer and allows for seamless GUI interactions.
The App designer will, however, need to have some SQL knowledge to understand:
- Various data types required for variables in the table
- Understanding data structures to define each row, tuple, column, cell
- Relations between each column
- Properties of the table
- Relation of one table to another
- Dependencies and limitations of the tables.
A company ACME logistics entry database would include a table that describes a customer with columns for name, address, phone number, and so forth. Another table would describe a transaction, including information like the product, customer, date, and destination, price, delivery time, booking dates. A user can get a database report showing the data they need. For example, a branch manager at ACME logistics might want a report on all customers that transported products after a certain date.*
for the above example, App designer Sam, will need some experience in SQL and DBMS to understand the data structure, data types and the various relations between tables to create the table and to come up with the query to extract the information.
Create Table
<
Procedure
As an App Designer, you can flesh out basic information of the table to be built such as:
Enter the table Name.
Provide a brief description.
Select the Application and module to which the table belongs.
Select the table based on which the attributes should reflect in the current table.
Activate or deactivate the table by selecting the Active toggle button.
Select if a default form should be created along with the table
Field | Description |
---|---|
Description | Type in a brief description of this Table. |
Display Name* | This is the name of the table that will be displayed on the page. This name will appear to the user instead of the actual table name. |
Extends From Table | Select the table from the drop-down list. The columns are inherited from the selected table. |
Icon | Icons can be assigned to the form. On clicking the button, a pop up displays all the icons that are available for assigning. |
Is Active? | If selected, this table becomes active. If selected, this table becomes available for the selected module. Disabled tables cannot be used and would not be displayed in other screens. |
Is Extensible? | If enabled, this table becomes extensible and can be reused with the other tables also. Accordingly, the columns of this table can be inherited to a new table and additional columns/fields can be added on top of it. Only those tables for which you have selected, Is Extensible ? as enabled are displayed in the Extends From Table parameter below. If you have disabled the Is Extensible ? for a particular table then those tables are not displayed in the Extends From Table parameter. |
Is Referenceable? | If enabled, then the user can define whether the table created from this form can be referenced in other forms/tables. |
Only Table? | Select if a default form should be created along with the table by toggling the switch. |
Application | Select an Application for the table. Selection of the application in this section defines the rules, workflows, and configuration that the current form will adhere to. You can control and restrict which applications can be visible to users using Role_Templates. Based on the Role_Template assigned to the user, only those modules access is provided for which applications are mapped to the Role_Template. |
Module | Select a module. for which you want to create the table. Modules are defined at an earlier stage. Click here for more information on how to create a module. |
Table Name* | Specify the Table Name. Based on the specified Table name the attributes are appended on the form. All table names will have the short code of the module and additional information that will be prefixed. The prefixes cannot be changed. While you do have an option to change the suffix of the Table Name. For example, a form with the display name of User List under Incident Management module will have an automated Table name “im_d_userlist”. Here “im_d_” is the prefix. Note: Two different forms can have the same Display Name but they will always have unique Table Name. |
View Info | Enter all the parameters that are required to set up/ configure the view |
Sequence Generator
The sequence generator allows you to define a sequence/pattern/format for IDs that are generated automatically for each ticket.
Field Name | Description |
---|---|
Auto Number Required? | Enable this toggle button to define the different code format for the auto-generated IDs. If enabled, the following fields are displayed: Auto Sequence Column Name |
Auto Sequence Column Name | Specify the column name for the auto-generated IDs. Example: Incident ID |
Short Code | Specify the short code for the auto-generated IDs. Example: IM ID |
Code Format | Define the code format for the auto-generated IDs. Accordingly, the system will generate the code for the auto-generated IDs. To define code format, perform the following steps: |
Sequence Length | Type in the numeric sequence for the auto-generated IDs that are generated sequentially for each ticket. |
Starts From | Type in the numeric sequence for the starting numbers of auto-generated IDs that are generated sequentially for each ticket. |
Is Separator Required? | To enable separator, slide is separator required button to the right. If enabled, the phrases in the code format will be separated by a separator. The default separator is a backslash (/). Example: IM/2021/05/24/130994 |
Identity Info
An identity column is a column (also known as a field) in a database table that is made up of values generated by the database. Its values are managed by the server and usually cannot be modified.
Identity columns can be used for generating key values. The identity property on a column guarantees the following:
Each new value is generated based on the current seed & increment.
Each new value for a particular transaction is different from other concurrent transactions on the table.
Field Name | Description |
---|---|
Identity Seed (Mandatory) | Define the identity seed number. The number defined here will be the starting ID of the first row of the table. Identity column generates sequential values for new records using a seed value. The term seed refers to the internal value that the server uses to generate the next value in the sequence. By default, an identity column's first value is 1 and each new value increments by one (1, 2, 3, 4, and so on). Identity Seed is the value that is used for the very first row loaded into the table. Ex: 00001 |
Identity Increment (Mandatory) | Define the identity increment number. The identity numbers are auto-generated in the increment defined here. Example: If the identity increment number is defined as 2, then the 1st row ID will be 00001, the 2nd row ID will be 00003, the 3rd row ID will be 00005, and so on. |
:::