defining relationships 1

[ztothaizzo]

Hey ... we had a server crash and our main database had to be recovered. it is working well now howver the related databases dont seem to be synching. can i delete the relationship and then re add it as new with the same settings?

 

[JeanW]

If the relationships are not documented somewhere, it will be a hell of a job to rebuild the left and right pane values...so, yes it's doable...

Better would be to find out why the related are not sinc.

What is your definition of 'the related databases dont seem to be synching'.¿

 

[ztothaizzo]

my definition of the syncing problem is that we have a main database which apparently is clled up and related to other databases' The Main database needed to be recovered and once recovered the othe databases open however it keeps saying the the "Main" cant be found and is required to complete this operation... it shows up in the defined relationship however i have a feeling that i either didnt recover it correctly or something?

So is there another way than deleting and then making a new relationship and point to the same file? or is that the best way...

thanks for your help

 

[JeanW]

Before we're going too far in the wrong direction...

Can you give me all the single steps you did to recover the main file ?

 

[ztothaizzo]

yes... i tried to open the database and it said that it needed to be recovered. so i went recover... file.. then i renamed it and trashed the corrupted file.. i was reading yesterday and found that that may have not been the a[ppropriate procedure... i do have a back up on a harddrive if recovering an old file would be better.

 

[JeanW]

NEVER use a recovered file...

Import the data into a clone of a known-good backup of the file. Do NOT put the recovered file back into use.

Recover 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,...). If you want more details on how FM does the recovery....

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.

Now, what is a known good backup ?

You're working on a development copy of your program, and then import the data into a clone of the development copy. But you have no way of knowing whether your devel copy is clean. It works. But caution, even though it's working, you might still have corruption somewhere in the file.

Example : a file that crashes only when two guests are on the same list layout, and a script is triggered to set a number field. This file ran for a full year before the corruption was discovered ( All the backups were corrupted ).

See Answer ID 2943 in the FM knowledge base for a technique.

There does not seem to be any way to be sure that your FM files are not corrupt, and there do not seem to be any tools that will assure a developer that their files are not corrupt.

So, essentially there is no way to use a "known-good backup", as there is no way to be certain that ANY Filemaker file is clean. One can be somewhat sure or even pretty sure, but there is no foolproof guarantee that the file you are using as your known-good backup isn't harboring some hidden corruption that will some day reach out and bite you.


HTH

 

[ztothaizzo]

so you are saying to use the database file which was backed up before the problems started and then import that info into a clone?

or are you saying im screwed?

thanks for all your help on this

 

[JeanW]

>> so you are saying to use the database file which was backed up before the problems started and then import that info into a clone?

Yes, use the data from the backup file in an empty clone.

>> or are you saying im screwed?

Don’t think so, but you need to follow a procedure/strategy to avoid problems in the future.

Otherwise you probably have to rebuild from scratch to be sure there isn’t corruption in the file.

FWIW, this is one of mine procedures...


When you need to protect the database's structure as well as its contents, you need to consider adopting a strategy that stores each of the pieces separately. This means saving the structure of your database as a master clone, and exporting its contents to a storage file of a type appropriate for the data the file contains.

The Basics
1. Save a master clone of your FM database. A clone is the database's structure minus its records, and a master clone is simply a clone that is used only as a source for other clones. By NEVER opening the master clone directly, you greatly reduce the possibility that the file structure will become corrupt. When you need to use the clone, you duplicate it and use the copy. Any time you make changes to your file's structure (create or delete fields, change your layouts, change scripts) you will need to save a new master clone. Place your new master clone in a safe place to prevent it from accidentally being opened.

2. Export all of your data from the database to a storage file. If your database consists entirely of textual data, a Merge formatted text file is a good choice for this purpose, as it creates an extra record at the beginning of the dataset that identifies each field, (very helpful if you ever need to put the separate pieces of the file back together again). If the database contains calculation fields and/or container fields, then you should export the data as a FM file. FM will create a new, blank database structure, and move your data into it.

The resulting file may be considered 'brand new.' Save your storage file in a safe place so you can go back to it when you need to.

