I have a file running on Fm 9.0 server. When it backups, I get the
message "verification failed error 664".
Should I use the clone of this file to replace it , save the file as
"compacted clone" or use a recovred file.
Thanks
news:1191005886.125223.216990@n39g2000hsh.googlegroups.com.. .
>I have a file running on Fm 9.0 server. When it backups, I get the
> message "verification failed error 664".
>
> Should I use the clone of this file to replace it , save the file as
> "compacted clone" or use a recovred file.
>
> Thanks
>
Good practice is to save a clone from your file as soon as you start
working. Then when something happenes you have an unused and undamaged
clone. Recover is only realy there to recover your data. It is not intended
to keep on working with the file. It may seem like the file functions after
a recover, but error may still be there and they might re-appear at any
time. If you don't have a fresh clone, you are left with an untrustworthy
file. You just might try and work with the recovered file. But don't be
surprised when it crashes in a major way along the line. An other solution
would ofcourse be to rebuild your file from scratch. Safe a clone (just in
case) and import the data from the recovered file. I know that almost nobody
works like this (storing virgin clones), but it is the only option to be
completely safe.
Keep well, ursus
On Sep 28, 4:21 pm, "Ursus"
>
>
> >I have a file running on Fm 9.0 server. When it backups, I get the
> > message "verification failed error 664".
>
> > Should I use the clone of this file to replace it , save the file as
> > "compacted clone" or use a recovred file.
>
> > Thanks
>
> Good practice is to save a clone from your file as soon as you start
> working. Then when something happenes you have an unused and undamaged
> clone. Recover is only realy there to recover your data. It is not intended
> to keep on working with the file. It may seem like the file functions after
> a recover, but error may still be there and they might re-appear at any
> time. If you don't have a fresh clone, you are left with an untrustworthy
> file. You just might try and work with the recovered file. But don't be
> surprised when it crashes in a major way along the line. An other solution
> would ofcourse be to rebuild your file from scratch. Safe a clone (just in
> case) and import the data from the recovered file. I know that almost nobody
> works like this (storing virgin clones), but it is the only option to be
> completely safe.
>
> Keep well, ursus
Fortunately I have a "clone" of the original. I get so many different
answers from FM and others. You have to wonder why they offer
"compact" and optimize when they then come back and say that can
damage the file as well. AS I understand it, you are not to use
"compact" unless you intend not to edit or add any more data to it.
Is that correct?
Thanks so much,
In article <1191012775.846282.182990@d55g2000hsg.googlegroups.com>,
jc@agncs.com wrote:
> On Sep 28, 4:21 pm, "Ursus"
> >
> > berichtnews:1191005886.125223.216990@n39g2000hsh.googlegroup s.com...
> >
> > >I have a file running on Fm 9.0 server. When it backups, I get the
> > > message "verification failed error 664".
> >
> > > Should I use the clone of this file to replace it , save the file as
> > > "compacted clone" or use a recovred file.
> >
> > > Thanks
> >
> > Good practice is to save a clone from your file as soon as you start
> > working. Then when something happenes you have an unused and undamaged
> > clone. Recover is only realy there to recover your data. It is not intended
> > to keep on working with the file. It may seem like the file functions after
> > a recover, but error may still be there and they might re-appear at any
> > time. If you don't have a fresh clone, you are left with an untrustworthy
> > file. You just might try and work with the recovered file. But don't be
> > surprised when it crashes in a major way along the line. An other solution
> > would ofcourse be to rebuild your file from scratch. Safe a clone (just in
> > case) and import the data from the recovered file. I know that almost
> > nobody
> > works like this (storing virgin clones), but it is the only option to be
> > completely safe.
> >
> > Keep well, ursus
>
> Fortunately I have a "clone" of the original. I get so many different
> answers from FM and others. You have to wonder why they offer
> "compact" and optimize when they then come back and say that can
> damage the file as well. AS I understand it, you are not to use
> "compact" unless you intend not to edit or add any more data to it.
> Is that correct?
>
> Thanks so much,
At the 2007 FileMaker Developers Conference, a FileMaker engineer talked
at some length about corruption, saving a compacted copy, recovery of
damaged database, use of clone, etc.
Of course making frequent backups is a basic practice to make it
possible to recover from disaster.
He advocated making backups as compacted copies as a means of avoiding
corruption. There was no indication at all that saving a compacted copy
causes corruption, quite the opposite, it helps to restore integrity and
prevent corruption. Saving a compacted copy rebuilds indexes and
dependencies, and thus corrects errors that can creep in to those
elements.
Doing regular consistency checks of the database is a good way to detect
errors. FMP9 does a consistency check when it opens a database. FM
Server does a more extensive consistency check when it makes a backup.
Saving a clone also rebuilds indexes and dependencies within the
database structure.
Recovering a damaged file is good for recovering the data, but it is
best to import the data into a clone and then use the resulting database.
If no clone is available, you may get away with using the recovered
file, but there is risk of future problems.
Better would be to go to a recent backup, and update any changed or new
records since the backup was made. This gives reasonable assurance of
sound structure, with only the need to update the data since the backup
was made.
Failing that, It may be beneficial to make a clone of the recovered
database, export the data from the recovered database into a collection
of text files (one for each table), then import the data into the clone.
For easiest use the text files should be MERGE files as those preserve
the field names and so make the import easier to set up.
There are some informative knowledge-base articles on the Filemaker web
site,
www.filemaker.com >> Support >> search for "Corruption" etc
--
For email, change
Bill Collins
On Sep 28, 8:34 pm, Bill
> In article <1191012775.846282.182...@d55g2000hsg.googlegroups.com>,
>
>
>
>
>
> j...@agncs.com wrote:
> > On Sep 28, 4:21 pm, "Ursus"
> > >
> > > berichtnews:1191005886.125223.216990@n39g2000hsh.googlegroup s.com...
>
> > > >I have a file running on Fm 9.0 server. When it backups, I get the
> > > > message "verification failed error 664".
>
> > > > Should I use the clone of this file to replace it , save the file as
> > > > "compacted clone" or use a recovred file.
>
> > > > Thanks
>
> > > Good practice is to save a clone from your file as soon as you start
> > > working. Then when something happenes you have an unused and undamaged
> > > clone. Recover is only realy there to recover your data. It is not intended
> > > to keep on working with the file. It may seem like the file functions after
> > > a recover, but error may still be there and they might re-appear at any
> > > time. If you don't have a fresh clone, you are left with an untrustworthy
> > > file. You just might try and work with the recovered file. But don't be
> > > surprised when it crashes in a major way along the line. An other solution
> > > would ofcourse be to rebuild your file from scratch. Safe a clone (just in
> > > case) and import the data from the recovered file. I know that almost
> > > nobody
> > > works like this (storing virgin clones), but it is the only option to be
> > > completely safe.
>
> > > Keep well, ursus
>
> > Fortunately I have a "clone" of the original. I get so many different
> > answers from FM and others. You have to wonder why they offer
> > "compact" and optimize when they then come back and say that can
> > damage the file as well. AS I understand it, you are not to use
> > "compact" unless you intend not to edit or add any more data to it.
> > Is that correct?
>
> > Thanks so much,
>
> At the 2007 FileMaker Developers Conference, a FileMaker engineer talked
> at some length about corruption, saving a compacted copy, recovery of
> damaged database, use of clone, etc.
>
> Of course making frequent backups is a basic practice to make it
> possible to recover from disaster.
>
> He advocated making backups as compacted copies as a means of avoiding
> corruption. There was no indication at all that saving a compacted copy
> causes corruption, quite the opposite, it helps to restore integrity and
> prevent corruption. Saving a compacted copy rebuilds indexes and
> dependencies, and thus corrects errors that can creep in to those
> elements.
>
> Doing regular consistency checks of the database is a good way to detect
> errors. FMP9 does a consistency check when it opens a database. FM
> Server does a more extensive consistency check when it makes a backup.
>
> Saving a clone also rebuilds indexes and dependencies within the
> database structure.
>
> Recovering a damaged file is good for recovering the data, but it is
> best to import the data into a clone and then use the resulting database.
>
> If no clone is available, you may get away with using the recovered
> file, but there is risk of future problems.
>
> Better would be to go to a recent backup, and update any changed or new
> records since the backup was made. This gives reasonable assurance of
> sound structure, with only the need to update the data since the backup
> was made.
>
> Failing that, It may be beneficial to make a clone of the recovered
> database, export the data from the recovered database into a collection
> of text files (one for each table), then import the data into the clone.
> For easiest use the text files should be MERGE files as those preserve
> the field names and so make the import easier to set up.
>
> There are some informative knowledge-base articles on the Filemaker web
> site,www.filemaker.com>> Support >> search for "Corruption" etc
>
> --
> For email, change
> Bill Collins- Hide quoted text -
>
> - Show quoted text -
Bill:
Thanks for that good explanation. What led up to the file being
damaged was when I would pull it off of the backup from server, open
it with FM , I would see nothing but question marks in each field. If
I pressed "show all" the records would show up correctly, But; soon
after that the file "failed" the consistency check on each backup.
Thanks
On Fri, 28 Sep 2007 22:21:56 +0200, "Ursus"
wrote:
>
>
>news:1191005886.125223.216990@n39g2000hsh.googlegroups.com. ..
>>I have a file running on Fm 9.0 server. When it backups, I get the
>> message "verification failed error 664".
>>
>> Should I use the clone of this file to replace it , save the file as
>> "compacted clone" or use a recovred file.
>>
>> Thanks
> I know that almost nobody
>works like this (storing virgin clones), but it is the only option to be
>completely safe.
Oh, I do. Whenever I finish a solution I keep a clone of the final
version after I deliver it to the client. That way if he has problems
I can start him over again. It's amazing how many ways clients can
screw things up even when you try to restrict their access to the
internal workings of a solution.
I even save a series of clones as my apps evolve.
Another use of clones is to manipulate a dataset that is intended for
the main app but that needs massaging first. One can import the
dataset into the clone, see how it fits, and make any adjustments,
before importing into the main app.
--
FW