Data WranglerYour well data is scattered across fourteen spreadsheets
Data Wrangler rounds it up, reads what it can, loads what it can prove into SQL Server, and holds the rest with a reason. No more archaeology every time someone asks for a well.
Yes, all of them. On one map.
in the reference master
federal and state
from LAS to Word
(we checked)
Two gates into the corral
Tables come in through one gate, documents through the other. Both end up in the same documented model, and both remember where every row came from.
That external drive in the drawer is worth opening
Farm-ins, acquisitions and vendors hand over data the same way: a 2 TB external drive, a folder tree nobody designed, logs, reports, spreadsheets and seismic in whatever state they left the building.
Point Data Wrangler at the drive. It catalogs every file, reads what it can, and loads the result into the same database as your own wells, so the partner's data is searchable and on the map beside yours. Existing rows are not overwritten, and every row still names the file it came from, so you always know whose is whose.
Point it at a folder, not a file
The tabular loader scans a folder of CSV and Excel files, works out what each one is, and takes the lot through staging, column matching, foreign keys, load and verify.
A partner's delivery goes in as a delivery. If it was the wrong one, the run comes back out in one step.
It matches the easy ones and asks about the rest
Exact matches go straight through; only the exceptions need you. A value that must point at something real, an operator for instance, is resolved rather than stored as loose text.
Skip a column on purpose and the record keeps that decision, so nobody later wonders where it went.
Your filing cabinet, promoted to database
The catalog walks a folder tree, works out what each file is, extracts what it says and stages the rows for promotion. LAS, DLIS, PDF, SEG-Y, shapefiles and Office documents all become records against the same wells.
We use OCR to read PDFs that are scanned images. Every row records the file it came from.
The data you'd never get from spreadsheets alone
Each bar splits a table's rows by where they came from: structured files in blue, documents in orange. Casing, stimulations, drill-stem tests, core photos, petrophysical zones and shows arrive entirely from reports and logs.
Load only the spreadsheets and those tables stay empty. And because every row carries the file it came from, the split is proved, not estimated.
Every file ends up on one of four posters
"Did it load?" has four honest answers, and each needs a different repair. So they are never squashed into a percentage.
Rows in the database carrying this file's id. Traceable back to the page they came from.
Extracted and waiting in staging for the next promote. Nothing lost, nothing asserted.
Blocked for a named reason: no well identifier, no location, an unregistered code. It waits and tells you which.
Neither staged nor loaded. The only real failure, and the only one worth losing sleep over.
Checked on the way in, and again later
Required values, types, widths, constraints and duplicate keys, then business rules with a severity: a latitude out of range, a completion dated before the spud.
The same rules run over the database as it stands. A table no rule covers is reported as unexamined, which is a different answer from clean.
Everything hangs off the well
The fourteen-character identifier is the spine. It is the key in thirty-five tables, and it is how a log, a formation top and a production volume find each other.
Lease & Land
24,178 Wyoming leases, federal and state, on the same map as the wells, each with its operator, status, dates, royalty and mineral type.
Sorted by decade, not by shoebox
Colour leases by owner, status, decade, size or elevation. Shaded by decade, the pattern around Casper is the history of where the activity went.
The land man never has just the one question
Filter by county, status, operator, acreage, elevation, miles from a named town or highway, or how much of the tract is wetland.
Ask in English. Read the SQL before it runs.
Claude writes the query against the tables this database actually has. When it gets creative and names one that doesn't exist, the page flags it before anything runs. Then follow the results all the way to the file.
Watch it run
Three million wells down to one, and back out to a spreadsheet. Recorded against a live database: nothing mocked, nothing sped up.
About eight minutes. Popcorn optional; coffee recommended.
Ready to round up some wells?
Bring a messy folder. We'll show you what loads, what's held and why, on your own data.