The initiated-commands table controls the use of routines that initiate and set up commands to be sent to a server (ct_command, ct_cursor, ct_dynamic, ct_param, and so on). It provides a finer level of enforcement than is possible with the commands table.
For example, the command state machine ensures that ct_param is called only after a command has been initiated. However, it cannot prevent an application from calling ct_param when the initiated command does not take parameters (as in the case of a ct_cursor(CS_CURSOR_CLOSE)). It is in cases like these that the initiated-commands table enforces the logical sequence of calls.
As another example, assume that a Client-Library cursor is declared using the cmd1 CS_COMMAND structure. After the cursor-declare command is sent to the server and the results are processed, the state machine is in the Idle state.
From the Idle state, the command state machine permits an application to initiate a new command. It cannot prevent an application from declaring a second cursor using the same CS_COMMAND structure that it used to declare the first cursor (cmd1).
The Initiated Commands table, however, keeps track of the state of a cursor on a command handle. It recognizes that, if a cursor has been previously declared using a particular CS_COMMAND structure, a second attempt to declare a cursor using the same CS_COMMAND structure is illegal.
See “Initiated commands” for a detailed description of each of the initiated command states. See “Callable routines for initiated commands” for a mapping of initiated command states with Client-Library routines.
