[alaricd]

Fixes #1284.

Root cause

FbDataReader.HasRows returned _command.HasFields, which is true for any query with columns, including empty result sets.

Change

HasRows now fetches one row ahead before the first Read, and Read/ReadAsync return that buffered row first. Empty, closed, schema-only, and fieldless results report false. The peek is synchronous because HasRows is a synchronous property.

Contract

DbDataReader.HasRows: "true if the DbDataReader contains one or more rows; otherwise false."

Tests

• HasRowsIsFalseForAnEmptyResultTest: fails without the fix (Assert.IsFalse(reader.HasRows) fails on the upstream code).
• HasRowsDoesNotSkipTheFirstRowTest: guard for the peek logic. It also passes on the upstream code, because the old HasRows was true for that result.
• Run locally against Firebird 5.0.2 (firebirdsql/firebird:5.0.2 container): all runnable variants pass. Variants that need the embedded client or a wire-encryption mismatch could not run here.

Verification gaps

• Firebird 3.0 and 4.0 not run locally. Upstream CI covers them.
• Embedded and CryptRequired variants not run locally.

AI disclosure

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

🤖 Generated with Claude Code

[cincuranet]

For an explicit EXECUTE PROCEDURE command with 1CommandType.StoredProcedure, _command.Fetch()dequeues the output-parameter values into_peekedRow. If the caller checks HasRowsand then closes/disposes the reader without reading,ClosecallsSetOutputParameters`, but the statement’s queue is now empty. Output parameters remain unset; previously, closing the unread reader populated them.

[alaricd]

@cincuranet Following up on the November 4 review. All identified issues have been addressed:

• Removed the duplicate test.
• Documented why _hasPeekedRow must track whether a fetch occurred independently of _peekedRow.
• Updated Close() and CloseAsync() to preserve stored-procedure output parameters when HasRows has already fetched the result.
• Added synchronous and asynchronous regression tests covering HasRows followed by Close without Read.

Both inline review threads are resolved.

The current CI run passes 23/24 jobs. The only failure is Firebird 5 embedded, where the runner exits with code 3 during HasRowsDoesNotSkipTheFirstRowTest, without reporting an assertion failure.

Could you rerun that job to establish whether the failure reproduces, and re-review the current patch?