What does HRESULT 0xC8000517 (hrTableDuplicate) mean?

 
Previous Next
hrTableLocked hrTableInUse

hrTableDuplicate

Why this is more specific than the message text

hrTableDuplicate means table creation reused a name already present in the database.

This is the legacy Directory Service backup/restore HRESULT form of JET_errTableDuplicate (0xC8000517).

The key comparison is: hrObjectDuplicate can include other object classes; this code identifies a table collision. The first useful observation is to enumerate objects with the exact normalized name and inspect whether a previous migration step committed. This evidence distinguishes name collisions, stale table handles, active users, locks, and structural dependencies.

Related ESE conditions

hrObjectNotFounda valid object name does not exist in the selected database or table scope
hrTableInUseopen cursors or operations prevent an exclusive table change
hrObjectDuplicateschema creation collided with an existing object name in the same namespace

The ESE objects in play

Diagnostic layertable and schema-object ownership, locks, and structural dependencies
Typical API surfaceJetOpenTable, JetCreateTableColumnIndex, JetDeleteTable, and schema enumeration APIs
Code-specific conditiontable creation reused a name already present in the database
First corrective directionmake schema migrations idempotent by checking the existing table definition before creation

Schema changes commonly require exclusive access and a specific transaction state. Object existence should be compared with the full expected definition before a migration is skipped.

Data for a reproducible case

  • Code-specific observation: enumerate objects with the exact normalized name and inspect whether a previous migration step committed.
  • the table/object metadata and normalized name; associate it with this result rather than with a later generic exception.
  • all JET_TABLEID owners, open modes, transactions, and current indexes.
  • the exact schema migration step and whether a previous attempt committed.

Corrective workflow

  1. Freeze the failing request context and record 0xC8000517, the Jet API name, and the current instance/session ownership.
  2. Verify the code-specific precondition: enumerate objects with the exact normalized name and inspect whether a previous migration step committed.
  3. Apply the targeted fix: make schema migrations idempotent by checking the existing table definition before creation.
  4. Before retrying the operation, reconcile object definition, exclusive-access state, and migration version.

Actions that can hide or worsen the problem

  • Do not force a schema mutation while table users remain active.
  • Do not skip a migration merely because an object with the same name exists.

Technical references


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