On Wed, 09 Jan 2013 15:31:55 +0100, herman.viaene@invalid.be.invalid wrote: >Keith Nuttle wrote: > >> On 1/8/2013 8:24 AM, Steve Hayes wrote: >>> On Mon, 07 Jan 2013 12:47:48 -0500, Keith Nuttle >>> <Keith_Nuttle@sbcglobal.net> wrote: >>> >>>> On 1/7/2013 10:49 AM, Steve Hayes wrote: >>>>> On Mon, 07 Jan 2013 08:08:44 -0500, Keith Nuttle >>>>> <Keith_Nuttle@sbcglobal.net> wrote: >>>>> >>>>>> On 1/6/2013 11:05 PM, Steve Hayes wrote: >>>>> >>>>>> To extract the data from these files you first need to determine how >>>>>> the >>>>>> field data was maintained, and then extract each field. I find the >>>>>> macros for word processors to be great for this. >>>>> >>>>> There is one problem with that notion, however. >>>>> >>>>> Computers with floppy disks having very limited storage space, >>>>> programmers tried to get them to hold as much as possible.; >>>>> >>>>> Have you looked at early versions of PAF (1.0 and 2.x)? >>>>> >>>>> They stored each name separately, and in the actual firstname field >>>>> they had a pointer to the name. So if the first name was James, the >>>>> extual string "James" was stored only once, and the Firstname field >>>>> just had a pointer pointing to that name. >>>>> >>>> >>>> As I said you have to determine how the data was stored, then you can >>>> get the record. Sounds like you have completed the first step >>> >>> Not really. I was just pointing out some of the difficulties in the way >>> of finding how the data is stored. Modern databases tend to be quite >>> prodligate with disk space -- xml for example. But back then programmers >>> tried to cram the maximum of data into the minimum of space, so they used >>> all kinds of tricks that make it very difficult to discover how the data >>> is stored. >>> >>> Old sequential access BASIC files are dead easy -- you can import them >>> into a spreadsheet "as is" -- in fact for some purposes of repetitive >>> data entry, like transcribing parish registers, it might be a lot easier >>> to design a BASIC front end than to try to enter it into a spreadsheet. >>> >>> >> If you ever find a good front end that uses a spreadsheet for its >> database please post it. >> >> I grew up on dBase where you could look at the data in the form format >> or spreadsheet format, I would love to find a front end where I could >> look at my speadsheet data in the form format. It is much easier to look >> at one row in a form presentation that to try to trace it in the >> spreadsheet format. > >LibreOffice > >Herman Viaene Are you saying that LibreOffice can read old Personal Pearl and dBASE files? That's good news, if true. -- Steve Hayes from Tshwane, South Africa Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

On 1/10/2013 12:15 AM, Steve Hayes wrote: > On Wed, 09 Jan 2013 15:31:55 +0100, herman.viaene@invalid.be.invalid wrote: > >> Keith Nuttle wrote: >> >>> On 1/8/2013 8:24 AM, Steve Hayes wrote: >>>> On Mon, 07 Jan 2013 12:47:48 -0500, Keith Nuttle >>>> <Keith_Nuttle@sbcglobal.net> wrote: >>>> >>>>> On 1/7/2013 10:49 AM, Steve Hayes wrote: >>>>>> On Mon, 07 Jan 2013 08:08:44 -0500, Keith Nuttle >>>>>> <Keith_Nuttle@sbcglobal.net> wrote: >>>>>> >>>>>>> On 1/6/2013 11:05 PM, Steve Hayes wrote: >>>>>> >>>>>>> To extract the data from these files you first need to determine how >>>>>>> the >>>>>>> field data was maintained, and then extract each field. I find the >>>>>>> macros for word processors to be great for this. >>>>>> >>>>>> There is one problem with that notion, however. >>>>>> >>>>>> Computers with floppy disks having very limited storage space, >>>>>> programmers tried to get them to hold as much as possible.; >>>>>> >>>>>> Have you looked at early versions of PAF (1.0 and 2.x)? >>>>>> >>>>>> They stored each name separately, and in the actual firstname field >>>>>> they had a pointer to the name. So if the first name was James, the >>>>>> extual string "James" was stored only once, and the Firstname field >>>>>> just had a pointer pointing to that name. >>>>>> >>>>> >>>>> As I said you have to determine how the data was stored, then you can >>>>> get the record. Sounds like you have completed the first step >>>> >>>> Not really. I was just pointing out some of the difficulties in the way >>>> of finding how the data is stored. Modern databases tend to be quite >>>> prodligate with disk space -- xml for example. But back then programmers >>>> tried to cram the maximum of data into the minimum of space, so they used >>>> all kinds of tricks that make it very difficult to discover how the data >>>> is stored. >>>> >>>> Old sequential access BASIC files are dead easy -- you can import them >>>> into a spreadsheet "as is" -- in fact for some purposes of repetitive >>>> data entry, like transcribing parish registers, it might be a lot easier >>>> to design a BASIC front end than to try to enter it into a spreadsheet. >>>> >>>> >>> If you ever find a good front end that uses a spreadsheet for its >>> database please post it. >>> >>> I grew up on dBase where you could look at the data in the form format >>> or spreadsheet format, I would love to find a front end where I could >>> look at my speadsheet data in the form format. It is much easier to look >>> at one row in a form presentation that to try to trace it in the >>> spreadsheet format. >> >> LibreOffice >> >> Herman Viaene > > Are you saying that LibreOffice can read old Personal Pearl and dBASE files? > > That's good news, if true. > > > > I can not say about Personal Pearl, But dBase files can be opened in Corel's Quattro Pro spreadsheet. Quattro Pro is part of the Corel WordPerfect Office Suite. Since MS Works will open a dBase file I suspect their higher end Excel will also open them. You may search the net and see if you can find a conversion program for Personal Pearl. There is a conversion programs for every ting ;-)