What does HRESULT 0x80040E60 (DB_E_CANTORDER) mean?

 
Previous Next
DB_E_CANTFILTER MD_E_BADTUPLE

DB_E_CANTORDER

Order cannot be opened

Exact value and result class

DB_E_CANTORDER has unsigned value 2147749472 (0x80040E60) and signed 32-bit value -2147217824. AllStat describes it as “Order cannot be opened”. In this result, the provider cannot open the requested sort order for the current view.

The high bit is set, so DB_E_CANTORDER is a failure HRESULT. Its facility is 4 (FACILITY_ITF) and its low code is 3680 (0x0E60). For DB_E_CANTORDER, these fields identify an interface-defined result family; they do not identify the provider instance, method, object generation or partial effects.

Contract boundary

For DB_E_CANTORDER, OLE DB view interfaces apply filter and sort definitions to a source rowset. For DB_E_CANTORDER, opening a filter or order depends on the view object, criteria metadata, rowset capabilities and current source state, not merely on the text of a predicate or sort key.

Investigation of DB_E_CANTORDER should start with the IRowsetView-derived object, source rowset generation and filter or sort definition being opened. Capture DB_E_CANTORDER before ADO, ATL, .NET or a database abstraction layer replaces the native HRESULT with a generic exception.

Evidence to collect

A useful DB_E_CANTORDER event records provider CLSID and version, process architecture, interface IID and method, object correlation ID, transaction state and the immediately preceding HRESULT. When recording DB_E_CANTORDER data involving filter values, sort keys and row identities, use types, lengths, hashes or redacted identifiers rather than secrets or complete business data.

  • Evidence 1 for DB_E_CANTORDER: ordered column DBIDs and direction flags.
  • Evidence 2 for DB_E_CANTORDER: current source metadata and rowset properties.
  • Evidence 3 for DB_E_CANTORDER: provider diagnostics from the sort-open stage.

Conditions that specifically lead to this result

  • Cause 1 for DB_E_CANTORDER: a sort key is unavailable or not orderable.
  • Cause 2 for DB_E_CANTORDER: the provider does not support the requested multi-column order.
  • Cause 3 for DB_E_CANTORDER: source rowset changes invalidated the stored sort definition.

Diagnostic sequence

  1. Capture raw 0x80040E60 and symbolic DB_E_CANTORDER at the native call boundary.
  2. Identify the exact failing stage for DB_E_CANTORDER: the provider cannot open the requested sort order for the current view.
  3. Retrieve all OLE DB error records for DB_E_CANTORDER before another COM call replaces thread error information.
  4. Compare the live object state and provider-granted capabilities with the input that produced DB_E_CANTORDER.
  5. Reduce the DB_E_CANTORDER operation to the smallest case that preserves the same view contract.
  6. Apply one evidence-backed correction for DB_E_CANTORDER and verify that the result is not merely replaced by a neighboring HRESULT.

Retry and recovery

Retry rule for DB_E_CANTORDER: retry after replacing the order with one supported by the current source. A DB_E_CANTORDER retry is safe only when the relevant input, object generation, capability or external state has changed. Before replaying a modifying call that returned DB_E_CANTORDER, determine whether rows, schema objects or URL resources were partially created or changed.

Do not turn DB_E_CANTORDER into an unbounded retry loop. Preserve cancellation for DB_E_CANTORDER and use a fresh provider object when the failed call may have left local state ambiguous.

Corrective actions

  • Action 1 for DB_E_CANTORDER: remove unsupported keys or directions.
  • Action 2 for DB_E_CANTORDER: rebuild the order from current column metadata.
  • Action 3 for DB_E_CANTORDER: push ordering into the command only when collation and null ordering remain correct.

Practical scenario

A view attempts to sort an object-valued column; selecting a scalar key prevents DB_E_CANTORDER. Keeping DB_E_CANTORDER with the method and object state makes this scenario diagnosable instead of reducing it to “database error”.

Developer and operations guidance

Code handling DB_E_CANTORDER should release COM objects in ownership order, retain per-row, per-column or per-property statuses, and log granted capabilities rather than only requested options. While handling DB_E_CANTORDER, opaque values such as HACCESSOR, HROW, HCHAPTER, DBID components and provider handles must remain scoped to the object that issued them.

Operational dashboards for DB_E_CANTORDER should group by provider version, interface, method and normalized failure stage. A DB_E_CANTORDER event must not expose passwords, tokens, full connection strings, unrestricted command text or raw row contents.

Difference from nearby HRESULT values

DB_E_CANTFILTER concerns a predicate view, while DB_E_CANTORDER concerns creation of an ordered view. Telemetry and remediation for DB_E_CANTORDER should keep these outcomes distinct.

Official Microsoft references

Looking for a different code? Search another status or error code.