The embedded SQL include statement provides a means to include external files in your program's source code. Its syntax is:

where filename is a quoted string constant specifying a file name, or a system environment variable (Linux) that points to the file name. If you do not give an extension to the filename (or to the file name pointed at by the environment variable), the default C input file extension .sc is assumed.

This statement is normally used to include variable declarations, although it is not restricted to such use. For more details on the include statement, see the SQL Reference Guide.

The included file is preprocessed and an output file with the same name but with the default output extension .c is generated. You can override this default output extension with the ‑o.ext flag on the command line. The reference in the original source file to the included file is translated in the output file to the specified include output file. If the ‑o flag is used (without an extension), then the output file is not generated for the include statement. This is useful for program libraries that are using make dependencies.

If you use both the ‑o.ext and the ‑o flags, then the preprocessor generates the specified extension for the translated include statements in the program but does not generate new output files for the statements.

For example, assuming that no overriding output extension is explicitly given on the command line. The embedded SQL statement:

is preprocessed to the C statement:

The employee.dcl file is translated into the C file employee.c.

As another example, assume that a source file called inputfile contains the following include statement:

The name MYDECLS can be defined as a system environment variable pointing to the file c/dev/headers/myvars.sc by means of the following command at the system level:

Because the extension .sc is the default input extension for embedded SQL include files, you do not need to specify it when defining an environment variable for the file.

Assume now that inputfile is preprocessed with the command:

The command line specifies .h as the output file extension for include files. As the file is preprocessed, the include statement shown earlier is translated into the C statement:

The C file c:\dev\headers\myvars.h is generated as output for the original include file, c:\dev\headers\myvars.sc.

You can also specify include files with a relative path. For example, if you preprocess the file c:\dev\mysource\myfile.sc. the embedded SQL statement:

is preprocessed to the C statement:

The C file c:\dev\headers\myvars.c is generated as output for the original include file, c:\dev\headers\myvars.sc.

The name MYDECLS can be defined as a system environment variable pointing to the file /dev/headers/myvars.sc by means of the following command at the system level:

Because the extension .sc is the default input extension for embedded SQL include files, you do not need to specify it when defining an environment variable for the file.

Assume now that inputfile is preprocessed with the command:

The command line specifies .h as the output file extension for include files. As the file is preprocessed, the include statement shown earlier is translated into the C statement:

The C file /dev/headers/myvars.h is generated as output for the original include file, /dev/headers/myvars.sc.

You can also specify include files with a relative path. For example, if you preprocess the file /dev/mysource/myfile.sc. the embedded SQL statement:

is preprocessed to the C statement:

The C file /dev/headers/myvars.c is generated as output for the original include file, /dev/headers/myvars.sc.

Some embedded SQL statements generate labels in the output code. If you include a file containing such statements, you must be careful to include the file only once in a given C scope. Otherwise, you may find that the compiler later complains that the generated labels are defined more than once in that scope.

The statements that generate labels are the select statement and all the embedded SQL/Forms block-type statements, such as display and unloadtable.