In the database, transaction commit, as well as request-level and transaction-level abort for an array request matches the equivalent multi-statement request. Transaction semantics are the same for emulated and non-emulated parameter array requests. The entire parameter array request is rolled back, including those parameter rows already processed.
Errors are handled exactly the same as they would be for the equivalent multi-statement request. The error information returned from the database to the client in the resulting failure parcel matches that from the unfolded request, and the parameter set that generated the failure is identified by the statement number in the failure parcel.
If an error occurs while executing a parameter array statement, the execution function returns an error and sets the row number variable to the number of the row containing the error. It is data source-specific whether all rows except the error set execute or all rows before (but not after) the error set execute. In case of an error, ODBC Driver for Teradata always fails the whole parameter array request.
If an error occurs, the statement number in the failure parcel is used to derive the row number of the failing parameter set and to set the corresponding SQL_DIAG_ROW_NUMBER field of the diagnostic record.
The SQL_DIAG_COLUMN_NUMBER field of the diagnostic record is set by the driver to SQL_COLUMN_NUMBER_UNKNOWN because the driver cannot determine the parameter number for the failure.
The buffer specified by the SQL_ATTR_PARAMS_PROCESSED_PTR statement attribute is set to the number of the failed parameter set.