Verify Integrity is a specific part of the Recover process and cannot be scripted. It does much more than just "going to a bunch of layouts". If you could do it, it would put the same delay on your server as you would through the scheduled back up on FMServer unless you backed up to a different computer on the network and used a copy of filemaker to verify it directly on that machine.
We've dealt with the delay issues from a verified back up on our system by making unverified hourly back ups and scheduling a separate verified back up that takes place late at night.
> unless you backed up to a different computer on the network and used a copy of filemaker to verify it directly on that machine
Yes, that is what I'm planning on doing.
I know verify does more than go to a bunch of layouts. However, when I manually check a database I open it up (just that it opens is a good sign) and then I move around in it to see if everything "looks allright". I just figured there might be something I can do in the script that checks it "better" (whatever that may be).
Yes, we do a verified nightly. I'm just being extra cautious and would like to verify the mid day one.
The only option I can see unless you are backing up to a mac and can do something with Applescript, is that a full recover could be run on the file from a "robot" file on the computer where the file is backed up. You can use a system scheduler to open the robot file and File Options can be set to run this script in the robot file when it is opened. This is a full up recover, however. For a large file, it could take quite a while to run and there's no automated way to report the recover results back to you short of checking the log and recover results manually.
Hmm, wonder if FMDiff could be automated....
BTW, the way we have this figured is that hourly backups are to never be used to replace the actual file, but rather can be used as a data source for importing data into either the original file (oops, deleted a record I shouldn't...) or into one of the verified back ups should that need ever arise...
Hmmm.... My understanding of a full recover is that it trashes the db in order to recover the data which then needs to be imported into a clone, so that seems too damaging just to check it.
I guess my homemade integrity check is more of a sanity check.
We have 70 tables. Importing into a verified backup would be a big job. Yikes!
So you wouldn't use an unverified backup as a production db even if everything "looks ok"?
Recovering the file generates a new recovered copy of the file. The original file is left unchanged. I often run a recover on a client's file as a quick check for issues. I then discard the copy generated by the recovery unless a problem is reported by the recover process.
I wouldn't say that the recovered copy is "trashed". Odds are that it is perfectly OK to use unless recover reports otherwise. It's just that there is no guarantee that the recovery didn't modify the design some way so that it is safer not to use the recovered file if there is any reasonable alternative to doing so.