Processing ESQL

---

The following sections discuss preprocessing and processing ESQL.

Preprocessing - the ESQL Command

An application program containing ESQL statements must first be preprocessed using the ESQL command before it can be passed through the host language compiler, since the host language itself does not recognize the ESQL syntax.

Preprocessors are available for the host languages supported on each platform, see Host Languages.

The input to the preprocessor is thus a source code file containing host language statements and ESQL statements.

The output from the preprocessor is a source code file in the same host language, with the ESQL statements converted to source code data assignment statements and subroutine calls that pass the SQL statements to the Mimer SQL database manager.

The original ESQL statements are retained as comments in the output file, to help in understanding the program if a source code debugger is used.

The output from the preprocessor is human-readable source code, still retaining a large part of the structure and layout of the original program, which is used as input to the appropriate host language compiler to produce object code.

The default file extensions for preprocessor input and output files depend on the host language used and are shown in the table below:

Language	Input file extension	Output file extension
C	.ec	.c
COBOL	.eco	.cob
FORTRAN	.efo	.for

Invoking the ESQL Preprocessor

You invoke the ESQL preprocessor with the following command:

 $ esql language [flagger] [options] input-file [output-file]

Language Flags

UNIX-style	VMS-style	Function
-c	/C	Indicates that the input file is written using the C/C++ host language.
-cob(ol)	/COBOL	Indicates that the input file is written using the COBOL host language.
-for(tran)	/FORTRAN	Indicates that the input file is written using the FORTRAN host language.

Flagger Flags

UNIX-style	VMS-style	Function
-e(ntry)	/ENTRY	Ensures that all SQL statements which are beyond the bounds of the entry level SQL-92 standard will generate a preprocessor warning and will be flagged with a warning comment in the output file.
-t(ransitional)	/TRANSITIONAL	Ensures that all SQL statements which are beyond the bounds of the transitional SQL-92 standard will generate a preprocessor warning and will be flagged with a warning comment in the output file.
-i(ntermediate)	/INTERMEDIATE	Ensures that all SQL statements which are beyond the bounds of the intermediate level SQL-92 standard will generate a preprocessor warning and will be flagged with a warning comment in the output file.
-f(ull)	/FULL	Ensures that all SQL statements which are beyond the bounds of the full level SQL-92 standard will generate a preprocessor warning and will be flagged with a warning comment in the output file.

Options Flags

UNIX-style	VMS-style	Function
-s(ilent)	/SILENT	Suppresses the display of the copyright message and input file name on the screen (warnings and errors are always displayed on the screen).
-l(ine)	/LINE	Generates #line preprocessing directives for source written in the C language. These force the C compiler to produce diagnostic messages with line numbers relating to the input C source code rather than the code generated by the preprocessor (and thus compiled by the C compiler).

Input-file and Output-file Flags

UNIX-style	VMS-style	Function
filename	filename	The input-file containing the source code to be preprocessed. If no file extension is specified, the appropriate file extension for the source language is assumed (previously described in this section).
filename	/OUTPUT=filename	The output-file which will contain the compiler source code generated by the preprocessor. If not specified, the output file will have the same name as the input file, but with the appropriate default output file extension (previously described in this section).

Note: As an application programmer, you should never attempt to directly modify the output from the preprocessor.

Any changes that may be required in a program should be introduced into the original ESQL source code. Mimer Information Technology AB cannot accept any responsibility for the consequences of modifications to the preprocessed code.

Example

The following example, on OpenVMS, shows how to preprocess the DSQLSAMP program:

 $ ESQL/C MIMEXAMPLES9:DSQL

What Does the Preprocessor Do?

The preprocessor checks the syntax and to some extent the semantics of the ESQL statements, see Handling Errors and Exceptions for a more detailed discussion of how errors are handled). Syntactically invalid statements cannot be preprocessed and the source code must be corrected.

The preprocessor also places comments in the generated output to indicate the SQL2 standard conformance level for each SQL statement (entry-level, transitional, intermediate or full).

If a flagger option, see the table above, has been specified, then an SQL statement that is beyond the bounds of the specified conformance level is flagged with a warning comment in the preprocessor output and a warning on the screen. Mimer SQL extensions are always flagged with a warning comment and generate a preprocessor warning.

Processing ESQL - the Compiler

The output from the ESQL preprocessor is compiled in the usual way using the appropriate host language compiler, and linked with the appropriate routine libraries.

UNIX: On UNIX platforms, the vendors' common C compilers are supported. On Linux this is gcc.

VMS: The following compilers (all sold by Hewlett-Packard) are supported on the OpenVMS platform: DEC C DEC FORTRAN DEC COBOL Note: For COBOL, the source program must be formatted according to the ANSI rules. Use the /ANSI option when compiling the resulting COBOL program.

Win: On Windows platforms, the C compiler identified by the cc symbol in the file .\dev\makefile.mak below the installation directory is supported.

Note: Other compilers, from other software distributors, may or may not be able to compile the ESQL preprocessor output. Mimer Information Technology cannot guarantee the result of using a compiler that is not supported.

The SQL Compiler

At run-time, database management requests are passed to the SQL compiler responsible for implementing the SQL functions in the application program.

The SQL compiler performs two functions:

• It checks SQL statements semantically against the data dictionary.
• It optimizes operations performed against the database (i.e. internal routines determine the most efficient way to execute the SQL request, with regard to the existence of secondary indexes and the number of rows in the tables addressed by the statement). You, as a programmer, do not need to worry, for instance, about the order in which tables are addressed in a complex selection condition. This optimization process is completely transparent.

Note: Since all SQL statements are compiled at run-time, there can be no conflict between the state of the database at the times of compilation and execution. Moreover, the execution of SQL statements is always optimized with reference to the current state of the database.

Mimer Information Technology AB Voice: +46 18 780 92 00 Fax: +46 18 780 92 40 info@mimer.se