The only trigger that should be encountered while attempting to delete from the LabelRec table is one that refers to the DescRec table. Because the Label field of a DescRec entry validates with the LabelRec table, one must remove all entries referencing the label you wish to delete. If you were renaming a label, you probably updated the LabelRec table and used fetch and update to rename the DescRec entries. By doing this, the DescRec table creates new entries for the Label/RefName pair, leaving the old ones intacted. For example, we want to delete FC 01-2 because the Faraday cup was removed from the system, or simply was named incorrectly.

First an attempt would be made to delete the cup.

  sample1=> DELETE FROM LabelRec WHERE Label='FC  01-2';
  
  NOTICE:  can't delete |FC  01-1| it is in use by DescRec.Label
  DELETE 0
  

As you can see, a trigger was hit in the Label field of the DescRec table. Since we don't want this label at all, delete it from the DescRec table. Attempt to delete from the LabelRec table again as well.

  sample1=> DELETE FROM DescRec WHERE Label='FC  01-2';
  DELETE 7

  sample1=> DELETE FROM LabelRec WHERE Label='FC  01-2';
  DELETE 1

The delete was successful since the trigger has been satisfied.

There is one other variation that may occur. That is, the label might be used in the logical link Label/RefName in the DescRec table. In this case, use fetch and update to modify the logical link to another parameter or set the values to NULL.

When deleting entries in the DescRec table, a number of triggers may need to be handled. Logical links to other DescRec entries is one of them. As described in the LabelRec section of this appendix, use fetch and update to modify the logical link to another parameters or set the values to NULL.

Another common trigger is with the CrtFixed table. In general, entries in the CrtFixed table pointing to the DescRec entry you wish to delete are no longer needed. Use a SQL delete command to delete these records.

CrtDCpnt and CrtICpnt table triggers are more involved. These two tables can have entries that point to more than just a single DescRec entry. Because of this, care must be taken to remedy the trigger. First, use the fetch to identify the entry that reference the DescRec entry. Look at each entry and determine if any other DescRec entries will be affected by the deletion of the entry in the Crt table. If no other DescRec entries will be affected, it is safe to delete the record. If other DescRec entries are affected, the typical action is to set the Label/RefName in the offending Crt table entry to NULL.

Triggers may also be caused by the NumList or NumPoint tables. If a trigger is with the NumList table, it is most likely the case that one wants to delete the numeric chain. To do this, find the NumList entry corresponding to the DescRec you wish to delete. Use the RecId from the NumList table to remove based on the MrecId in the NumPoint table. Then remove the NumList entry using the same RecId.

  sample1=> DELETE FROM NumPoint WHERE MrecId=112;
  DELETE 3

  sample1=> DELETE FROM NumList WHERE RecId=112;
  DELETE 1

If the offending record is simply a NumPoint entry, more steps must be taken. Since the NumPoint table relies on sequential RecId numbers to function properly, removing a RecId in the middle of a chain causes a need to shuffle the RecId numbers up. For example, the Label/RefName we want to delete from DescRec is RecId 3 in a list of five NumPoint actions. If the NumPoint record is deleted from the table, a sequence of 1,2,4,5 is left. This is not acceptable. To correct this, change the RecId of the fourth entry to 3, and the fifth entry to 4. After a fetch to verify your changes, you will notice that you now have 1,2,3,4,5 again, with 4 and 5 being identical. Delete the fifth record. Attempt the delete on the DescRec entry again.

Much like the triggers from the numeric chains, the triggers for the interlock chains can require extra steps. The same principles apply to deleting an entire chain. Perform a delete based on the RecId from ChkList, using MrecId in ChkPoint, ChkAct, and ChkAlarm. Then perform the delete based on the RecId in ChkList itself.

If the offending record is an entry in ChkPoint, remove and shuffle the RecId as was described for the NumPoint table. After shuffling the RecIds, correct the Offset values for the entries to remove the dead space left by the deleted entry. For example, the previous chain had 5 checks, each of them containing a single bit of offset. The third check was deleted. The offsets of the old RecId 4 and 5 (new RecId 3 and 4) should be changed to 2 and 3 repectively. In addition, the Mask and Mask2 fields in the ChkAct and ChkAlarm tables must be updated to reflect the deletion of the ChkPoint entry.

The DataRec table triggers are similar to those of the LabelRec in that it will only conflict with DescRec entries. To remedy this trigger, redirect any DescRec entries that point to the Addr of the DataRec you wish to delete. A common practice is to use the fetch command with a modified .pqry to extract only the DescRec entries that point to the Addr you wish to delete. Edit the fetched file and set the Addr to 0. This points the DescRec entries to a NULL DataRec. Use the update command to push the changes back to the database. Perform your delete statement again.

The MsgKeys table can run into problems when deleting from two types of triggers. The first type will be caused by the MsgTbl table. The second caused by the DescRec table.

It is assumed you wish to remove a message completely and are not attempting to rename a message list. To handle the MsgTbl, simply perform a delete statement on the table name in the MsgTbl table. For example, one might have created a UserSR message for a custom status read that is no longer used. In this case, the following should be done.

  sample1=> DELETE FROM MsgTbl WHERE MGown='UserSR';
  DELETE 2

  sample1=> DELETE FROM MsgKeys WHERE MsgNme='UserSR';
  DELETE 1

The message list may still be in use by a DescRec entry, preventing deletion. If the DescRec entry is no longer needed, delete it. Otherwise, use the fetch and update commands to point the record to a different message list.

Other triggers exist that one may run into. For example, triggers when working with the wiring tables may occur. The previous sections should give you enough information to get you started with handling them. After working with the database, it will become easier to make an informed decision on how to handle a situation. Always be aware of the structure and intertable relationships when modifying the database.