An application using DBF files.
Assuming that we use a shared file server for DBF storage, the following data damage happen the most often in the traditional architecture:
1. Inserting nonsense information (a random byte sequence) to a data table or an index. The reason for this may be a damaged workstation, a network card, switching on or off of the station while sending a message.
2. A disturbance of the DBF files consistency with the associated indexes. The reason - a connection break up between an application and a file server after the modification of DBF file and before updating all indexes. A connection break up usually stems from a network damage or disconnecting a workstation or a server form the network or from a damage or switching off of the station.
3. A disturbance of the logical consistency of data. Assuming that the program is written correctly, the consistency disturbance may be the result of a sudden abortion of a running program, which makes the ending of logically related operations impossible (a code part, which realizes dependent changes in data). A sudden abortion of a running program is usually a consequence of a connection abortion between an application and a file server ( the reasons like in point 2).
With the terminal work, the damage of type 1 cannot occur, as the application is not executed physically on a workstation but in DOS window of Windows NT system. Possible problems with a workstation will cause a terminal disconnection, or in the worst case, a distortion of the picture shown on a terminal.
Terminal software has been structured in such a way that executing an application cannot be stopped while the indexes are being updated, which eliminates the possibility of a consistency disturbance of indexes and DBF databases, even when a terminal is suddenly disconnected.
Because of the fact that with the work in terminal architecture data (DBF,NTX) and an application are on the same computer, a connection abortion between an application and the data is practically impossible on a working server. There is one issue left - a connection between an application and a terminal. By default, an application working in terminal mode ends its activity when it finds out that a connection with a terminal has been aborted. It may cause a disturbance of the logical consistency of data. In order to avoid such a possibility, a mechanism of "terminal transactions" has been introduced.
Using additional functions of Terminal package, a programmer can mark in xBase program code fragments which cannot be aborted (Listing 1). If a connection between a terminal and an application is aborted at the moment when the application is in the terminal transaction mode, the fact that there happened a disconnection will be ignored until the end of the transaction. The terminal transaction guarantees a complete execution of a marked application fragment. Correct inserting of terminal transactions to an application eliminates a possibility that a disturbance of the logical consistency of data may occur. Working in terminal architecture and using terminal transactions you can achieve a system stability and the level of data security normally unavailable in traditional installations with a file server.
The transmission between terminals and applications can be encrypted in order to keep the confidentiality of the sent information.
An application using SQL server via Mediator.
Here, apart from terminal transactions, we have access to the database transactions and to all the security mechanisms of SQL database. The level of protection is not worse than in applications written in modern SQL tools.
