Article View: comp.sys.mac.databases
Article #363Re: FileMaker Pro 2.0 warning
From: Mike Steiner
Date: Thu, 15 Oct 1992 22:36
Date: Thu, 15 Oct 1992 22:36
49 lines
3359 bytes
3359 bytes
In article <tal691.719131199@huxley>, tal691@huxley.anu.edu.au (Tonio Loewald) wrote: > > 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 ? :) ). FileMaker Pro has this ability; however you have to impliment it by setting up a field for it. Not everyone wants to do this, so it is optional. +---------------------------------------------------------------------+ |Now that I have a reader that can do .sigs, I can't think of a witty | |one to put here, so I won't. All normal disclaimers apply. | +---------------------------------------------------------------------+
Technical Details
Message-ID:
<mike_steiner-151092153515@192.35.50.131>Path:
arc1-ca.pugleaf.net!sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!sgigate!olivea!gossip.pyramid.com!pyramid!claris!NewsWatcher!userReferences:
<718444781.F00005@blkcat.UUCP> <tal691.719131199@huxley>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!sgigate!olivea!gossip.pyramid.com!pyramid!claris!NewsWatcher!user From: mike_steiner@qm.claris.com (Mike Steiner) Newsgroups: comp.sys.mac.databases Subject: Re: FileMaker Pro 2.0 warning Message-ID: <mike_steiner-151092153515@192.35.50.131> Date: 15 Oct 92 22:36:31 GMT References: <718444781.F00005@blkcat.UUCP> <tal691.719131199@huxley> Sender: news@claris.com Followup-To: comp.sys.mac.databases Lines: 49 Nntp-Posting-Host: steiner