▪For input and input/output parameters, parameter can be a literal or a parameter marker. Because some data sources do not accept literal parameter values, be sure that interoperable applications use parameter markers.
▪For output parameters, parameter must be a parameter marker.
If a procedure call includes parameter markers, the application must bind each marker by calling SQLBindParameter() prior to calling the procedure.
Procedure calls do not require input and input/output parameters; however, the following rules apply:
▪A procedure called with parentheses but with parameters omitted, such as {call procedure_name()} may cause the procedure to fail.
▪A procedure called without parentheses, such as {call procedure_name}, returns no parameter values.
▪Input parameters may be omitted. Omitted input or input/output parameters cause the driver to instruct the data source to use the default value of the parameter. As an option, a parameter's default value can be set using the value of the length/indicator buffer bound to the parameter to SQL_DEFAULT_PARAM.
▪When a parameter is omitted, the comma delimiting it from other parameters must be present.
▪Omitted input/output parameters or literal parameter values cause the driver to discard the output value.
▪Omitted parameter markers for a procedure's return value cause the driver to discard the return value.
▪If an application specifies a return value parameter for a procedure that does not return a value, the driver sets the value of the length/indicator buffer bound to the parameter to SQL_NULL_DATA.
To determine if a data source supports procedures, an application calls SQLGetInfo() with the SQL_PROCEDURES information type.
For more information about procedures, see Stored procedures in the solidDB® SQL Guide.