What does HRESULT 0x80040E64 (MD_E_INVALIDCELLRANGE) mean?

 
Previous Next
MD_E_INVALIDAXIS DB_E_NOCOLUMN

MD_E_INVALIDCELLRANGE

One or more cell ordinals is invalid

Exact value and result class

MD_E_INVALIDCELLRANGE has unsigned value 2147749476 (0x80040E64) and signed 32-bit value -2147217820. AllStat describes it as “One or more cell ordinals is invalid”. In this result, a requested cell range contains at least one ordinal outside the current cellset.

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

Contract boundary

For MD_E_INVALIDCELLRANGE, OLE DB for OLAP models axes, tuples, coordinates and cells separately. For MD_E_INVALIDCELLRANGE, a tuple identifies one member from each relevant hierarchy, a coordinate positions a cell across axes, and cell ordinals are valid only for the current dataset shape.

Investigation of MD_E_INVALIDCELLRANGE should start with the dataset object, axis metadata, tuple construction and cellset generation used by the failing call. Capture MD_E_INVALIDCELLRANGE before ADO, ATL, .NET or a database abstraction layer replaces the native HRESULT with a generic exception.

Conditions that specifically lead to this result

  • Cause 1 for MD_E_INVALIDCELLRANGE: the start or end ordinal exceeds cell count.
  • Cause 2 for MD_E_INVALIDCELLRANGE: range arithmetic overflows or reverses boundaries.
  • Cause 3 for MD_E_INVALIDCELLRANGE: cached cell ordinals belong to an earlier axis cardinality.

Evidence to collect

A useful MD_E_INVALIDCELLRANGE event records provider CLSID and version, process architecture, interface IID and method, object correlation ID, transaction state and the immediately preceding HRESULT. When recording MD_E_INVALIDCELLRANGE data involving member unique names, cube coordinates and calculated-measure expressions, use types, lengths, hashes or redacted identifiers rather than secrets or complete business data.

  • Evidence 1 for MD_E_INVALIDCELLRANGE: requested first and last cell ordinal.
  • Evidence 2 for MD_E_INVALIDCELLRANGE: current total cell count and axis cardinalities.
  • Evidence 3 for MD_E_INVALIDCELLRANGE: dataset generation used to calculate the range.

Diagnostic sequence

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

Corrective actions

  • Action 1 for MD_E_INVALIDCELLRANGE: perform checked range arithmetic.
  • Action 2 for MD_E_INVALIDCELLRANGE: clip user paging only within documented bounds.
  • Action 3 for MD_E_INVALIDCELLRANGE: recompute linear ordinals whenever axis shape changes.

Retry and recovery

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

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

Practical scenario

A grid requests the old final page after filtering shrinks the cube result; recomputing cell count avoids the invalid range. Keeping MD_E_INVALIDCELLRANGE with the method and object state makes this scenario diagnosable instead of reducing it to “database error”.

Difference from nearby HRESULT values

MD_E_BADCOORDINATE rejects a multidimensional coordinate, while MD_E_INVALIDCELLRANGE rejects linear cell ordinals. Telemetry and remediation for MD_E_INVALIDCELLRANGE should keep these outcomes distinct.

Developer and operations guidance

Code handling MD_E_INVALIDCELLRANGE 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 MD_E_INVALIDCELLRANGE, opaque values such as HACCESSOR, HROW, HCHAPTER, DBID components and provider handles must remain scoped to the object that issued them.

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

Official Microsoft references

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