Restrictions on OPTOFC

With the OPTOFC feature enabled, the following restrictions exist:

You can only use the OPTOFC feature on select cursors whose SELECT statement was prepared. For example, the OPTOFC feature reduces network round trips for the following select cursor:
```
/* Valid select cursor for OPTOFC optimization */
EXEC SQL prepare sel_stmt 'select * from customer';
EXEC SQL declare sel_curs cursor for sel_stmt;
```
The OPTOFC feature eliminates execution of the OPEN statement as a separate step. Therefore, any error conditions that opening the cursor might generate are not returned until after the initial FETCH.
Static cursors are not freed when they are closed.
With the OPTOFC feature enabled, static or dynamic cursors are not freed when they are closed. Because does not actually send the CLOSE statement to the database server, a cursor is not implicitly freed. A subsequent OPEN and FETCH on a cursor actually opens the same cursor. Only at this time would the database server notice if the table was modified (if it was dropped, altered, or renamed), in which case it generates an error (-710).
With the OPTOFC feature disabled, a static cursor is freed when it is closed. When ESQL/C reaches a CLOSE statement for a static cursor, it actually sends a message to close the cursor and free memory associated with this cursor. However, dynamic cursors are not implicitly freed when they are closed.
The GET DIAGNOSTICS statement does not work for SQL statements that are delayed on the way to the database server. For example, in the following sequence of SQL statements, GET DIAGNOSTICS returns 0, indicating success, even though the OPEN is delayed until the first fetch:
```
EXEC SQL declare curs1 ...;
EXEC SQL open curs1
EXEC SQL get diagnostic
EXEC SQL fetch curs1
```