Classify the MDB problem
| Condition | Investigation |
|---|---|
| Opens in Access, original software gone | Extract schema, relationships, queries and data; determine which business rules lived in application code. |
| Jet/Access reports corruption | Preserve copies, inspect file/version context and attempt bounded repair or table extraction. |
| Password or workgroup security | Identify legitimate credentials, MDW/workgroup configuration and file-level versus user-level security. |
| Tables appear but data is incomplete | Check linked tables, external backends, attachment paths and filtered application views. |
| Application errors while MDB opens | Investigate DAO/ADO/provider version, queries and application expectations rather than repairing healthy data. |
Recovery and extraction sequence
- Stop writes and preserve the MDB plus LDB, MDW, linked files and application configuration.
- Identify Jet/Access version and whether encryption/security is involved.
- Inventory tables, fields, indexes, relationships, saved queries, forms/modules where present and linked-table targets.
- Extract intact objects to a fresh staging database or open format.
- Validate AutoNumber keys, memo/OLE fields, dates, decimals and Unicode/code-page behavior.
- Reconcile record counts and known business totals.
Limits and migration implications
Compact-and-repair may help some logical damage but also changes the file; never run it on the only copy. Deleted or overwritten pages may be unrecoverable. Opening tables does not recover validation or calculation rules implemented by a VB6/Delphi client.
Use database recovery services for damaged or mixed estates and format identification when file identity is uncertain. VB6 dependencies belong in the VB6 cluster; undocumented application rules may need reverse engineering.
Provide
MDB and companion files, original application, error text, Access/Jet version if known, credentials you are authorized to use, linked-table sources and expected record examples.