Linux: when the first statement of a batch fails at execute, the rest of the batch is lost (5.6.0) #483

Version: 5.6.0 (and master). Platform: Linux only, with msodbcsql18. Seen on CI's Ubuntu runners and on Fedora under WSL. Windows is fine.

What happens

If the first statement of a batch fails at execute and the batch carries on, Linux reports the error as the end of the query. Everything after it is lost.

raiserror('boom', 16, 1); select 2 as m

The same thing happens with a duplicate key insert followed by a select (insert #t values (1); select 2 as m against a table that already has row 1): the 2627 error comes with more=false, and the select's result never arrives.

5.6.0's fix for #475 (the look-ahead after a failed SQLExecDirect in odbc_statement_legacy.cpp) evidently does not hold on Linux. The driver may report the state after the failed execute differently there; we have had Linux-specific handling for msodbcsql18 before.

Repro

The event contract corpus on #482 pins it:

• test/contract/corpus/errors/raiserror-then-result.{events,callback}.linux.txt
• test/contract/corpus/errors/dup-key-d.{events,callback}.linux.txt

Both are marked # status: known-bug. The Windows transcripts next to them (.txt) show the expected sequence. Run with node test/contract/capture.js raiserror-then-result dup-key-d.

The same result comes from #482's lib/ and from the base commit's (00787346), so it is older than the queue work in that PR.

Fix

Bring Linux in line with Windows. Once it does, the .linux.txt files are deleted, and the shared transcripts apply on both platforms.