🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac.databases
Article #357

Re: FileMaker Pro 2.0 warning

#357
From: Tonio Loewald
Date: Thu, 15 Oct 1992 06:39
46 lines
2819 bytes
Paul.Heller@p391.f70.n109.z1.fidonet.org (Paul Heller) writes:

>I spoke with Claris Tech Support yesterday about a problem I was having with
>several FileMaker Pro databases after receiving the 2.0 upgrade.  Turns out
>there's a potential big-time problem when converting files unless you do the
>right things first.

>The problem involves any FileMaker Pro file that was created or used under 
>1.0v1.  Seems 1.0v1 had a problem with its indexes, and doing a RECOVER
>under 1.0v2 or 1.0v3 would fix it.  If the problem remains, however, and
>you simply convert the file to 2.0 format, you'll lose data, and according
>the person I spoke to at Claris there is NO way to recover it.

>The key to avoiding this is to RECOVER the file first - don't just open &
>convert it with FM Pro 2.0.  I don't know whether doing a recover of a 1.0vx 
>file in 2.0 also converts it, since I had already converted the files by the
>time I learned this.

>There's supposed to be an insert in the package that explains this, but mine
>must have been one of the first shipped, because it didn't have one.  

>Be warned - this cost me a lot of grief, since I didn't understand what had
>happened and then put in many hours adding data to one of my most important
>files & couldn't simply go back to the pre-2.0 backup.  It's amazing that they
>didn't discover this during development and test of 2.0 - it's also a little
>bothersome that a corrupted index can permanently damage a FileMaker file with
>no way to recover the data (it's still there - you just can't get at it), but
>according to Claris tech support, that's the way it is.

I know this doesn't make up for the bug you've mentioned, but such problems
in general (eg. you update the wrong version of a database file) can be
avoided by time-stamping (creation/modification date) on records automatically,
allowing all records created/modified during a given period to be separated out
and exported to the correct version of a file.

There's no reason why such a timestamp shouldn't be added to records (or
for that matter, be made part of any record automatically -- anyone at
Claris listening ? :)  ).

Just a thought.

Tonio Loewald

-- 
Tonio Loewald            | Ph  06 290 1594 | PO Box 101 O'Connor
tal691@huxley.anu.edu.au | Fax 06 290 1595 | ACT 2601   AUSTRALIA
Technical Details
Message-ID: <tal691.719131199@huxley>
Path: arc1-ca.pugleaf.net!sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!usc!rpi!batcomputer!munnari.oz.au!manuel.anu.edu.au!huxley!tal691
References: <718444781.F00005@blkcat.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!usc!rpi!batcomputer!munnari.oz.au!manuel.anu.edu.au!huxley!tal691
From: tal691@huxley.anu.edu.au (Tonio Loewald)
Newsgroups: comp.sys.mac.databases
Subject: Re: FileMaker Pro 2.0 warning
Date: 15 Oct 92 06:39:59 GMT
Organization: Australian National University
Lines: 47
Message-ID: <tal691.719131199@huxley>
References: <718444781.F00005@blkcat.UUCP>
NNTP-Posting-Host: 150.203.2.12