Visitar URL original
cmd.Cancel() in QueryRowImpl finally block causes ORA-1013 on Oracle Database Queries · Issue #2215 · DapperLib/Dapper · GitHub
Skip to content

cmd.Cancel() in QueryRowImpl finally block causes ORA-1013 on Oracle Database Queries #2215

Open

Description

@Raveendra-Pai

Summary

The finally block in QueryRowImpl<T> calls cmd.Cancel() when the reader is
not null and not closed. While this works safely with SQL Server, it causes Oracle
to raise ORA-1013 ("user requested cancel of current operation") on any
non-happy-path exit from the method.

Affected Method

SqlMapper.cs → QueryRowImpl<T>

finally
{
    if (reader is not null)
    {
        if (!reader.IsClosed)
        {
            try { cmd?.Cancel(); }
            catch { /* don't spoil any existing exception */ }
        }
        reader.Dispose();
    }
    if (wasClosed) cnn.Close();
    cmd?.Parameters.Clear();
    cmd?.Dispose();
}

Root Cause

cmd.Cancel() is reached whenever reader is not disposed before the finally
block. This happens on all non-happy paths, including:

Scenario reader null before finally?
Happy path (rows found, disposed) ✅ Yes — safe
ThrowZeroRows() called ❌ No — Cancel() fired
ThrowMultipleRows() called ❌ No — Cancel() fired
Any exception thrown mid-read ❌ No — Cancel() fired

On SQL Server, cmd.Cancel() is a safe and common cleanup pattern.
On Oracle (ODP.NET / Oracle.ManagedDataAccess), it sends an explicit cancel
signal to the server, which raises ORA-1013 as a hard error — masking the
original exception (e.g. "no rows found", "multiple rows", or a query error).

Behaviour Discrepancy

  • SQL Server: cmd.Cancel() → silently acknowledged, resources released
  • Oracle: cmd.Cancel() → raises ORA-1013, surfaces as an unrelated error
    in the application

Workaround

Commenting out the cmd.Cancel() call resolves the issue. reader.Dispose()
alone is sufficient for cleanup on Oracle — the explicit cancel is unnecessary
and harmful.

Suggested Fix

Consider making the cancel behaviour conditional on the provider, or removing it
entirely since reader.Dispose() already handles cleanup across all major providers:

//if (!reader.IsClosed)
//{
    // cmd.Cancel() triggers ORA-1013 on Oracle (see issue #XXXX).
    // reader.Dispose() below is sufficient for cleanup across providers.
    // try { cmd?.Cancel(); }
    // catch { /* don't spoil any existing exception */ }
//}

Though the provider-agnostic approach (simply removing the call) is cleaner since
Dispose() is sufficient.

Environment

  • Dapper version: latest (main branch)
  • Oracle driver: Oracle.ManagedDataAccess.Core
  • .NET version: .NET 10
  • Database: Oracle

References

Activity

  1. hiSandog commented on Jul 11, 2026

    @hiSandog

    Rather than only asserting that Oracle no longer surfaces ORA-1013, a regression test could verify that the original “zero rows,” “multiple rows,” or provider exception remains the observable exception. It would also be useful to exercise early reader disposal after the first row, since removing or suppressing Cancel() must not leave the command actively fetching. If behavior becomes provider-specific, documenting the extension point would avoid hard-coding Oracle type names in the core path.

  2. mgravell commented on Jul 11, 2026

    @mgravell
    Member

    That was basically the dilemma that was hurting my head. The entire point of ado.net was for all the providers to follow the same rules to allow abstraction. The reality is very different so we need to decide which "wrong" is less wrong, since it is absurdly hard to reliably sniff the provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions