Recover Command: Part II

[SteveB]

This is a continuation of my last posting about the Recover command. Live Oak suggested a UPS since he seems to think it's a rare occassion. I believe it happens more frequently than Filemaker admits. I'm using FM5 on Win98 and trying to built a Kiosk solution that has 4 files that appear as one to the user. My goal was to trap the error about using the Recover command, and then just replace the file with a backup copy.

In the last 8 months of using FM5, I have had a number of files get clobbered and require recovery. I believe this happens if Windows freezes as FM is in the process of updating its indexes. On rare occassions the file has not been recoverable (layouts and fields missing)...obviously very scary stuff. So, rather that force a user deal with Recover and then renaming a file, and then not knowing whether the file's integrity is okay, using a backup copy is a better solution.

In a Kiosk, for those of you who have never created one, all of the FM menus and commands are eliminated. Without the menus, there is no way to recover a file, since if the command is put on the topmost menu and the main file needs recovery, your dead. My main file has no data records, just some scripts and layouts so it is not likely that it would get blown, but I don't want to take the chance and and get bitten down the road.

Has anybody had any experience with trying to trap and handle the Recover command?

[john.daly]

I'd go with LiveOak on this one. If the file is corrupted, it won't open and so your script will not even start to run. You can Recover a file however by holding down Ctrl and Shift whilst trying to open it. The damaged file is then renamed as OldFilename and the recovered file is given the same name as the original. The user can then open it in the normal way. They ought to be able to cope with this with a little guidance. This definitely works with the runtime version as I have frequently had to get people to use it as a result of crashes in Windows! If you automaitcally back up the file every time it closes then you can also include a script to reinstate the back up if you ever require it.

[LiveOak]

If you a creating commercial kiosks and file corruption is a large issue due to Windows crashes, how about switching to the Mac platform? Several thing then become possible. Daily automatic startup and shutdown eliminate a lot of system heap issues. A very good accoustic touch screen iMac is available from Elo. File corruption issues on stand-alone machines running say OS 8.6 seem very rare. An additional option is to run a persistent RAM disk program such as RAMBunctious, which in our experience enhances stability and gives about a 3:1 speed bump. If crashing is creating a large economic impact, the difference in price between an inexpensive PC and an iMac should not be an issue. -bd

[SteveB]

Don't you guys ever read anything completely? I'm doing a KIOSK version on WIN98, not on a MAC, not with WIN2000, and not as part of an IS department. The product is a general system to maybe thousands of single users on PCs scattered over the entire country. I can't handhold each one of them.

First, the recover command does NOT rename the bad file and rename the new one with the old name...it calls the recovered file

"....Recovered". Then the user must rename it.

Second, I just built a Kiosk version with the corrupted file. First, FM Developer allows that to happen which it shouldn't. Second, I get the message about needing to use the Recover command, but KIOSK programs DON'T HAVE a recover command, just the IDIOTIC message, and it leaves the user hanging in the KIOSK. You have to terminate the KIOSK with a Ctrl-Del to get back to the desktop.

Third, FM's own documentation expressly states that you should never use the corrupted file, except to export the records into a clone.

Now, does anyone have any useful ideas?

[Chris Wood]

Hold your shirt on (to coin an old English saying). I know that developing databases can test ones patience, but take it out on your wife/lover/girlfriend but not on the nice friendly and helpful guys on this forum. :-)

This is how I think it works with my runtime kiosk databases running on Windows NT 4 and FM 5.0.

If the Kiosk version fails to start due to corruption, you have to exit it either by pressing Alt + F4 or by pressing Ctrl + Alt+ Del and using the task manager to close the file. Also, when the screen is black, pressing Alt + Tab will allow you to select another open application or the desk top. Once out of the damaged file, open Explorer and find the folder and file; pressing Ctrl + Shift while double clicking the offending file brings up a dialogue box for opening the damaged file and asking for a name for the recovered file. Give it the same name as the damaged file and press OK. The damaged one is renamed .....OLD and you have a recovered file with the same old name.

Now, I have only done this with an OK file to see what happened becasue I have never had a damaged kiosk file. Fortunately with my product, the client can just re install the original file from CD-ROM. My application is only a source of data with no changes being made by the client.

Hope this helps.

Chris

[SteveB]

Thanks for your comments Chris. I've come up with a solution, which is not perfect but accomplishes replacing the corrupted file (I happen to have a saved one to test with) with a backup copy. Although I can't supress the FM5 error message, I can tell that the user hit the Cancel key on the Open File after the original Open fails. Cancel returns a "1" from Status(CurrentError). Exit the Kiosk and run a standalone 'Recover File' Kiosk that does nothing more that replace the user's files with the most recent backup, which I automatically create every time the user exits the Kiosk. I will even try to automate the closedown and startup, given that the Cancel code is known and trapped.

[LiveOak]

Good deal! Sounds like you are a lot closer to an workable solution. I think the initial confusion in the responses was the use of the word "kiosk". This solutions is really a "runtime" solution which doesn't really run on a kiosk you control, but rather on a wide variety of end user machines (correct?). -bd

[This message has been edited by LiveOak (edited February 15, 2001).]

[SteveB]

Well, the FM manual calls the thing a Kiosk and it doesn't differentiate whether it is a true stand alone, or it always has a support person(s). Its primary charateristic is that it only depends upon the menus that I've included and none of the FM ones.

It seems that when the system detects that the user hit the cancel key on the Open (after trying to recover), this stops all scripts from running, so I can't figure out how to automate the process. I can, however, detect that the user cancelled, but I havn't been able to go beyond this point. Drats!!!

[SteveB]

I did go beyond just detecting the cancel. I switch to another file that handles the restores automatically from a backup folder. The only thing I can't do is suppress the error messages.