Sounds like you are doing OK on your own Tin Miner and I commend your effort.
The reason I asked about the format is that I have something that I developed some years ago for the West Cumbria Mine Research Group, (reading this Dave Banks). I developed the database as a normalised multi relational Microsoft Access run-time application. The population was by WCMRG member Dave Kelly who added 11175 miners, 4020 addresses where miners lived, with employments at 400 mines. The effort of Dave Kelly is truly remarkable, the above numbers are correct and not typo errors. Being multi relational it obviously has advanced search and reporting functionality, and would require little effort to 'back end' an Internet website.
The origins are interesting as it was originally developed by Dave who produced, and I emphasise no disrespect intended here; a mess. This is actually quite common. Access is deceptively easy to get into, like a beach on a warm day, and the sea looks so tempting. One goes for a paddle, the water is nice so one takes a further step, water is now up to your thighs and one more step and the bottom takes a sudden plunge!
To develop professionally with MS Access one needs a good working knowledge of the relational model, structured query language, and the Visual Basic for Applications programming language amongst quite a few other things. To develop commercial databases, add mathematics, book keeping and accountancy. The learning curve is 5 years + full time.
Anyway, back to subject. The above database is readily adaptable to any purpose with a change of title etc. Roy Morton has a copy that he is populating with information that he has spent quite some time putting together.
It is capable of importing data from other formats using Open Database Connectivity Drivers (ODBC) such as Excel, dBase, FoxPro, CSV text files or whatever. It also supports OLE whereby photographs etc can be embedded in the database for rapid retrieval, this is by means of a simple Windows browse dialog box, "Where is my picture" all automated with Visual Basic. There is however an issue here whereby the Microsoft Jet 4 data engine will only support a data file of 2 gigabytes. It could however be migrated to a server database such as SQL Server which has no limit.
The bottom line is this is freely available to anyone who can use it, although importing from above described 'flat file' systems could sometimes necessitate manual linking between different data tables to create the relationship.
The application is really a simple lightweight effort having a mere 15 tables and little source code. My 'heavy weight' financial management application has 71 tables and enough source code to fill an encyclopaedia, the main code blocks in 41 modules, and deployment is at 150 megs with an empty data file.
Update 21/12/07
Seeing no response to this posting I have to make myself clear. Basically, if anyone wants this, buck shee, its there for the asking. However, it would be better if I did any data importing from other formats on a turnaround basis. I know that there are people out there developing databases in various forms, I just want to try and help.
My avatar is a poor likeness.