🚀 go-pugleaf

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

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