One advantage of using a text file format like Merge is that the resulting file can be opened in a word processor or spreadsheet application, if necessary, and edited or printed. Also, because a file in this format also saves the names of the fields and their export order at the top of the document, FM can open it, by itself, as an actual database (albeit without the layouts you developed). When saved in a Merge formatted text file, data that once took up megabytes of hard drive space will now be much smaller, often small enough to fit on a floppy disk.

Creating a master clone
1. With the database open, go to the File menu and select the Save a Copy As... command. Select Clone (no records) from the menu to save a clone of your database file.

2. At this point, you have a clone with no records, but you may also have a file structure that is possibly damaged due to corruption carried over from the original file. This clone needs to be recovered. Do not open the clone. Go directly into the FM File menu and select the Recover command. Select the clone in the dialog box and begin the recovery process.

Exporting to your storage file
1. Find the set of records that you wish to export.

2. From the File menu, select Import/Export:Export Records. Choose the file type for your export. Select an appropriate destination (backup volume, removable media, etc.). Give the export file a descriptive name, e.g., 'BlaBla Jul05 to Aug05.txt'

3. Select the fields for export, and their order.

4. Export your found set.

• When exporting data, remember that FM will only export the 'found set.' If you need to export ALL of your records, be sure to first choose Find All from the Select menu. If you only want to export a specific group of records, do a Find for them first, then export.

• If you want to export only records that have been recently modified, do a Find for the date range in a Date Modified field, and then export.

• If you have no uniform criteria for the set of records you want to find, create a text field and call it Check. As you scroll through your records, place an 'X' in the Check field, then do a Find in this field for this value. You now have your found set and you can export it. (If you want to export the majority of your records, do the reverse. Check the ones you don't want to export, do a Find and Omit for 'X', and you will then have the group you do want to export.)

• In the Specify Field Order for Export dialog box, be sure that each field you want to export is clicked and moved over to the export order. If there is a field whose data you do not want to export, do not click on the field to move it over.

• Leave the Don't Format Output radio button selected before you press OK. You will want your clone to do the field formatting of your data.

• Consider creating a FM script, to run automatically when the file is closed, that will perform these backup procedures.

Restoration Procedures
1. The clone is now your working model. Use a copy of it only when you need to have a new structure available to re-import data. Never actually use your Master Clone to import your records; always keep it as your backup clone. If you need to use it, duplicate the file. Move the duplicate to a working folder and use it to import your merge file.

2. Once the clone is opened, go to File menu and select Import Records. Import the records and you will have a new, clean database, smaller in size.

3. If you decide to change any layouts, save another clone to update your Master Clone. Again, save your data to a storage file to maintain a backup of the data. If you find your data is too large to continue saving as a single document, you may want to do a Find for records that have been modified recently and export that found set to a stand alone format of an appropriate file type.

HTH

 

[JeanW]

After this backup/restore procedure, make sure your main file has the same name as the 'old' one.

If related files are asking for the main file, follow the steps given by FM to locate the main file.
Changes are you can re-establish the relationships.

 

[ztothaizzo]

couldnt i just copy the backed up data base files (known to be good) over the existing recovered and possibly corrupt files?

 

[JeanW]

>>couldnt i just copy the backed up data base files (known to be good) over the existing recovered and possibly corrupt files?

Do it the other way round.
Make a copy from the known to be good files (clone, no records).
Inport the data from the recovered file.
Rename the clone, check all the data.
When you're sure everything is ok (maybe minor changes to do), delete recovered file.

 

[ztothaizzo]

why would i need to import the data from the recovered fie.. the good file was backed up the day before the problem started why not just use the backed up file as is?

 

[JeanW]

If there is no difference (in data) between the backup file and the recovered, why not just make a copy from the backup and use that one.
Why do you want to copy the data from the backup 'over' the revovered ¿

 

[ztothaizzo]

thanks for all your help... things seem to be working ok...for now.. my only problem now is that our filemaker pro server wont stop when i prompt it to. I eventually have to restart the server which i hate doing... any idea why it wont stop?

 

[JeanW]

Your first post was ....server crash...

Did you a re-install from FM ?

Have you checked the permissions on the database files? This usually isn't an issues with Server 5.5, but worth checking.

Have you checked the firewall options.

What does the event.log file say?