This is not typical behavior. We use FileMaker here 8am - 5pm, 6 days a week with very few problems on Windows Xp. I've just started using a brand new Windows 7 lap top and FileMaker has been very stable on it.
Are these issues occuring with a specific file or group of files?
If you create a brand new file from scratch (just a test file--not a full up solution), does it exhibit the same issues?
The database file is being served by FileMaker Pro Advanced 11 v03 and it is quite large. I believe it's at 1.1 GB in size. Looking at the server admin we normally have 20 to 22 people logged into it from 8am to 3pm. We have no pluggins running on the server or the clients, and all the clients exceed the minimum hardware specs. We've been doing OK until late last month when I noticed a co-worker's FileMaker client crash.
Since then, the reports from users has steadily increased.
I'd take a back up copy and perform a recover on that copy (you can leave it to run overnight perhaps) to see if the recover reports any problems. You may have a damaged file that needs to be replaced with a back up copy that isn't damaged.
Nice thought, but that isn't going to work. We make hourly backups and this started about a month ago. Besides, if it was a corrupt file, wouldn't filemaker server be the one that would be crashing or reporting an error?
I guess I will report it again to FileMaker Support and hope they a better idea of what's going on.
We make hourly backups and this started about a month ago.
Corruption can be "latent" it can occur but not be immediately noticed. That's one reason to create an archive of multiple back ups so that you can work back through them until you find a "clean" copy and then you have the fun task of restoring data, added/changed since that back up.
Besides, if it was a corrupt file, wouldn't filemaker server be the one that would be crashing or reporting an error?
No, corruption manifest itself many ways. Client crashes but no server crash is definitely a possibility. You can have corruption and not have any crashes at all. The system may appear to work fine, except finds and sorts on a given field may not work as expected, or a script may not produce expected results... Sometimes you don't discover the problem until you upgrade your server or clients to a newer version or change platforms when you then get a crash when you didn't have crashes before...
Even if you recover the file and it recovers with no problems found, you can't rule this possibility out.
"Corruption can be 'latent' it can occur but not be immediately noticed."
That's not good. We do have an archive but our database has (seriously) 197 tables, with just as many layouts and twice as many scripts. We have 3 other people who work on it besides me. There is no way to determine where the break happened since it only happens once or twice a day and only on half of the clients.
"No, corruption manifest itself many ways."
Ok. More reasons why we shouldn't have done this project in FM. I was thinking ASP.NET with a SQL backend but it would have been much slower to develop than FM. I guess there's there's always Iron Speed Designer.
Rereading your comments from earlier and last month in this post... when you said "I'd take a back up copy and perform a recover on that copy". I took the word "recover" and thought you meant "recover = move a copy out of back up and use it". Not Recover as a function of the application under the "File" menu.
So I did the "recover function" on a copy and it found some problems. Here's its summary report:
File blocks: scanned and rebuilt 310691 blocks, dropped 0 invalid data blocks.
Schema: scanned fields and tables, 2 items modified
Structure: scanned; 3 items modified.
Field indexes: rebuilt.
Now the log file is 11470 lines long. What exactly am I looking for in here? Is there a phrase I should be searching on... like :::ERROR::: or "Oops"?
And once I find out what the problem is I shouldn't use this recovered file... I get that. But if its a table should I create a new one by hand and change all the relationships, etc and if it's a layout... make a new one? Seems strange that the recover function doesn't make a database that's usable.
Most of the time, recover makes a database that is usuable, it's just that you are trusting a "robot" that has no idea how your originally designed the file to get everything back to the original state you need for it to function correctly. That's why I recommend finding a back up, running a recover on it and then repeating this with older back up copies until you find one where recover does not report an issue. You then save a clone of this back up and import all the data from your original recovered copy and updating next serial value settings as needed--a process that can be scripted--which can free to do other stuff while Filemaker grinds through all the data if this is a very large file.
If you can't find a clean back up that you can use, you have two choices:
Perform a lot of tests on it to confirm that it is working correctly and cross your fingers that all is good. Likely it is, it's just that there's a small chance that it isn't ok.
Analyze the recover log and try to identify what problems where found during the recover. Delete those parts of your system (could be a layout, script or entire tables. Run a recover to see if you now have a "clean" result. Then carefully rebuild the database. You might take the chance of importing/pasting elements from the damaged file, but if you do, use recover to test the results after every such change to make sure you aren't bringing a damaged item into your remodeled file.
And I truly regret being the bearer of additional bad news, but your recover may not have found an actual problem at all as there's a bug in the recover process that can trip this warning when there was no damage to begin with:
For More Information see: FMPA 10: group graphic + align = corrupt file?
This is one of many acknowledged bugs that can be found in the Known Bug List here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
If you think that this might be the case, take a copy of your file, ungroup all objects on all layouts and see if you get the same results when you recover this file. Do this on a copy as it destroys all your button setups.
To follow up:
The crashing only occurs on Windows XP SP3 and Windows 7SP1. The fault can that causes FMPA 11 v3 crash can be many, mostly ntdll.dll and dbcommon.dll.
We did do a recover and it did report 2 layouts with problems and one table with strange data.
So we deleted the layouts. FMPA still crashed and for some people they were not even able to use filemaker. They would login and imediately it would crash.
So the recover log reads this for our history table:
2011-09-21 22:51:22.911 -0700 ARC Core.fp7 8461 Deleted invalid field data, ID or repetition invalid
2011-09-21 22:51:22.911 -0700 ARC Core.fp7 8461 Deleted invalid field data, ID or repetition invalid
What's invalid field data, ID or repetition invalid?
So we decided to just do without our History table. We deleted it and all of its relationships. Now some of the people who couldn't even use FileMaker can... but some of the people who haven't had any problems in the past are now crashing.
Running a recover now reports no problems. What's my next step?
Sounds like your database has significant structural problems. Your only option may be to either rebuild the file piece by piece--possibly from a "blank page" or to revert to a back up copy that does not have this issue. You'd then import the data from your most recent file's tables to get the most up to date data possible into this file.
Things to keep in mind about Recover:
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
*** Finally Stable ***
FileMaker became so unstable that we were desperate. Most Windows clients running on windows XP couldn't run FileMaker. Windows 7 and Mac clients were stable. We ran recover again. It reported no problems. We rebooted the server (Windows 2003 Standard SP2) and when it came back up it FileMaker server did a verification on our database file and it said it was corrupt. We had no choice but to use the recovered database.
FileMaker server didn't complain about the recovered file but many of the Windows XP clients did. We were desperate at this point. We started hacking and clearing rarely used layouts and tables. Turned off external ODBC connections. We cleared about 30% of the database in filesize by the time we were done. We did another recover on that trimmed up database and put this newly recovered database into place on the server and so far (it's been 72 hours) no problems.
I really think FileMaker Corp needs to look at the structure of their file system. If we were able to break it with just with 209 tables and 317 layouts, 362 scripts and a file size of 1.3GB, I'm really afraid of expanding on what we have now which is 170 tables, 260 layouts and 304 scripts at .91 GB thinking that we are on the border line of its stability point.
Hmmm, well we use a pair of windows server machines to host files out to XP (and now a few W7) clients. The largest file is now 4.4 GB and growing.
Crashes are very rare and have to be as these files support a POS type environment where even a few minutes down time result in customers being lost to competitors...
That's encouraging, however it fails to explain how we were able to corrupt a database a third the size of your database.
Are there any 3rd party tools or plugins that you know of that will monitor the structure of the database? We've have put our entire company's data processing and storage into this FileMaker Solution and if we have periods of downtimes like this last episode I'm sure the CEO will cut his losses and look elsewhere.
You might try a web search to see what you can find. I know of FMDiff as one product that seems to have the features you'd want for this task.