Every table that is to be accessed by the DB Admin application must have an associated table class, even if this is empty with no methods. For any given table the class name is of the form tables<table name>_. For the built-in tables the classes are defined within the DB Admin package (file classes.php). For all other tables there must be a sub-directory for the given table within the application tables directory and this will contain the PHP script for the table class. The path to this script will be:-

$CustomPagesPath/$RelativePath/tables/<table name>/<table name>.php

This is equivalent to the data structure used in Xataface.

The following methods are available to be defined within a given table class:-

• beforeSave($record) - This is called immediately before a record is due to be saved. It takes a single parameter for an object of the db_record class (see later page). If an error condition is detected the function is required to output an appropriate error message and return the value false. This will then result in the record not being saved.
• afterSave($record) - This is called immediately after a record is saved. It takes a single parameter for an object of the db_record class.
• beforeDelete($record) - This is called immediately before a record is due to be deleted. It takes a single parameter for an object of the db_record class (see later page). If an error condition is detected the function is required to output an appropriate error message and return the value false. This will then result in the record not being deleted.
• afterDelete($record) - This is called immediately after a record is deleted. It takes a single parameter for an object of the db_record class.
• <field name>__validate($record,$value) for a given field - This is called at the same time as beforeSave and is used to validate a given record field. It takes two parameters - an object of the db_record class plus the value of the field being validated. If an error condition is detected the function is required to output an appropriate error message and return the value false. This will then result in the record not being saved.

When a MySQL view is to be created from a given table, the process can often be automated by calling the built-in function create_view_structure. This function runs the required MySQL query to create/replace the view. It will create a symbolic link with the name of the view pointing to the class directory for the parent table. Within this directory it will create a class script file using the name of the view and defining it as a child class of the parent table class. A record for the view will be created in the dba_table_info table with the parent table field pointing back to the parent record. The view should then operate entirely as if it were a table in its own right. Class methods can theoretically be re-defined for the view, because once the child class script has been created, it will not be deleted/re-created by a subsequent call to create_view_structure.

As a matter of convention, views created by this method carry the name prefix _view _ to make them distinguishable.

Child table structures operate in a similar way to view structures although they are used much less often. By calling the function create_child_table_structure, an empty table is created with the same structure as the parent table. This is then linked to the parent table by the same method used for a view structure.

As a matter of convention, tables created by this method carry the name prefix _ctab _ to make them distinguishable.

In order to perform operations on a table, the application needs to be loaded with a URL parameter of the form -table=<table name> A number of standard table operations are available using built in actions. These are as follows:-

• List - This is the default action that is used in the absence of a URL action parameter. The table is listed on the screen with a given number of entries per page. This number is customisable in the_dba_table_info_ table but defaults to 100. There are navigation links to all the pages. The number of entries per page can be dynamically altered. Also there is a search box to narrow the display down to records matching a given search criterion. The display can also be made to sort by a given column by clicking on the head of the column. The editing screen for a given record is accessed by clicking on any of the displayed fields for the record.
• Edit - The editing screen for a record is linked to from the table listing screen (see above). The URL for this includes a record ID parameter, the format of which is described on the next page.
• New - By clicking the button for a new record on the table listing screen, an empty editing screen is displayed, which can be filled and saved.
• Delete - One or more records can be deleted by checking the boxes of the required records in a table listing and clicking the Delete Selected button at the bottom of the page. The application will prompt for confirmation.
• Update - One or more records can be updated by checking the boxes of the required records in a table listing and clicking the Updated Selected button at the bottom of the page. The application will then display an update screen in which one or more fields can be selected and a new value for each specified.
• Update All - The update facility can be applied to all records in the table by clicking the Update All button at the bottom of the page. An update screen similar to the one for "Update Selected" appears, but with the addition of a checkbox to confirm that all records in the table are being updated.
• Copy - One or more records can be copied by checking the boxes of the required records in a table listing and clicking the Copy Selected button at the bottom of the page. A copy screen appears, similar in layout to the update screen. An additional constraint is applied however, in that at least one primary key field must be selected because it is not possible to make a copy of a record with all the same primary key values.