Disabling Message Chaining

You can choose to disable message chaining. Before you disable message chaining, consider the following situations:

• Some SQL statements require immediate replies. If you disable message chaining, re-enable the OPTMSG feature once the restricted SQL statement completes.
• If you perform debugging, you can disable the OPTMSG feature when you are trying to determine how each SQL statement responds.
• If you enable OPTMSG, the message is queued up for the database server but it is not sent for processing. Consider disabling message chaining before the last SQL statement in the program to ensure that the database server processes all messages before the application exits.
• If you disable message chaining, you must reset the SQL_INFX_ATTR_OPTMSG attribute immediately after the SQL statement that requires it to avoid unintended chaining.

  The following example shows how to disable message chaining by placing the SQL_INFX_ATTR_OPTMSG attribute after the DELETE statement. If you place the attribute after the delete statement, the driver can flush all the queued messages when the next SQL statement executes.

  SQLSetStmtOption(hstmt, SQL_INFX_ATTR_OPTMSG, 1);
  SQLExecDirect(hstmt, (unsigned char *)
  "delete from customer", SQL_NTS);
  SQLSetStmtOption(hstmt, SQL_INFX_ATTR_OPTMSG, 0);
  SQLExecDirect(hstmt, (unsigned char *)
  "create index ix1 on customer (zipcode)", SQL_NTS);

  Unintended message chaining can make it difficult to determine which of the chained statements failed.

  At the CREATE INDEX statement, the driver sends both the DELETE and the CREATE INDEX statements to the database server.