pro is not checked

[Gregory_I]

Over the weekend my server was rebooted due to a Microsoft windows update. Upon restart I notice (1) hoested database out of 15 was closed and did not start automatically within FM Server 9.0. I gues thee database was corrupted with the shut down so I performed a recover on the databaseusing 9.0. BTW the origional file was created and hosted with FMP 7.0 before I upgraded to 9.0. After the recover the database works good. There is a check mark missing in the "pro column" on the server main screen. I am not sure why this happened and even if it is relevent. All of my other files have a check mark. Can anyone give me any insight to the "pro column" and why a recover would have removed the check mark. Also, why did I need to do a recover in the 1st place for only (1) database when I was hosting all 15 at the same time? Thanks Greg

[Colin Keefe]

The Pro column is the extended privilege bit in the file that permits users to access the hosted file via filemaker client. All the columns in that view indicate extended privilege bits of one kind or another.

You only needed to recover one out of 15 files because only one was damaged during the crash/reboot. Why only one was damaged...well, without knowing anything about the files, or the server environment or the event log, sort of a tough question to answer. But generally the state of a hosted FileMaker file is continually changing as data is written to it from the cache. A crash during a cache write would leave a file incompletely written, and therefore damaged.

By the way, you'd probably be better off importing data from your recovered file into a clone of a last known good backup file (you do have one, don't you?). The Recover routine enthusiastically trashes damaged file components in an attempt to get the data in a retrievable state. So there may be hidden changes to your file you don't know about yet - like missing layouts or recovered fields, etc.

[AudioFreak]

Honestly what I do not get is why Filemaker inc has not added a message to the recovery process that alerts the user that doing this will make the file unusable and should only be used to recover data.

If we were writing a script that allowed users to do this themselves we would surely put a Custom Dialogue within the script.....

Michael

[Colin Keefe]

Yeah, good point. It is made pretty explicit in the Help file that rehosting a Recovered file into production isn't necessarily best practice:

Special notes on recover

In general, recovering a file should be reserved for files that will not open, or are displaying index problems. Databases that are returning records incorrectly from a find should be fixed by recover.

The Recover command aggressively attempts to correct a file so you can open it and recover your data. To do this, the Recover process may delete corrupt fields, layouts, layout objects, scripts, and data. For this reason, you should only use the Recover command when you cannot open a file. Do not use this command for regular file maintenance.

Note Keep in mind that there are many other conditions that will return incorrect find results, including mismatched field types. Be certain you have eliminated all other possibilities before recovering a file.

But who reads help files? Recover's purpose is so frequently misunderstood that it does deserve some special notice in the application interface, not just the help file.

[Gregory_I]

Did the recover and import. Things are back to normal. Still not sure why a recover would have changed the Extended privilages setting. The only thing I can guess is that The file was created using 7.0 and recovered using 9.0.

[AudioFreak]

Did the recover and import. Things are back to normal. Still not sure why a recover would have changed the Extended privilages setting. The only thing I can guess is that The file was created using 7.0 and recovered using 9.0.

Doing a Recovery will destroy what ever Filemaker thinks it needs to destroy to "Recover" your data. I'm guessing you don't have a known good backup? As pointed out it's not good practice to use a recovered file.

Michael

[Steven H. Blackwell]

Concur with comments about Recovered files. But that's not the issue here.

[color:red]Automated updates, both software and firmnware should never, ever, be installed on a FIleMaker Server. This is one of the worst things you can do to a FileMaker Server,

Use the Notify option instead, then download the software update. Then wait a week or so to see if anyone is reporting that the OS update orpatch brokeany partof the FMS functionality. And that happens frequently to any number of products.

Steven