This topic briefly introduces some concepts that are very important in QAB Programming.
Most QA Build programs will update a database at some point. When attempting to update a database it is important to do it in such a way that when updates that are logically dependent on one another are all made simultaneously, so that either all the updates succeed or all fail. Such a group of updates is called a transaction. A simple example might be that in an order processing program the order header record might maintain an order value field based on the total value of the order lines. (Purists would probably object to this, but this type of thing is very common in practice, to avoid the need to have to read all the order lines just to discover the total value of an order.) If the order header and the order line records are not updated in a single transaction two things may go wrong:
In simple QAB programs each procedure body is treated as a transaction. This means the QAB program may have to update several database tables in order to keep the database consistent. If your application needs a transaction that cannot be conveniently handled like this you need to use the Private Database facilty, which allows a transaction to be spread over as many procedure bodies as you need.
Your first QAB programs will probably mainly be interactive - allowing the user to read or update data from the database using dialogs. Later on you will want to produce report programs that send output to a printer, or create a file that can be read by another program such as a Word Processor. You may want to export data from your database into a file that can be sent to a mainframe computer. Finally you may want to use specialised hardware in your programs, for example POS hardware such as a bar code scanner, or non standard displays such as two line operator and customer displays. All these operations are handled in QA Build through printing. A QAB program selects (opens) a particular print device and then uses various types of print procedure bodies to send output to it. Instead of, or as well as, selecting a print device, a program can opt to send output to a file.
Because of the way QAB programs are stored on the database, it is not possible for a complete system to be contained in one QAB program. In fact the maximum compiled size of a QAB program is currently limited to 64K code+data. If you are used to writing C++ or Basic programs this may sound tiny, though in fact it is more than enough for quite a large and complex program that might be many times larger in other languages. One reason QAB programs are small is that the user interface is stored completely separately from the program logic. Another is that the stored QAB program only has to contain the "business logic" of the application - all the executable code is in the QA Build Interpreter and the DP4 libraries it depends on.
However, sooner or later you will probably find that one of your QAB programs breaks the 64K limit, and you will need to modify your program to use one or more overlays. Moving code from your main program into an overlay is quite simple and the operation of the program will be more or less unaffected, because the two parts of the program can share each other's data seamlessly.