In some third-generation languages, such as C and COBOL, you can place static SQL statements directly into the source code of the host language. This is known as embedded SQL. The DB2 Precompiler can then examine the source code and translate the embedded SQL statements into DB2 calls that the host language compiler understands.

In an ESL application, however, static SQL statements are not embedded in the source code. Instead, they are stored separately from the ESL code in SQL Access Modules, which you create and maintain with DB/Assist.

A SQL Access Module (SAM) contains the static SQL statements and associated ESL variable information for all or part of an ESL application. A SAM consists of a group of related database access functions that can be shared across an entire ESL application.

The action routines and associated variable files created by DB/Assist for a SAM, can be shared by numerous ESL Applications and each ESL Application can use the output from multiple sets of SAMs provided there are no naming clashes with the SQL Statement Names or the variables. For example, if you are building a customer services application, you might create separate SAMs in DB/Assist for inventory, accounts payable, accounts receivable, and customer information. For more information about a recommended methodology for building applications with DB/Assist and Workbench, see Developing Applications with DB/Assist.

After you create a SAM and build the SQL statements in it, DB/Assist performs the following functions to include the SAM in your Workbench project:

•Generates a set of ESL action routines for each valid SQL statement in the SAM.

•Compiles the ESL action routines into the current Workbench project or, if you are running DB/Assist standalone, to a file that you specify.

•Creates a bind file for the SAM and a database access package.