Your Calibration Certificates Are Inside the Access File. Get Them Out Properly Before You Migrate

Here is how it usually goes. The migration plan looks fine. The instrument table exported cleanly to CSV, the calibration history came across with dates and results, and the row counts reconcile. Then someone opens the history for a torque wrench that was found out of tolerance last spring, goes to check the certificate, and finds nothing there. The export took the record but not the PDF, because the PDF was never in a column. It was in an Attachment field, packed inside the .accdb itself.

If your Access calibration database was built after about 2007, there is a good chance someone took this route. It was a sensible choice at the time. Attachment fields meant no broken network paths, no "who moved the Certificates folder" and no separate file share to back up. The lab technician clicked the paperclip on the form, picked the scan, and the certificate stayed with the record. For years it simply worked.

Migration is where that convenience turns into a liability, and you need to deal with it before the extract, not after go-live.

Why Attachment fields don’t migrate like other data

An Attachment field isn’t a column holding a value. Access stores it as a hidden child table: each parent record can hold several files, and each file carries its own file name, file type and binary data. That design has three consequences for a migration.

A standard export leaves the files behind. Export the calibration table to Excel or text and the Attachment column either drops out or comes through as a file name with no file. The CSV your migration partner received is complete as data and incomplete as evidence.

The original file names are rarely meaningful. Technicians attached whatever the scanner produced: scan0001.pdf, IMG_4471.jpg, cert.pdf. Inside Access the record supplied the context, so the name didn’t matter. Pull those files out to a folder and the context is gone. You get forty files called cert.pdf that collide on disk, and no way of telling which belongs to which instrument without opening each one.

The file has been growing toward its ceiling. Each attachment adds at least its own size to the database, and an .accdb has a hard 2 GB limit. A database that holds ten years of scanned certificates is often the reason the file has been slow, needs regular compact-and-repair, and occasionally corrupts. Many teams start migrating precisely because the file is getting close to that limit, which means the certificates are both the payload and the risk.

What an auditor actually needs from a certificate

ISO 9001 clause 7.1.5.2 requires you to keep documented information as evidence that measuring equipment is fit for purpose and traceable to national or international standards. IATF 16949 7.1.5.2.1 goes further: it asks for calibration records that include as-found condition when an instrument is out of specification, and an assessment of whether product was affected. AS9100 and ISO/IEC 17025 make similar demands. In every case the certificate is the bridge from your internal record to the external traceability chain, because it carries the lab’s accreditation, the reference standards used and the measurement uncertainty.

So the requirement isn’t just "keep the PDFs". It’s that every certificate stays tied to the instrument and the calibration event it documents. A certificate that is present but orphaned meets the letter of record retention and fails the moment an auditor asks you to show the certificate for gauge 0412’s calibration on a specific date.

The extraction method: rename on the way out

The fix is simple to describe and worth doing carefully. Extract every attachment with DAO (the method is Field2.SaveToFile), and build the output file name from the record, not from the original name.

A pattern that has held up for me in practice:

<InstrumentID>_<CalDate yyyy-mm-dd>_<EventID>_<seq>.<ext>

For example: TW-0412_2026-03-17_E18833_01.pdf.

Each part has a job:

• InstrumentID: the key the target system will use to find the asset.
• CalDate in ISO format: so files sort chronologically and a person scanning a folder can find the right event.
• EventID: the primary key of the calibration record in Access. This is what guarantees uniqueness and makes the mapping exact. Two calibrations on the same day for the same instrument (a failed as-found, then an as-left after adjustment) are common enough that date alone won’t do.
• seq: because one record can hold several attachments, such as the certificate, a data sheet and a photo of the damage.
• Original extension, kept: do not convert anything during extraction. A converted file is a different file.

Two practical notes. SaveToFile raises an error rather than overwriting an existing file, which is one more reason the record-derived name must be unique. And run the extraction against a copy of the database taken at your freeze point, never against the live file.

Write a manifest alongside the files

The files alone are not enough. Have the same routine write a manifest, a CSV with one row per extracted file: InstrumentID, EventID, CalDate, original file name, new file name, file size. After extraction, add a hash of each file (PowerShell’s Get-FileHash does this in one line). The manifest is your evidence that what left Access is what arrived in the new system, and it costs almost nothing to produce.

A worked reconciliation

Take a hypothetical plant: about 900 instruments and twelve years of history in Access. Before extracting, run a count query against the attachment’s file-name subfield. Access lets you query [Certificate].FileName directly, so you can count attachments per calibration record and in total. Say it returns 6,214 files across 5,870 records.

After extraction you check three numbers:

1. Files on disk = 6,214. If fewer, something was skipped or an error was swallowed.
2. Manifest rows = 6,214, all with a non-empty InstrumentID and EventID. A blank key usually means a calibration record whose instrument was deleted years ago. That is exactly the kind of orphan you want to find now, deliberately, rather than in front of an auditor.
3. Records with zero attachments. This list is often the most useful output of the whole exercise. Some will be in-house checks that legitimately carry no certificate. Others are external calibrations where the certificate was never attached. Better to find those gaps before migration, when you can still request a copy from the lab, than to inherit them in a new system that makes them obvious.

Only once those three checks pass do the files go into the import, matched to their calibration events by EventID.

"Can’t we just keep the Access file as the archive?"

It’s the most common objection, and it’s reasonable. Keeping the old file read-only feels lower risk than touching thousands of documents.

The trouble is that it splits your evidence. The new system holds the instrument, the due date and the pass/fail history, while the proof behind each result stays in a file that needs a specific Access version to open, sits on someone’s share, and gets less familiar every year. When an auditor pulls a sample, someone has to remember which system to open for which year. And the 2 GB, corruption-prone file you were trying to retire becomes the one thing you can’t retire.

Keeping a read-only legacy copy as a backstop is sensible. Making it the only home of your certificates is the problem.

What changes once they’re in PrüfDesk

In PrüfDesk, a certificate is attached to the calibration record it documents: the pass/fail result, the as-found and as-left values, and the procedure followed. That record belongs to a registered instrument, so opening a torque wrench’s history shows each event with its own evidence, and the next calibration due date is calculated from the most recent one. When an auditor samples a gauge, the audit-ready PDF report comes from the same records, so you aren’t assembling it by hand from two systems.

None of that helps if the certificates arrive as forty files called cert.pdf. Getting the extraction right is what makes the rest work.

Pre-extraction checklist

• Freeze point agreed, and a copy of the .accdb taken at that point
• Every table that has an Attachment field identified (certificates are not always only on the calibration table)
• Count query run: total attachments and attachments per record
• Naming pattern fixed: InstrumentID, ISO date, EventID, sequence, original extension
• Extraction writes a manifest; hashes added afterwards
• Three-way reconciliation passed: file count, manifest keys, zero-attachment list
• Missing external certificates requested from the lab before go-live

If you’d like a second pair of eyes on your schema before you extract, we’re happy to go through it with you. Send us the table structure (no data needed) and we’ll tell you where the certificates are hiding.