What database server are you using? More specifically does it support batched updates?
It appears that the SQL in the exception should be provided via the currSql member of batchUpdate. If possible could you add try debugging the doInStatement method to see where the exception is raised and what the value of currSql is at the time.
A repro project would also be very useful to help us replicate the problem.
Reproduced the problem, thanks for the test project.
The problem isn't that SQL in the exception contains the first element, rather that it contains the last. The reason for this is that your database supports batched updates so all the SQL is submitted as a single request. By the time the exception has been raised all the statements have been looped over and so the last one ends up in the message.
This is obviously a bit misleading but I don't think we have a safe way to tell precisely which SQL statement failed. Probably the best that we can do is ensure that the exception contains all the SQL statements concatenated together.
If you know that you will always be talking to HSQLDB it is possible to access the actual SQL that failed in the following (non portable) way: