Hi,

In past couple of months we have had a recurring problem of databases
corrupting themselves such that they show 0 Records. However the first
record remains visible. The other records are inaccessable.

The databases are hosted on FM Server 5.5 under Win2K Server. About 40
different db files are served. This problem so far has only happened on
the largest databases. The problem has recurred the most on a db with
about 60K records of about 200 fields each. It is quite a complext db
with many relational links to the other dbs and lots of fairly involved
scripts. We typically only have about 20-30 users at any given time.

In most cases the Recover function saves us. However in one case this
did not work.

Has anyone else expereinced this?
Is this likely a FM related problem or is it more likely a OS or HD
directory problem?

Regards
Mike

>
> In most cases the Recover function saves us. However in one case this
> did not work.

The Recover function recovers *data* at the cost of database structure.

A Recovered file should *never* be placed back into production.

All the data in the recovered file should be imported to a clean,
never-before-corrupted clone of the database.

If you do not have one, then you should rewrite that database, then import
the data from the Recovered file.

Keep a clean clone copy of all your databases.

Sorry if this is not good news - this subject is covered fairly frequently
here.

See the cdf FAQ postings:
http://heifer.ucc.usyd.edu.au/FMPro?-db=cdf%5ffaq.fp5&-format=faq%5fdetails.html&NavFullCode=3f13&-find
and
http://heifer.ucc.usyd.edu.au/FMPro?-db=cdf%5ffaq.fp5&-format=%2fcdf%5ffaq%2ffaq%5fdetails.html&NavFullCode=3f64&-find

Cheers

Webko

Corruption is corruption.  However, unless you have a clean backup or 
you want to rebuild the database from scratch, here's something you can 
try.  It may resolve the issue completely, it may not.

I imagine that even in the bad file, you can perform a find and it will 
show you the proper records.  But the total record count is incorrect 
and Show All Records will not work.

Create a clone of your database (File > Save As > clone).  You're going 
to want to open the clone and import all records using matching names 
from the bad file.  The tricky part is getting the found set to show all 
records.  As mentioned above, Show All Records will not work.  Instead, 
you'll need to go to a field that you are positive has data in it for 
ALL records.  Find in that field by using an asterick for a text field 
or >0 for a number field.  Once you perfrom the find, it should be all 
records and you can do the import.  This should reset the counter for 
you.  Now just make sure your clone is named properly to replace the bad 
file.



Sleepy wrote:
> Hi,
> 
> In past couple of months we have had a recurring problem of databases
> corrupting themselves such that they show 0 Records. However the first
> record remains visible. The other records are inaccessable.
> 
> The databases are hosted on FM Server 5.5 under Win2K Server. About 40
> different db files are served. This problem so far has only happened on
> the largest databases. The problem has recurred the most on a db with
> about 60K records of about 200 fields each. It is quite a complext db
> with many relational links to the other dbs and lots of fairly involved
> scripts. We typically only have about 20-30 users at any given time.
> 
> In most cases the Recover function saves us. However in one case this
> did not work.
> 
> Has anyone else expereinced this?
> Is this likely a FM related problem or is it more likely a OS or HD
> directory problem?
> 
> Regards
> Mike

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance

Thanx for the advise. I doubt if we have a backup that has not been
touched by this. 

However this seems quite strange to me. One would have thought that the
"Recover" function actually built a new database using the data of the
old. Not just make a copy of the corrupt container then try to fill it.
I suppose that its possible the stucture could be lost, in which case
it should tell me that it had a problem recoverring structure. Is it
possible to recover data without knowing the structure? Your URL seems
to be to one of your own recommendations which is fine (BTW one of them
is dead), but it would be interesting to know what the actual recover
functions are that are being carried out.


In article <cbo7fv$hmt$1@spacebar.ucc.usyd.edu.au>, Tim 'Webko' Booth
<T.Booth@isu.usyd.edu.au> wrote:

