Before you begin compiling, testing, and executing your OpenESQL code, consider what you want OpenESQL to do for you:
- Only to embed SQL into the generated code
- To have OpenESQL simply embed SQL into the generated code, no compiler directive options are required. This is the default behavior.
- To manage the application using SQL Server stored procedures
- For OpenESQL to manage your application using SQL Server stored procedures for your applicable SQL statements, specify either the ACCESS or BIND SQL compiler directive option.
The following table provides a quick reference to the SQL compiler directive options that affect code generation. For complete information on each, see the appropriate
Reference topic.
| SQL Compiler Directive Option
|
Generation Specifics
|
Advantages
|
| None (default)
|
SQL remains embedded in object code
|
Simplicity
|
| ACCESS
|
Creates a stored procedure at compile time for most static SQL statements
|
Convenient for testing when the BIND SQL compiler directive option is to be used for deployment.
|
| BIND
|
Enables deployment of application code by generating an SQL batch script that can be used with
sqlcmd or SQL Server Management Studio to update the SQL Server database.
|
- Security can be applied separately to procedures and data so that application users can only access and update data via the application.
- DBAs can review SQL that is to be deployed without having to access source code.
|
