Home Articles Downloads Forum Products Services Seminar Contact
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 2 of 2 1 2
RoJo #62708 15/11/12 1:59 PM
Joined: Feb 2004
Posts: 14,257
Likes: 20
Super Hero
OP Offline
Super Hero
Joined: Feb 2004
Posts: 14,257
Likes: 20

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. smile

Joined: Feb 2004
Posts: 14,257
Likes: 20
Super Hero
OP Offline
Super Hero
Joined: Feb 2004
Posts: 14,257
Likes: 20

I wonder if someone could help me out here? think

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. smile


If you don't inspect ... don't expect.
Joined: Jun 2000
Posts: 2,390
Likes: 8
Huw Offline
Hero
Offline
Hero
Joined: Jun 2000
Posts: 2,390
Likes: 8
Any idea if it shipped with Visual dBase?

Joined: Jun 2000
Posts: 2,390
Likes: 8
Huw Offline
Hero
Offline
Hero
Joined: Jun 2000
Posts: 2,390
Likes: 8
aha - whilst looking for it, I came across the wonderful XTGold.

Happy days smile

Huw #63033 10/12/12 9:38 PM
Joined: Feb 2004
Posts: 14,257
Likes: 20
Super Hero
OP Offline
Super Hero
Joined: Feb 2004
Posts: 14,257
Likes: 20

It was worth it just for that, then! smile

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 smile

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)?

Joined: Feb 2004
Posts: 14,257
Likes: 20
Super Hero
OP Offline
Super Hero
Joined: Feb 2004
Posts: 14,257
Likes: 20

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

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. whistle

PS: "nothing heard" on Paradox.

* Light-Bulb Moment(s)

Joined: Feb 2004
Posts: 14,257
Likes: 20
Super Hero
OP Offline
Super Hero
Joined: Feb 2004
Posts: 14,257
Likes: 20

Any more comments on this topic? think

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)! think

* 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).

Page 2 of 2 1 2

Moderated by  DaveC in Oz, RoJo 

Link Copied to Clipboard
Who's Online Now
1 members (Diego de Jesus Gonzalez Beltran), 90 guests, and 44 robots.
Key: Admin, Global Mod, Mod
Newest Members
Adil Parmar, Sachin, Natali, Patrick Healy, Lazrdo
9,791 Registered Users
Forum Statistics
Forums25
Topics10,696
Posts72,188
Members9,790
Most Online5,980
Jan 29th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.5