File maintenance

[pigslow]

I am running 2 filemaker files on a filemaker advanced 7.03 server running on a WIN 2003 server. One has 37 tables and holds the majority of all of the data. The second file has 10 tables and is used as a dumping ground for a data exchange between a MySQL database and the main Filemaker database. The main database is also quite large. The largest table has 700,000 records and is still growing at a good rate.

At times I have had some serious issues with script running and never stopping or just running far longer than normal. Three weeks ago I did a recovery and then created a compact copy of those recovered files and everything seemed to be a lot better.

I have since read that exporting the data, creating a clone and then importing the data into the clone may be a better and safer solution. Can anyone comment on this? I would like to know what the best practice is for keeping this database running in good shape and how often I should do so.

If exporting is the way do I have to do an export from each table then import back into each table. I can't seem to find any easier way.

[Wim Decorte]

Recovery is not a file maintenance mechanism. It is meant to recover a crashed file to a state where you can get the data out and import the data into a known good backup. To do that it will sacrifice anything that it feels might be corrupt (data, field definitions, layouts, scripts,...).

Compacting a file is usually all the file maintenance you will need. Best way to do that is to take the file down from the server.

Importing into a clone would work too but it is a lot more work and potentially dangerous if you forget to reset the serial numbers or accidentally toggle the "perform auto enter" on import.

[pigslow]

Thank you for the reply. I am not sure why but my database is not as heathy as others I have worked with. It tends to not want to run scripts after it has run for a while without some form of maintenance.

[Wim Decorte]

When it happens, step through the scripts with script debugger and see where the slowdowns occur. Should give you a clue as to what is going on...

[pigslow]