Coding Requirements for Embedded SQL Programs
The following sections describe coding requirements for writing embedded SQL programs.
Comments Embedded in C Output
Each embedded SQL statement generates one comment and few lines of C code. You may find that the preprocessor translates 50 lines of embedded SQL into 200 lines of C. This can confuse you if you are trying to debug the original source code. To facilitate debugging, a comment corresponding to the original embedded SQL source precedes each group of C statements associated with a particular statement. (Note that a comment precedes only executable embedded SQL statements.) Each comment is one line long and informs the reader of the file name line number and the type of statement in the original sources file.
The ‑# flag to the esqlc command makes the C comment a C compiler directive, causing any error messages generated by the C compiler to refer to the original file and line number; this can be useful in some cases.
One consequence of the generated comment is that you cannot comment out embedded statements by putting the opening comment delimiter on an earlier line. You have to put the delimiter on the same line, before the exec word, to cause the preprocessor to treat the complete statement as a C comment.
How Statements are Embedded Inside C If Blocks
As previously mentioned, the preprocessor can produce several C statements for a single embedded SQL statement. However, all of the statements that the preprocessor generates are delimited by left and right braces, composing a C block. Thus the statement:
if (!dba)
exec sql select passwd
into :passwd
from security
where usrname = :userid;
exec sql select passwd
into :passwd
from security
where usrname = :userid;
produces legal C code, even though the SQL select statement produces more than one C statement. However, two or more embedded SQL statements generate multiple C blocks, so you must delimit them yourself, just as you delimit two C statements in a single if block.
For example:
if (!dba)
{
exec frs message 'Confirming your user id';
exec sql select passwd
into :passwd
from security
where usrname = :userid;
}
{
exec frs message 'Confirming your user id';
exec sql select passwd
into :passwd
from security
where usrname = :userid;
}
VMS: Because the preprocessor generates a C block for every embedded SQL statement, the VAX C compiler may generate the Internal Table Overflow error when a single procedure has a very large number of embedded SQL statements and local variables. You can correct this problem by splitting the file or procedure into smaller components. 
Embedded SQL Statements that Do Not Generate Code
The following embedded SQL declarative statements do not generate any C code:
declare cursor
declare table
declare statement
whenever
These statements must not contain labels and must not be coded as the only statements in C constructs that do not allow null statements. For example, coding a declare cursor statement as the only statement in a C if statement not bounded by left and right braces causes compiler errors:
if (using_database)
exec sql declare empcsr cursor for
select ename from employee;
else
printf("You have not accessed the database.\n");
exec sql declare empcsr cursor for
select ename from employee;
else
printf("You have not accessed the database.\n");
The preprocessor generates the code:
if (using_database)
else
printf("You have not accessed the database.\n");
else
printf("You have not accessed the database.\n");
This is an illegal use of the C else clause.
Last modified date: 08/28/2024