> >
> > In most cases the Recover function saves us. However in one case this
> > did not work.
> 
> The Recover function recovers *data* at the cost of database structure.
> 
> A Recovered file should *never* be placed back into production.
> 
> All the data in the recovered file should be imported to a clean,
> never-before-corrupted clone of the database.
> 
> If you do not have one, then you should rewrite that database, then import
> the data from the Recovered file.
> 
> Keep a clean clone copy of all your databases.
> 
> Sorry if this is not good news - this subject is covered fairly frequently
> here.
> 
> See the cdf FAQ postings:
>
> http://heifer.ucc.usyd.edu.au/FMPro?-db=cdf%5ffaq.fp5&-format=faq%5fdetails.ht
> ml&NavFullCode=3f13&-find
> and
>
> http://heifer.ucc.usyd.edu.au/FMPro?-db=cdf%5ffaq.fp5&-format=%2fcdf%5ffaq%2ff
> aq%5fdetails.html&NavFullCode=3f64&-find
> 
> Cheers
> 
> Webko
> 
>

I don't think this solution would work for our case becasue no records
are accessable. Find will not work at all....grayed out. However I have
to ask in light of Tim's comment: wouldnt cloning the db result in the
same problems as allegedly caused by using the recover function? ie if
the structure is damaged wouldnt the clone also be damaged?

Anyway, guys, the real question I have is is the nature of the
corruption Ive described common? Is the kind of corruption where the
record count goes to 0 a symtom of FM server or a bad direcory
structure? The reason I ask is that Ive seen this now on a few
different dbs and they are not all related. Do I need to change my
platform?

cheers
mike


In article <10dvde7jk2vbmae@corp.supernews.com>, Howard Schlossberg
<howard@antispahm.fmprosolutions.com> wrote:

> Corruption is corruption.  However, unless you have a clean backup or 
> you want to rebuild the database from scratch, here's something you can 
> try.  It may resolve the issue completely, it may not.
> 
> I imagine that even in the bad file, you can perform a find and it will 
> show you the proper records.  But the total record count is incorrect 
> and Show All Records will not work.
> 
> Create a clone of your database (File > Save As > clone).  You're going 
> to want to open the clone and import all records using matching names 
> from the bad file.  The tricky part is getting the found set to show all 
> records.  As mentioned above, Show All Records will not work.  Instead, 
> you'll need to go to a field that you are positive has data in it for 
> ALL records.  Find in that field by using an asterick for a text field 
> or >0 for a number field.  Once you perfrom the find, it should be all 
> records and you can do the import.  This should reset the counter for 
> you.  Now just make sure your clone is named properly to replace the bad 
> file.
> 
> 
> 
> Sleepy wrote:
> > Hi,
> > 
> > In past couple of months we have had a recurring problem of databases
> > corrupting themselves such that they show 0 Records. However the first
> > record remains visible. The other records are inaccessable.
> > 
> > The databases are hosted on FM Server 5.5 under Win2K Server. About 40
> > different db files are served. This problem so far has only happened on
> > the largest databases. The problem has recurred the most on a db with
> > about 60K records of about 200 fields each. It is quite a complext db
> > with many relational links to the other dbs and lots of fairly involved
> > scripts. We typically only have about 20-30 users at any given time.
> > 
> > In most cases the Recover function saves us. However in one case this
> > did not work.
> > 
> > Has anyone else expereinced this?
> > Is this likely a FM related problem or is it more likely a OS or HD
> > directory problem?
> > 
> > Regards
> > Mike

Sleepy wrote:

> I don't think this solution would work for our case becasue no records
> are accessable. Find will not work at all....grayed out. However I have
> to ask in light of Tim's comment: wouldnt cloning the db result in the
> same problems as allegedly caused by using the recover function? ie if
> the structure is damaged wouldnt the clone also be damaged?

If Find is not accessible with your password, then you need to get a 
master password.  Or, if you had to for some reason, then perform a 
recovery and then find all your records.

The DB clone might still contain some corruption.  This is an interim 
solution so that you can use your data.  But the record count issue will 
most likely be resolved by doing as I explained.  A clone resets the 
initial record count to zero so that as you import, the counter remains 
accurate.  The problem with your bad db is that the counter, through a 
crash or some corruption, has reset itself to zero in the middle of your 
database; any total record count that you see when you do a 'show all 
records' is the count since it was reset to zero.

This, by the way, should never be an issue in FMP7, but it is in prior 
versions.

