API Implementation and Versions (Magic xpa 3.x)

Magic xpa is a dynamic tool with no compilation or link stages. Magic xpa programs can be executed as soon as an operation is inserted into the proper Magic xpa table. The data views defined in Magic xpa are also dynamic, and can change from one program to another and from one application to another. Magic xpa does not limit the variety of data view.

To provide this versatility with a single rule-based engine, Magic xpa uses dynamic SQL to construct the SQL data view that Magic xpa programs require. Each Magic xpa task that uses SQL tables issues the proper SQL statement to specify the data view needed. The SQL statement is then prepared by the Magic xpa Database Gateway. During this preparatory stage the DBMS optimizer analyzes the statement and prepares it for processing.

Unlike 3GLs and 4GLs that use embedded SQL to eliminate runtime SQL statement parsing and optimization by pre-compilation, Magic xpa does not use compilation. Therefore, the preparation stage may produce additional overhead by executing a task that is repeatedly called. However, if the task is declared resident, the SQL statement is prepared just once and is not released. Repeated calls to the task will use the existing statement instead of preparing a new one. In this case, the performance of Magic xpa’s dynamic SQL implementation is the same as the performance of an embedded SQL program.

For information on Magic xpa Gateways for other databases see:

Oracle – This gateway is written with the Oracle Call Interface (OCI) procedures to achieve maximum capability and performance.

MS-SQL – This gateway is written with the Object Link Embedding DB interface (OLE-DB). For maximum performance it uses client cursors and commands.

DB2 – This gateway is written using the DB2 Call Level Interface (CLI) procedures.