Ariadne - Technical description

Description

Very often, control is forwarded from one form to another, and sometimes back again. In this forwarding of control, parameters are passed from the calling Form to the called form. Example, the Entries per event form calls the Persons form in order to select a person as participant. The selected person-id is then returned to the Entries form.

The parameter passing so far has been realized by global variables. A number of global variables is introduced to accomodate the required parameter types. So far (Ariadne 4.10) the calling form directly calls the requested form, after having set the global variables as transaction parameters. In the meantime, transactions between forms getting more complex and this requires more global variables for parameter passing. At this point the need has evolved to introduce an intermediate function which manages the transactions between forms and reports. This is what a transaction server does.

The transaction server introduced in Ariadne 4.20 is of a very, very simple type. It does not support multi threading, it does not support queing, and it does not support address translation. (i.e. make a difference between the functional (if you will 'logical') name of a form and the technical name of the form. Address translation makes redirection of transactions possible). In future these functionalities may be developed, or an real transacion server / message server may be introduced.

The Simple Transaction Server (STS) consists in the definition of the next global variables:

Having one set of global transaction parameters may pose problems when more transactions occur at the same time. Normally however, transactions between forms in the Access database are conducted in a sequential manner.

Care has to be taken that multiple forms can be open at the same time, and the order in which forms are closed need not be the reverse of the order in which they were opened. For this reason forms should only react to transactions which were adressed to them by the TS_To parameter. Further, transaction parameters can only be trusted during the transaction. If you need to keep the value of the requesting form (TS_From), or the value of the ObjectId, you need to temporally store these in the called form.

At this moment the values and their meaning of the TS_Action types are not standardized. You can find values as 'select', 'display', 'new', 'requery'. These values have only bilaterally meaning between the forms using these.

So far there is no function which translates the name of the called form (in the TS_To parameter) to the call command (docmd.openform "form name"). This means that the call command still has to be issued from the calling form. So is a name of a formchanges, you have to change this in all the calling forms. The reason not to use address translation instead is that this involves database interaction for address translation in transaction passing. Before making this step, the effects on performance need to be investigated.

The global transaction parameters are defined in P000-Initialization:

Change history