If you want to edit an existing database, skip this section.

A contract is typically cloned from an existing, similar contract. The following is how to clone a contract named source1 to sample1.

Start by making a complete copy of the contract directory.

csadmin$ cd /AccelNET
csadmin$ cp -R source1 sample1

Once this has been done, edit /AccelNET/sample1/environ. Set CONF=sample1 at the very least.

The following commands will create the runtime database directory structure.

csadmin$ cd /AccelNET/db
csadmin$ make_db_dir sample1

Next make a postgres contract directory, setup the editing tools environment, and create a default AccelNET database. The following should be executed as the postgres user.

postgres$ cd /AccelNET/pg
postgres$ make_contract sample1
postgres$ make_tools sample1
postgres$ /AccelNET/pg/sys/dbcreate/builddb/dbcreate sample1
postgres$ cd /AccelNET/pg/sample1
postgres$ cp ../source1/senvi .

You should now have the start of an AccelNET database.

After the database has been created, verify that /AccelNET/environ is linked to /AccelNET/sample1/environ and that CONF=sample1 is set in the file. Edit the senvi file to set CONF=sample1 as well. Logout and back in as the postgres user for the changes to take effect.

In order to modify entries in the database, a table or portion of a table must be retrieved from PostgreSQL. To accomplish this task, the fetch command will be used.

postgres$ cd $TOOLS
postgres$ fetch Label

A file called Label.lst containing the LabelRec table is produced. This file may be opened with any unix/linux text editor. Each line of the file contains a single entry of the table. Fields are separated by a vertical tab (|). From this point, fields can be edited and entries may be added.

Updating a table will modify existing and insert new entries. It is usually best to work from a freshly pulled table or to clone from an existing database. Once the changes have been made to the text file, save it and return to the prompt. To update/insert, use the update command from the tools directory.

postgres$ update Label

Watch the output for any errors. Errors can be caused by invalid values, incorrect field positions, or table relation conflicts. If an error occurs on an entry, the update or insertion of that entry will not occur.

Deleting entries can be one of the most frustrating tasks with an AccelNET database. This is due to the nature of using a relational database and currently available tools. A basic knowledge of SQL is required to delete entries. As the postgres user, connect to the database using the psql command.

postgres$ psql sample1

A welcome message should display giving you a list of help commands and a prompt 'sample1=>' waiting for a command.

For this example, we will delete an entry out of the DescRec table. We are going to attempt to delete the entry for label 'FC 01-1' and refname 'PosSC' from the table. This will only match one entry in the DescRec table because of the primary keys set for the table. It is important to know what is going to match your delete request to avoid unwanted removal of entries.

sample1=> DELETE FROM DescRec WHERE Label='FC  01-1' AND RefName='PosSC';

Here is where the trouble will most likely start. The majority of the time, an error will be displayed stating that it cannot delete the entry. This is what is called a trigger. A trigger message will look much like this:

NOTICE: can't delete |FC 01-1|PosSC | it is in use by ChkPoint.CPdesc

A quick glance will tell you that you tried to delete FC 01-1|PosSC and that a reference to it exists in the ChkPoint table. To resolve this, you must delete the reference(s) to the parameter in the ChkPoint table. In addition, pay attention to where you are deleting from. In cases such as the interlock tables (ChkList, ChkPoint, ChkAct, ChkAlarm), related tables may need to be modified to refelect the deletion. See the appendix titled "Resolving PostgreSQL Trigger Errors" for a more in depth look at resolving trigger errors.

The easiest way to find which entry contains the offending parameter is to retreive the table to a text file and perform a search. To exit psql simply type \q and you will be returned to the normal shell prompt. After finding the entries, decide how they should be handled. Some entries, such as those in the crtDCpnt or crtICpnt tables may contain parameters that are still in use. In this case, it is probably best to replace the offending parameter values with NULL|NULL. Another case would be where the parameter is taking up an entry that will no longer be needed. Use psql and a DELETE statement to remove the entry. Again, pay close attention to the statement you use to delete the entry so as not to harm the rest of the table. Once you have removed the offending entries, attempt the original DELETE statement. If all of the offending entries in all of the tables have been removed, the delete will be succesful. Repeat the above process until the delete is succesful.

Once modifications to the database are complete, they need to be converted to a format the runtime system can use. To accomplish this task, the dbconvert command is used. The command dbconvert all will convert all of the tables to the runtime format. Individual tables can be converted by specifying them in the same way fetch and update are called. In general, it is best to use the dbconvert all instead of converting individual tables. This will decrease the chance of not converting a needed table. The speed of current processors is able to do the operations fast enough.

There are a few special cases that require prior preparation for conversion. The first case is with the DescRec table. The DescRec table has flags that allow for M, B, and IncVal to be calculated. To do this calculation, you can use the buildmb all command. The second case is with any Crt table. The Crt tables calculate their location coordinates based on the RecId. This is done using the convertX and convertY commands.

Now that the desired editing has been completed and the database has been converted, the runtime system must be notified of the new changes. There are two scenarios for notifying the runtime system.

The first scenario is the most reliable as well as the easiest. The disadvantage is that the control system must be halted.

The second scenario allows modification of the runtime database without the need to stop the AccelNET clients. Be aware that this method only works on certain tables and fields in the database. As a rule of thumb, this method will not allow addition of new records, changes to primary keys, or changes to fields that are used as pointers.

Here is a fairly complete list of modifiable fields:

To perform this type of modification, the dbmodify command is used as the postgres user. The following is an example using the DescRec table.

postgres$ dbmodify Desc

In addition to the listed fields above, there are a few things to consider. For example, modifications to the interlock and numeric chains will not be evaluated immediately. Modifications will be evaluated when a watched parameter changes value in the ChkPoint or NumPoint table for the chain. It may be helpful to use the cache command within Xcrt to refresh the currently displayed page. This can fix drawing errors while moving icons around the diagramatic display.