Global_.fp5 corruption

>Correct, that's how it would be done.

That is how it was done. If I replace the fp5 files with a backup copy, fm reports damaged Global_.fp5; but if I uninstall og, then replace the installed default dbs with the same exact backup, it works (kinda, all payments, expiration dates and billing cycle items are gone) There must be another remaining element that doesn't like the backup dbs, which forces a reinstall. Can you look at the optigold database and determine what's wrong? I've been trying to do this by the book (which never showed up) and this is a drastic failure that needs to be resolved. The data must be in there.

 

> You can email support if you want them to look at it, although truthfully, they aren't > going to be able to tell you anything other than yes it's corrupt or no it's not.

I translate that to: "your data, your problem". You may be right; however, for optigold to be of any use I must determine where it all went wrong. How can I prevent this from happening in the future and what backup strategy can recover fully from such an odd disaster. These backups, though performed correctly, are utterly useless. Will this happen again in another month? Nobody knows. Is filemaker breaking or is optigold? What would you do if you were here?

 

I managed to combine some databases from an earlier backup with my newest backup, like Global_ and Invoices_ and Export_. I ran a recover on those three older files and copied them to the current structure; this is the only combination that worked for me. The recover function would not create a usable file, if performed on the newest versions of the fp5 files.

Compared to earlier, my work/verification will be minimal. Whew. Thanks for sticking with me on this forum. I hope this dialog can help somebody else, but my situation may have be unique.

Filemaker now performs weekly and daily backups to a different volume. The simplicity of the interface does not create much variability in the backup process, leading me to believe that may not be the culprit. It could have been network problems, bad memory or HD sectors, or good ol bad luck. I plan on writing a batch file or something like this psuedo:

sc filemaker stop
copy *.fp5 g:/backup
foreach file in *.fp5
md5sum file vs g:/backup/file > integrity.log
sc filemaker start

It's been said many times before, and may be in the works, but I really think you ought to scrap filemaker for some sql variant. I could have had a less caveman approach to the solution (combining database components from varied backups) if the backend was a more common standard.

 

I currently have this same exact problem. Global_.fp5. Optigold states that "it can not read the disk that the file is on!" I can copy the file to another disk, replace with a backup and get the same error.

I'm running on a Mac G5 os X if there was a problem with the disk, my os would report it prior to Optigold ISP starting.

Does digital point have a file recovery service?

I have called x 2 and emailed with no response....I'm finding this is the defacto S.O.P. for Digital Point.

 

Here's a quote from Support Services [support@digitalpoint.com] (James)

art wrote:

> We seem to be experiencing a problem with the file
> Global_.fp5 in our optigold isp software. I get an error stating that
> ³Sorry, filemaker is unable to read the disk that this file is on.²
> When we try to use the backup, we get the same error. It appears that
> the problem is in the file and not on the disk, as the disk checks out
> fine. I have copied the entire directory to another disk and get the same error. Have you ever seen this problem before?

No, I have not. Have you tried to recover the file?

james

 

One thing I've noticed and have had to go through when doing non-filemaker server initiated backups is make sure NO ONE is connected and has OPtigold databases open.....make sure all clients log out, then check the filemaker server admin (not filemaker server prefs/control) and make sure all guests are logged out, then shut down fmserver...... I've found that if a client is still logged in when I shut down, I get corrupted fm files.... this is not the case with the built in fmserver backup, which I just point to backup to an SMB share on one of our SNAP servers.....

Also, it's a good practice when simply shutting down filemaker server (restart/maintanence etc..),to kick off or log off direclty the guests in the admin then shut down (this includes auto-task machines and web interface machines)... that solved most of our flakey issues with fm and corruption...Although, on a side note, I had a ups fail on the Dual G5 we have fmserver running and simply lost power, even though the generator came on, still took down the box, and to my surprise (this was mid day) when restarted, fmserver reported no corrupt databases...I was soooo happy, 2 hours to recover the databases averted

Jon.
Other World Computing