Purpose and scope
The table_ops form is simply a means of doing explicit manual update
of any of the underlying views or forms. Row creation, modification,
deletion and fuzzy search (as in single_ops) are offered. Note however
that each interaction is a single transaction, so the form cannot be
used to build up complex arrangements atomically or to defer deferable
constraints.
At the top of the form is a pop-up menu with a button for selecting the table (aka object type) to be addressed. The fields displayed below that depend on what was thus selected. There is one such field for each column of the table (aka attribute of the object). The field(s) comprising the primary key are marked with asterisk(s) (*).
The "create" function
This causes insertion of a new row into the table. It is your
responsibility to ensure that the fields are correctly specified.
The specified update_date and updated_by are (of course) ignored,
being supplied automatically.
The "modify" function
This causes an existing row to be updated. Start by getting the row displayed, then overwrite the fields as required, then finally press the button. There is no a priori bar on changing the primary key. (The row for update is referenced from a hidden field, set when the row is displayed.)
The "destroy" function
This causes the displayed row to be deleted from the table.
The "fetch*" function
This causes the row identified by the contents of the primary key field(s) to be displayed.
The "search" function
This function can be use to find a row by fuzzy matching of
any of the fields. All displayed fields, even the updated_x fields,
can contribute to the match. Blank fields are ignored. (The
"clear form" button may be of use.) Fields that are not
blank are matched using SQL match semantics (the LIKE function), where
the whole field must be specified but % denotes any string and _
denotes any single character. Matching is insensitive to case. The
search picks out registrations for which all (non-empty)
fields match.
[Experimental] There is an exception to the above, which would not have been particularly useful in the case of the (ubiquitous) review_date field. Here the more useful semantic of testing for not greater is adopted, and the special denotation "today" is acceptable.
The first matching entry, if any, is displayed, and if the search throws up more than one match then a pop-up menu of primary keys for rows that fitted is offered, together with a button for causing the selected entry to be displayed. The pop-up does not survive into the next display of the form. If you want to re-use it then you will have to use the browser's "back" button.
The "history*" function
This displays as plain text the update history of the row displayed in the main fields. More strictly, it selects from the related history table/view those rows that carry the same thread id as the one in the main display.
The "history search" function
Whilst "history" is appropriate for looking at the history of a current item, even though its primary key may have changed in the course of history, it is notably useless after the item has been deleted. "history search" on the other hand, searches the history table for fuzzy matches as described under the "search" function, displaying all matches. It is thus useful against deleted items, but on the down side it will pick up any unrelated matches as well.