If the last key component of the main table is a number, the auto increment feature of QA Build can provide a default value for creating new records:
For other tables QAB generates the auto-increment number itself. It uses a value one higher than the key of the last record in the table where all the other keys (if any) match the current values. If there is no such record the lowest valid value is used.
This type of processing can be very useful. For example in an order entry program, you would make the order table (with a single part key consisting of just the order number) a MAKEDB auto-increment table. Then the DP4 database manager that each user will get a different order number for adding a new order (whereas if you relied on QAB auto-incrementing all users would get the same number and suffer from contention problems). The order lines would be keyed on order number and line number and would not be a MAKEDB auto-increment table. QAB auto-incrementing will then number the lines within each order starting from 1 (assuming you set the low value for the line keyfield to 1 in MAKEDB). Assuming your system is designed to allow only one user to work on an order at once, then there is no need for the contention avoiding benefits of a "real" auto-increment table. Also, if you did use a real auto-increment table, the line numbers would not start from 1 for each order, but would be unique across the whole database.
Enable this option to use auto-incrementing as described above.
Enabling this option forces the user either to enter the number of an existing record or set up a new record using the auto-increment number.
Normally enable this option to ensure (for MAKEDB auto-increment tables at least) that no two users can attempt to create a record with the same key.
If required, set up a message using the Message Assignment menu that is displayed for display when the user enters a number that is not the auto-incremented number nor the key of an existing record.
There are some problems with using genuine auto-increment tables if applications are going to be run in a resilient configuration with more than one server. It is impossible to maintain a guaranteed consistent auto-increment numbers across the whole system because of the possibility of network failures of various types, and some changes are required to make the numbers work at all in a desirable way. A common solution is to change the key of tables that you would like to be auto-increment. For example instead of keying the order table just on an order number you might key it on a ws_id (denoting a unique code for the computer where the order was generated), and then ws_id_order number. Now QAB auto-increment can keep order numbers unique. For environments that use split servers, this facility may not work as expected. Please consult the network and resilience documentation.