Typically, Client-Library removes the binding between the application’s destination variables and a command after the application has processed the results of the command.
CS_STICKY_BINDS, however, determines whether bindings established by ct_bind persist across repeated executions of a command. If CS_STICKY_BINDS is enabled (CS-TRUE), Client-Library does not remove binds until the application initiates a new command with ct_command, ct_cursor, ct_dynamic, or ct_sendpassthru.
CS_STICKY_BINDS must be set to CS_TRUE before ct_send is called to execute the command whose result bindings will be saved. Once set, the property affects all future command processing on the command structure.
CS_STICKY_BINDS should be set only by applications that repeatedly execute the same command, and only if the result formats returned by the command cannot vary. A command’s result format information consists of a sequence of the following result-set characteristics:
The result type (indicated to the application by the ct_results result_type parameter)
The number of columns available to the application using ct_res_info; applies to fetchable results only.
The format of each column available to the application using ct_descibe for each column; applies to fetchable results only.
If a server command contains conditional logic, it is possible that the format of the results returned by the second and later command executions will not match that of the first execution. In this case, the bindings established in the first execution are cleared automatically by Client-Library. ct_results raises an informational error (and returns CS_SUCCEED) when Client-Library detects a mismatch in the results format.
Applications can reuse binds by setting the CS_STICKY_BINDS command property to CS_TRUE before the command is sent to the server. Applications check the CS_HAVE_BINDS command property to see whether binds have been established for a result set.
For example, suppose an application repeatedly executes the same RPC command to run a stored procedure containing a single select statement. Such an application could use the program logic shown below to re-execute the command and reuse the result bindings:
/*
** Enable persistent result bindings.
*/
ct_cmd_props to set CS_STICKY_BINDS to CS_TRUE
/*
** Initiate the RPC command.
*/
ct_command(CS_RPC_COMMAND, proc_name)
ct_setparam for each parameter
set values in parameter source variables
ct_send
loop while ct_results returns CS_SUCCEED
switch(result_type)
case CS_ROW_RESULT:
ct_bind for each column
loop on ct_fetch
... process row data ...
end loop
case CS_STATUS_RESULT:
ct_bind for the procedure’s return status
loop on ct_fetch
... process the return status value ...
end loop
... other cases...
end switch
end loop
/*
** Change the input parameter values and resend the command.
*/
set values in parameter source variables
ct_send
loop while ct_results returns CS_SUCCEED
switch(result_type)
case CS_ROW_RESULT:
(optional) ct_cmd_props to check CS_HAVE_BINDS
loop on ct_fetch
... process row data ...
end loop
case CS_STATUS_RESULT:
(optional) ct_cmd_props to check CS_HAVE_BINDS
loop on ct_fetch
... process the return status value ...
end loop
... other cases...
end switch
end loop
/*
** Execute a new command. A call to ct_command, ct_cursor, or
** ct_dynamic clears the previous initiated command from the
** command structure.
*/
ct_command
... and so forth ...
If a command returns multiple result sets (for example,
if the stored procedure in the example above contained multiple select statements),
then the results loop logic above would use calls to ct_res_info(CS_CMD_NUMBER) to
distinguish between the different result sets.
When CS_STICKY_BINDS is set to CS_TRUE, there is some internal overhead caused by Client-Library’s need to save and compare result-set formats. Applications that do not repeatedly execute the same command and reuse the result bindings should leave the property at its default setting, FALSE.
CS_STICKY_BINDS does not affect binds established on command structures that control extended error data or notification parameter values. Applications access these command structure as the CS_EED_CMD and CS_NOTIF_CMD connection properties, respectively. Applications must always rebind when fetching from these command structures.
For detailed usage information on the routines mentioned above, see the reference page for each routine in Chapter 3, “Routines”
Applications check the CS_HAVE_BINDS command property to see if any saved binds are established for the current result set. See “Have bindings”, “Resending commands”, and “Restoring a cursor-open command”.
