[alaricd]

Fixes #1285.

Root cause

RecordsAffected was taken from the statement type. Firebird classifies INSERT ... RETURNING and DML inside an execute block as stored procedure execution, so the new switch returned -1 for them, although the server reports the correct count. This was a regression for the reader: before this PR it reported the insert count.

Change

• RecordsAffected starts at -1 and is set in the FbDataReader constructor (review feedback).
• INSERT, UPDATE, and DELETE report the server count. Stored procedure execution reports the server count only when it is positive, so a procedure that changes no rows keeps -1.
• UPDATE ... RETURNING and DELETE ... RETURNING are classified as SELECT by Firebird, so they keep -1, as before this PR. This is unchanged and outside this PR.

Measured server counts (Firebird 5.0.2)

• insert ... returning: 1
• insert without returning: 1
• update with no matches: 0
• execute block with one insert: 1; with two inserts: 2; empty block: 0
• update ... returning and delete ... returning: -1 (SELECT classification)

Tests

• RecordsAffectedForInsertReturningTest (reader) and ExecuteNonQueryForInsertReturningTest: fail without the fix (Expected: 1, But was: -1).
• ExecuteNonQueryForStatementWithoutRowChangesIsMinusOneTest: pins the -1 for a procedure that changes no rows.
• RecordsAffectedIsMinusOneForSelectTest: existing SELECT coverage.
• Run locally against Firebird 5.0.2: 192 passed across the command, batch, stored-procedure and reader suites. The failures were all environment errors (embedded client missing, or wire-encryption mismatch with the container config).

Verification gaps

• Firebird 3.0 and 4.0 not run locally.
• Embedded and CryptRequired variants not run locally.

AI disclosure

This change was prepared with AI assistance (Claude Code).

🤖 Generated with Claude Code

[cincuranet]

I think this is not entirely correct. The INSERT ... RETURNING in Firebird is reported as StoredProcedure IIRC and hence now it would become -1.