> 
> Anyway, guys, the real question I have is is the nature of the
> corruption Ive described common? Is the kind of corruption where the
> record count goes to 0 a symtom of FM server or a bad direcory
> structure? The reason I ask is that Ive seen this now on a few
> different dbs and they are not all related. Do I need to change my
> platform?
> 
> cheers
> mike
> 
> 
> In article <10dvde7jk2vbmae@corp.supernews.com>, Howard Schlossberg
> <howard@antispahm.fmprosolutions.com> wrote:
> 
> 
>>Corruption is corruption.  However, unless you have a clean backup or 
>>you want to rebuild the database from scratch, here's something you can 
>>try.  It may resolve the issue completely, it may not.
>>
>>I imagine that even in the bad file, you can perform a find and it will 
>>show you the proper records.  But the total record count is incorrect 
>>and Show All Records will not work.
>>
>>Create a clone of your database (File > Save As > clone).  You're going 
>>to want to open the clone and import all records using matching names 
>>from the bad file.  The tricky part is getting the found set to show all 
>>records.  As mentioned above, Show All Records will not work.  Instead, 
>>you'll need to go to a field that you are positive has data in it for 
>>ALL records.  Find in that field by using an asterick for a text field 
>>or >0 for a number field.  Once you perfrom the find, it should be all 
>>records and you can do the import.  This should reset the counter for 
>>you.  Now just make sure your clone is named properly to replace the bad 
>>file.
>>
>>
>>
>>Sleepy wrote:
>>
>>>Hi,
>>>
>>>In past couple of months we have had a recurring problem of databases
>>>corrupting themselves such that they show 0 Records. However the first
>>>record remains visible. The other records are inaccessable.
>>>
>>>The databases are hosted on FM Server 5.5 under Win2K Server. About 40
>>>different db files are served. This problem so far has only happened on
>>>the largest databases. The problem has recurred the most on a db with
>>>about 60K records of about 200 fields each. It is quite a complext db
>>>with many relational links to the other dbs and lots of fairly involved
>>>scripts. We typically only have about 20-30 users at any given time.
>>>
>>>In most cases the Recover function saves us. However in one case this
>>>did not work.
>>>
>>>Has anyone else expereinced this?
>>>Is this likely a FM related problem or is it more likely a OS or HD
>>>directory problem?
>>>
>>>Regards
>>>Mike

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance

in article 280620042000236754%ticked.off@really.bad, Sleepy at
ticked.off@really.bad wrote on 6/28/04 5:00 AM:

> Anyway, guys, the real question I have is is the nature of the
> corruption Ive described common? Is the kind of corruption where the
> record count goes to 0 a symtom of FM server or a bad direcory
> structure? The reason I ask is that Ive seen this now on a few
> different dbs and they are not all related. Do I need to change my
> platform?

Take a look at this article by Gregory Durniak:

Damaged Files and Hidden Corruption in FileMaker Pro

http://masdevelopment.com:3455/1/57

HTH

Lee

Thanx Lee, a very informative article indeed. We will try the clone
then import the recovered data method and watch it closely. But I agree
fully with the article's author, its hard to understand why FM cannot
come up with an efficient way of checking file integrity...ie if
converting to FM7 fixes it then its obviously possible to detect and
correct, which is what I expect the "recover" command to do.

cheers
mike


In article <BD057B25.8A01%canepa6645@charter.net>, Lee Smith
<canepa6645@charter.net> wrote:

> in article 280620042000236754%ticked.off@really.bad, Sleepy at
> ticked.off@really.bad wrote on 6/28/04 5:00 AM:
> 
> > Anyway, guys, the real question I have is is the nature of the
> > corruption Ive described common? Is the kind of corruption where the
> > record count goes to 0 a symtom of FM server or a bad direcory
> > structure? The reason I ask is that Ive seen this now on a few
> > different dbs and they are not all related. Do I need to change my
> > platform?
> 
> Take a look at this article by Gregory Durniak:
> 
> Damaged Files and Hidden Corruption in FileMaker Pro
> 
> http://masdevelopment.com:3455/1/57
> 
> HTH
> 
> Lee
>