Built-In Tables

A set of built-in tables for use by the DB Admin package itself needs to be created in the database being managed. These tables are generated by clicking on the link Update Table Data at the bottom of the DB Admin application screen. Once these tables have been created, they can be customised as required by editing them as regular tables. The links to edit these tables can all be found at the bottom of the DB Admin application screen. In the event of any additions and/or structural alterations to the table set within the database (typically via phpMyAdmin), it is necessary to re-run the Update Table Data link in order to reflect any necessary changes.

Some of the basic features of the built-in tables are described below. This page does not contain an exhaustive description of all table fields. Those that relate to more advanced features will be covered in more detail on the appropriate pages.

dba_table_info

A record is created for every table in the database being managed (including the built-in tables described on this page). Each record contains a number of configuration options for the table, and the self-documentation on the record edit screen will explain most of these. Records can exist for MySQL views and these will be created as and when needed (see Tables).

Special mention should however be made of the parent_table field. One table can be defined as a child of another, the normal scenario being when a MySQL view is generated from a given table. Less often this may take the form of a "child table" (see Tables). The parent_table field is simply a link back to the record for the parent table. When a particular table/view is being processed by the application, the latter will look for necessary configuration data for the table, including that held in the dba_table_fields table (see below). Where information is not available, the application will work backwards via one of more parent table links to find the necessary information. This means that the record field information does not have to be duplicated every time a view or child table is created.

dba_table_fields

This contains configuration details for all fields within all tables in the database being managed (including the built-in tables described on this page). Each record is defined by a table name and field name. The key information held in this table includes the following:-

• A flag to indicate if the field is primary. This is fixed when the table data is first set up and cannot be edited in the DB Admin interface.
• A flag to indicate if the field is required (i.e. NULL not allowed). This is fixed when the table data is first set up and cannot be edited in the DB Admin interface.
• The widget type to be used in a record edit screen. This is set to a default value for the given MySQL field type when the table data is first set up. In certain cases it may be appropriate to change the widget type for a given field (e.g. a simple text field could use a simple input, a text area or a select). In other cases (e.g. date or enum) the widget type must match the MySQL field type. Any attempt to set an invalid widget type for a field will be ignored on saving the record.
• The description field allows for optional information describing the function of the field to be displayed as help information on the record editing screen.
• The vocabulary data enables the input value to be selected from the values of a given field in a given table. For a select widget this information is necessary in order to populate the dropdown list, but vocabulary can also be used to aid auto-fill in a simple text input field.
• A flag is set to indicate whether the given field is to be displayed in a table listing in each of desktop and mobile modes. When the table data is first set up, these flags are set by default for all primary key fields and not set for all other fields. These settings can then be customised as required.

dba_sidebar_config

The DB Admin application screen contains a customisable sidebar to the left containing useful jump links. This is somewhat analogous to the sidebar in Xataface (controlled by conf.ini), though whereas the latter only catered for links to table screens, in DB Admin it is more versatile. The dba_sidebar_config table contains all the information to create the sidebar, with one record per sidebar item. Each sidebar item can be of one of the following types:-

• Perform a given action.
• Open a given table. If a table is opened without an associated action, the list action is assumed by default. It is however possible to define both an action and a table for a given sidebar item in order to open a table with a particular action (the most common example being in the use the new action to create a new table record).
• Run a custom script. The URL has to be in relation to the path to the current page directory in the page hierarchy (i.e. $CustomPagesURL/$RelativePath). A custom script therefore needs to be created in the current page directory, though this can if necessary just contain an automatic redirect to another page.
• Display a label with no link. This is often used to add an HTML <hr> tag to divide the sidebar into logical sections.

dba_relationships

This table is used to define one-to-many relationships between tables with linked record fields within the local database. It is used to specify automatic operations on linked records when a given record is viewed, updated or deleted.

The record fields within this table are as follows:-

dba_change_log

[---Description goes here---]