Here are guidelines, tips, and reminders to help you use persistent binding correctly:
A program benefits from persistent binding only if it meets both of these criteria:
It contains at least one Embedded SQL statement that executes more than once, and
That statement uses the same host variables repeatedly to exchange values with SQL Server.
The -p and -b options affect only the file being precompiled, unless that file declares a cursor. If the file declares a cursor, -p and -b affect all statements that use the cursor. In general, you should use both the -p and -b options or use neither. If your program consists of more than one Embedded SQL source file, you should generally use the same combination of the -p and -b options to precompile all the files.
Generally, if you use the same cursor in more than one source file of a program, use the same combination of the -p and -b options when precompiling those files. Otherwise, you will need to understand exactly how different combinations of the options can change which data a statement sends or retrieves.
A program that uses persistent binding should, where practical, execute a single Embedded SQL statement repeatedly instead of executing two or more identical statements once each.
The rules controlling a statement’s bindings differ depending on whether the statement:
Can use persistent binding
Uses a cursor
Is a dynamic SQL statement
Is a fetch statement with the rebind/norebind clause
Bindings never persist beyond the lifetime of a connection. In statements that use a cursor, bindings never persist after the cursor is deallocated.
A dynamic cursor’s declaration controls the binding behavior of all statements that use the cursor. For a static cursor, the statement that most recently opened the cursor exerts this control. A program should open a static cursor only in the source file that declares it.
