When errors occur in a batch, only last one is visible, masking the original cause of the failure

When batch execution fails, we usually want to see the first failed statement. The subsequent failures can be caused by the first one, but in the exception thrown the (irrelevant) information of only the last failure is available.

Note the following line:

https://github.com/microsoft/mssql-jdbc/blob/05ef7c07d184e9f8b659c351f68599b1a94132e3/src/main/java/com/microsoft/sqlserver/jdbc/SQLServerStatement.java#L1879

Our scenario:

1. We are using SET IDENTITY_INSERT .. ON in one batch with INSERTs to fill a table with IDENTITY fields.
2. Insertions fails somewhere in the middle of the batch because of constraint violation.
3. But what we see in exception is “Cannot insert explicit value for identity column”, which has nothing to do with the real cause of the error.

Can we change the logic of error handling so that the first failure in the batch is saved and is used when building BatchUpdateException?

[Jeffery-Wasty]

@inponomarev

I initially thought to move this to our backlog, and consider it again in the future, but on further thought, this doesn’t seem like work that will enhance the driver. Users are able to see all batch error messages with the method described above and thus we feel no change is required. Adding a ‘total number of errors’ like you describe wouldn’t be helpful either. The user still needs to process the batch response, so they will be seeing the total regardless of whether is presented to them outright, or through batch processing. Finally, again, while changing to show a first error message may help workflows that use the first response, it will harm workflows that take advantage of last error message, having zero, or even a negative effect, in the long run.

Thanks for the submission, and discussion, but we will now close this issue.

[Jeffery-Wasty]

Hi @inponomarev,

We’ll look into this. You make a good argument around how returning the last known error can mask the actual problem, but we’ll have to take a look into the impact this has on other workflows. Thanks for the PR as well, we’ll take a look into that too.