DDHTool - Home

Overview

I specialize in database design and administration, also in programming interfaces, for the mineral exploration for the mining industry. I have extensive experience in receiving collected data (in a huge variety of form, quality and format) from the field and organizing it in a meaningful manner. I am also well versed in cataloging source data, supporting the master database. Using the Internet allows me to perform those tasks from anywhere. Under those duties, I have developped a suite of handy tools, which I have named DDHTool.

DDHTool is a suite of software applications, ultimately interfacing to a central enterprise mineral exploration database. One of the main strenght of the suite is in its comfort in flowing updates from the field (where no Internet access is available) to a site office (where Internet access is all but limited) and finally to headquarters. Another apsect lies in to simplicity in the design of the database. Contrary to common practice, the data model is very similar to formats familliar to geologists. This promotes better use of the collected data.

The system is completely administered and coded by myself using industry standard software packages. The main database is under Microsoft SQL server, most tools are coded using Microsoft's Visual Studio suite. The system is flexible in that it may be in use on my systems and administered by myself. It can grow (along with deposit / company) into a fully hosted on the company's system and administered by a company database administrator,... or anything in between. Multiple central repository are possible and easy to manage. The free database package used is SQL Server Express (which can accomodate for a 10 gyigabyte database file. The biggest database file I have encountered so far, is just shy of 6 GB.). This makes this system accessible to companies of all sizes. It also makes for a smooth transition, should the owner decide to use an in-house database administrator,... at any point.

Scenario

After the normal confidentiallity documents are in place, I request the historical data and place it in the master database. I catalog the supporting documents (assay certificates, core photos, log scans, etc.). All that data can regularly be replicated to the owners' server, which can be a simple Windows desktop PC.

Other pieces of informations recommended for a smooth startup are:

Distribution lists per site (with access levels - who can see assay results, who can see QAQC results, who can act on actions for QAQC failures)

Libraries of codes used

The establishment of a few policies and procedures (will the company want to use sample dispatch numbers issued by the DBA (database administrator),... at which point will these be issued,... will internal QAQC be used,... at what rate,... etc.)

What data will be collected

etc.

incorporating the new data collected from site(s)

incorporating new assay results from the assay laboratory(ies)

distributing the data

reporting the new data

These tasks are largely handled automatically by DDH3-AdminTools. Typically a 30 minutes job. On site, the approved geologist(s) receives an updated database file, enters the day's collected data using DDH3-SiteTools, and sends the database administrator a copy of the EditLog at the end of the day,... and the cycle continues.

A little history

My system came to life in West Africa in 1996. The main problems were, first in that the data used to reside in disconnected spreadsheets, second issue was the very expensive and limited bandwidth. A simple correction to a spreadsheet required re-transmitting the whole spreadsheet over sat-phones. Then, anytime the data was to be loaded in 3D mining software, required manually assembling the data for the mining software from the numerous spreadsheets. Errors were numerous,... the process was tedious.

Migrating from multiple spreadsheets to a database was only a natural first step. Next, HQ (headquarters) only needed the changes to the database,... not the whole database every update. This is where DDHTool steps in. While updating the local database, using my tools (in West Africa), a text file is generated where every changes to the database are logged. Only the text file is required to synch the master copy. That text file is all that needs transmitted to HQ. HQ can then transmit a fresh copy back to site for the next day's data entry.