Format · GIS\Key 3.1
Your GIS\Key data, moved without a single number being rewritten.
GIS\Key 3.1 is discontinued, desktop-bound, and stores your history in FoxPro DBF tables that need an AutoCAD licence to open. Migrating off it is not a file conversion — it is a chain-of-custody problem. This is a technical account of exactly what CHEMDAS reads, what it does, and what it refuses to do.
01 — What we read
22 tables, not just the results file.
A GIS\Key export is a directory of DBF tables whose meaning lives in the
relationships between them — QC class is encoded by which
file a row is in, not by a column. Reading CResult.dbf
alone silently discards the blanks, spikes, duplicates, and surrogates that make
the results defensible. CHEMDAS reads the whole set and preserves the classification.
| DBF table | Becomes | Identified by |
|---|---|---|
| LMLIST.dbf | Lab method analytes | LAB_ID · METH_ID · LM_CODE · CAS_NUM · SEQ_NUM · LIMIT_1 |
| LMETHOD.dbf | Lab methods | LAB_ID · METH_ID · LM_CODE · LMETH_NAME |
| Site.dbf | Sites | SITE_ID · X_COORD · Y_COORD |
| WELL.dbf | Wells | SITE_ID · T_DEPTH · WELL_BOT |
| CFIELDM.dbf | Field measurements | SITE_ID · SAMP_DATE |
| FLLEVEL.dbf | Fluid levels | SITE_ID · FL_DATE · FL_CODE · LEVEL |
| CSample.dbf | Samples | SITE_ID · SAMP_ID · SAMP_DATE |
| WSCREEN.dbf | Well screens | SITE_ID · SI_TOP · SI_CODE · SI_MATER |
| DSPIKE.dbf | Spike definitions | SPIKE_TYPE · SEQ_NUM · CAS_NUM · MAX_RPD |
| DSURROG.dbf | Surrogate definitions | SEQ_NUM · CAS_NUM · B_RECOVER · E_RECOVER |
| Cblank.dbf | Blank results | CAS_NUM · CONC · BLANK_ID · C_UNIT |
| CRESULTD.dbf | Duplicate split results | SITE_ID · CAS_NUM · CONC · C_UNIT |
| CResult.dbf | Primary results | SITE_ID · CAS_NUM · CONC · C_UNIT |
| SPIKE.dbf | Spike results | SPIKE_DUP · T_CONC · CAS_NUM · S_CONC |
| ctestb.dbf | Blank tests | SAMP_ID · TESTED · BLANK_ID · LAB_ID |
| ctestq.dbf | Control spike tests | SAMP_ID · TESTED · TEST_ORIG |
| ctestd.dbf | Duplicate split tests | SITE_ID · SAMP_ID · TESTED · LM_CODE · PRIME_LAB |
| CTest.dbf | Primary tests | SITE_ID · SAMP_ID · TESTED · LM_CODE |
| SURROGB.dbf | Blank surrogates | CAS_NUM · S_CONC · RECOVER · BLANK_ID |
| SURROGQ.dbf | Control spike surrogates | CAS_NUM · S_CONC · RECOVER · LBATCH_ID |
| SURROGD.dbf | Duplicate surrogates | SITE_ID · CAS_NUM · S_CONC · RECOVER |
| SURROG.dbf | Primary surrogates | SITE_ID · CAS_NUM · S_CONC · RECOVER |
This table is generated from the importer's declared type signatures at render time. It is not a maintained list — if the pipeline stops reading a table, this page stops claiming it.
The field-level mapping is documented to the same depth: the authoritative
94-field LABDATA specification covers every
RES_CODE pattern, exception code, and
warning code the format can emit — including the ones GIS\Key's own documentation
never explained.
02 — The process
Five steps, and you can stop at any of them.
Nothing is written to your database until the final step. Everything before it is staged, reversible, and inspectable — because the moment an import is both irreversible and opaque, you have lost the ability to defend it.
-
Step 1
Configure
Point at the export and choose the project. Files are hashed on arrival; the hash follows the batch into the audit chain.
-
Step 2
Select
Each file is routed by content fingerprint — the columns it carries — scoped to the format you chose, with the filename only as a tiebreaker. Rename a file and it still routes correctly.
-
Step 3
Validate
Severity-tiered rules run per field: required fields, CAS format, dates, unit-aware ranges, method-in-standard. Warnings inform; failures block.
-
Step 4
Review
Preview the staged rows, standardize units, resolve errors, approve analytes the registry has not seen, and confirm location stubs. This is where a human decides — and only here.
-
Step 5
Commit
Staged rows land in the unified schema. Failed rows can be retried alone; the whole batch can be discarded or rolled back, with deleted rows archived to S3 with a SHA-256 manifest first.
03 — What happens to a value
The lab reported it. We keep it. Everything else is derived alongside.
Canonical units are not a rewrite. The as-reported concentration, its unit, and its qualifier are stored exactly as the lab sent them and are never mutated. The canonical value is computed next to the original, carrying the conversion factor and the registry version that produced it — so a result questioned years from now can be traced back to the source file without anyone's word being involved.
As reported → canonical
Illustrative — sample data
| Analyte | As reported | Canonical | Factor | Status |
|---|---|---|---|---|
| Trichloroethylene 79-01-6 | 0.0047 mg/L | 4.7 ug/L | ×1000.0 | Converted |
| Tetrachloroethene 127-18-4 | <0.5 UG/L Non-detect | <0.5 ug/L | ×1.0 | Unit normalized |
| Benzene 71-43-2 | 12 ug/L Estimated | 12 ug/L | ×1.0 | Already canonical |
Conversion registry 2026-07-20.1 · as-reported values are stored unmodified · canonical values are derived, not written over the original
04 — Limits
What this migration does not do.
You will find these out in the first hour anyway. Better here.
- CHEMDAS does not reconstruct data GIS\Key never stored. If a value was lost in your original installation, migration surfaces the gap — it does not fill it.
- Analytes the reference registry has not seen require an explicit human approval before commit. This is deliberate friction: silently inventing an analyte is how a database quietly stops being defensible.
- Unrecognized qualifier codes are flagged as warnings, not dropped and not guessed. A code we do not have a dictionary entry for stays visible as an unknown.
- Units we cannot convert are marked unconvertible and passed through unchanged rather than coerced. The as-reported value is still exactly what the lab sent.
- CHEMDAS ingests already-reduced lab results — GIS\Key DBF exports and GIS\Key EDDs. It is not an instrument data system and does not process raw chromatograms.
05 — And it goes back out
The migration is not a one-way door.
CHEMDAS writes GIS\Key 3.1 DBF as well as reading it — the reverse of this pipeline, through the same field mapping. A platform that can only take data in is asking you to trust it forever. Two ways out: the Excel workbook export you run yourself from the app, whenever you want it, and the GIS\Key 3.1 DBF export, which an operator runs for you on request rather than a button you press. Ask for either on the assessment call and we will show you the file.