What does HRESULT 0x80040E61 (MD_E_BADTUPLE) mean?

 
Previous Next
DB_E_CANTORDER MD_E_BADCOORDINATE

MD_E_BADTUPLE

Tuple is invalid

Exact value and result class

MD_E_BADTUPLE has unsigned value 2147749473 (0x80040E61) and signed 32-bit value -2147217823. AllStat describes it as “Tuple is invalid”. In this result, an OLAP operation receives a tuple whose members do not form a valid tuple for the current cube and axis context.

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

Conditions that specifically lead to this result

  • Cause 1 for MD_E_BADTUPLE: members come from incompatible hierarchies.
  • Cause 2 for MD_E_BADTUPLE: tuple arity does not match the expected coordinate shape.
  • Cause 3 for MD_E_BADTUPLE: a member unique name is stale after cube metadata changed.

Contract boundary

For MD_E_BADTUPLE, OLE DB for OLAP models axes, tuples, coordinates and cells separately. For MD_E_BADTUPLE, 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_BADTUPLE should start with the dataset object, axis metadata, tuple construction and cellset generation used by the failing call. Capture MD_E_BADTUPLE before ADO, ATL, .NET or a database abstraction layer replaces the native HRESULT with a generic exception.

Diagnostic sequence

  1. Capture raw 0x80040E61 and symbolic MD_E_BADTUPLE at the native call boundary.
  2. Identify the exact failing stage for MD_E_BADTUPLE: an OLAP operation receives a tuple whose members do not form a valid tuple for the current cube and axis context.
  3. Retrieve all OLE DB error records for MD_E_BADTUPLE 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_BADTUPLE.
  5. Reduce the MD_E_BADTUPLE operation to the smallest case that preserves the same olap contract.
  6. Apply one evidence-backed correction for MD_E_BADTUPLE and verify that the result is not merely replaced by a neighboring HRESULT.

Evidence to collect

A useful MD_E_BADTUPLE 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_BADTUPLE 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_BADTUPLE: member unique names and hierarchy IDs.
  • Evidence 2 for MD_E_BADTUPLE: expected tuple arity from axis metadata.
  • Evidence 3 for MD_E_BADTUPLE: cube and catalog generation used to build the tuple.

Corrective actions

  • Action 1 for MD_E_BADTUPLE: construct tuples from current schema metadata.
  • Action 2 for MD_E_BADTUPLE: include at most the permitted member from each hierarchy.
  • Action 3 for MD_E_BADTUPLE: re-resolve persisted member names before execution.

Practical scenario

A saved tuple combines two members from the same hierarchy; reconstructing it with one member per hierarchy makes it valid. Keeping MD_E_BADTUPLE with the method and object state makes this scenario diagnosable instead of reducing it to “database error”.

Retry and recovery

Retry rule for MD_E_BADTUPLE: retry after rebuilding the tuple from valid current members. A MD_E_BADTUPLE 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_BADTUPLE, determine whether rows, schema objects or URL resources were partially created or changed.

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

Difference from nearby HRESULT values

MD_E_BADCOORDINATE rejects a complete cell coordinate, while MD_E_BADTUPLE rejects one tuple component. Telemetry and remediation for MD_E_BADTUPLE should keep these outcomes distinct.

Developer and operations guidance

Code handling MD_E_BADTUPLE 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_BADTUPLE, 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_BADTUPLE should group by provider version, interface, method and normalized failure stage. A MD_E_BADTUPLE 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.