EBME Forums Forums Maintenance Biomed Databases Archiving Data

Remember them? I'm in the local town Library at the moment ... and there's a microfiche set-up three yards from where I'm sitting! They use it for the Burial Index(es), apparently.

And - what's more - up in the corner sits a 35 mm microfilm reader. The film spools for this one contain archives from the local newspaper.

I remember that the army tried microfiche for parts lists and such. They were even talking about a "pocket reader" for "field" use, although I never came across one myself.

But who knows, maybe Santa will bring this one, Robert!

Or - if you've been really good - this.

I wonder if someone could help me out here?

I am looking for a database file generated by the Borland Paradox database manager (any version will be OK ... but the more, the merrier).

I need this file in order to test out a data importing routine.

So ... if anyone has such a file available (any data will do, but "equipment related" data would be most appreciated), I would be pleased to accept it.

My email address is in my Profile.

Thanks in advance.

Any idea if it shipped with Visual dBase?

aha - whilst looking for it, I came across the wonderful XTGold.

Happy days

It was worth it just for that, then!

I still have XTG here (2.01 circa 1990)

There may be bits of Paradox with Delphi ... and maybe VB includes importing and exporting from and to Paradox (although I can't be sure).

There was a time (the early to mid 1990's), of course, when Paradox databases were the "flavour of the month". I can still remember a guy out in KSA insisting that we use it (we - I - didn't of course, as even back then we had too much time and effort invested in dBASE code).

No, Huw ... it's just a database file in the Paradox format that I need. If I have to, I expect I could create one myself (although I don't have Paradox loaded on any machine within easy reach)!

Cheers

PS: apart from Paradox (which, if I remember rightly, had its own language, known as PAL), I always liked Borland stuff (and Philippe Kahn is one of my heroes), so - once more down memory lane:- do you remember TurboBasic (and all the other Turbo's)? Then there was Quattro Pro ... and, of course, SideKick (a classic, and still the definitive TSR, surely)?

I'm still working on this one (see the OP).

After a fair amount of experimentation (but no real *LBM's) it's looking like this:-

An archiving capability for jobs records only. Options to include:-

1) All
2) All closed
3) All in year (eg, 2012)
4) Closed in year
5) All within a date range (eg, 06-04-2010 to 05-04-2011)
6) Closed within a date range

With 4) being the default (with "last year" - 2012 at the moment - being suggested).

The archived records end up in a .zip file. From that point it's up to the user to squirrel it away somewhere (renaming it to whatever, and moving it to wherever - for safekeeping). Once safely archived, records meeting the selection (as above) will be deleted from the working database. For tidiness the Jobs are renumbered (any gaps are closed).

The more difficult part (when it comes to the programming) is when recalling the archived data back into the current working database ... and inserting in some sort of sensible way. For my own quirky reasons, I want to be able to seamlessly recall the archived data at any time (and, yes - re-archive it at will)! The way I'm doing it involves Jobs being renumbered so that they always remain in order of job opening date. But first the user has to copy the .zip file back into place (into the working directory - or, if you insist, "folder"), renaming it specifically, then running the recall routine.

If we're not careful, stuff like this can end up being unduly complicated (not to mention difficult to explain)! And as always there's a balance to be struck when it comes to verifying incoming data (against related databases, for example), especially in regard of how long it all takes - bearing in mind that some Jobs databases can be relatively large.

Just thought you'd want to know all that.

PS: "nothing heard" on Paradox.

* Light-Bulb Moment(s)

Any more comments on this topic?

I've decided to be able to archive what I call "outputs" (reports etc.) as well as jobs records. This routine also compiles data into a .zip file, for storage and (or) recalling as needs be.

And at the moment (that is, these last few weeks) I'm looking into "data migration" - a topic that may warrant its own thread. In a phrase:- how to preserve legacy code?

In an attempt to keep things straight in my own mind, I use the following rough definitions:-

1) Archiving: preserving "historical" (or closed) data*
2) Importing: bringing in data from "outside"
3) Exporting: sending out data to various "outside" formats (.csv**, .xls etc.)
4) Sharing: passing updated data between the same database system used at (different computers at) different locations
5) Migration: passing data between various - but different - database systems (whilst preserving as much valid data as possible) and re-coding if necessary (and possible)***

My methods are:-

1) Selection of records then compilation to .zip file(s)
2) Importing from .csv to native datafiles (.dbf)
3) Exporting from native datafiles (.dbf) to selected format (.csv, .txt, .xls etc.)
4) Selection of records then compilation to .zip file(s) for unpacking at the receiving computer
5) Getting legacy data into .xls, saving as .csv then importing into native datafile (.dbf) for cleaning up and further processing

It's that last bit - "cleaning up and further processing" that has resulted in various bottle necks (log-jams?) and I'm wondering how others - and other systems - have dealt with it (if at all)!

* With an option to clear out (remove, delete) old records once they have been archived.
** Traditional Comma-Separated Value data files.
*** Some database systems use native "codes" - eg, job codes etc. - within their routines and it's nice to be able to re-assign these when data is being migrated in, if possible (and if their structure and rationale is published, or otherwise understood).