It sound like you may have a corrupt object/item on that layout, or a script that's not exiting or keeps getting called.
That's what we've thought in the past and hunted for but with no definitive results. It's compounded by the fact that it happens once every few weeks or so and there's nothing that's been reported that any one is doing out of the ordinary.
I'm going down this route at the moment but can't recreate the problem, and assume I won't find anything.
I just thought of something else. Such flaky behavior may be a memory problem. From just needing to pull and reseating the cards to a bad cell/address.
Thanks for that suggestion I'll follow that next.
I ran a full recovery and found nothing untoward in the meantime
Interestingly when my client phones me and says the database has froze again I can still access it via FM client/open remote and go into various tables and edit them ok. It's only when I try to go to a layout based on a certain table that it freezes and FM is labelled as 'not responding' and I have to force quit. And the only solution so for is a server restart.
You explain that you have to restart the server when you have the problem:
- If you remove this layout, then you would not have anything causing a crash?
- Or is the crash occurring when entering any layout based on this specific table or TO?
- Is the server accessible via the admin console when the file has crashed?
- What does the log say after the crash?
- Can you log into the file on the server from an other client when you have the problem?
- If this is the case, it is not the server that has a problem, and this is what I would expect.
- Which version of FileMaker Server 13 are you using?
- Which version of the FileMaker Pro Client/Go Client are you using?
Could you say a little bit more about this layout, and it's content?
You also write: "The server log suggested the server was unstable." Could you please quote how the server log is suggesting that the server is unstable?
If, and only if, the problem is related to the specific layout an to no other element, then do like this:
- Create a new empty layout based on the same TO
- Copy let's say 1/5 of the elements of your original layout and paste them on to your new layout.
- Check, do you have the problem now?
- Repeat with more elements.
When you have found out which set of elements that carry the problem you should try the same procedure within this now more limited scope. And finally when the problem is isolated you can try to remove this single element from the original layout and then test.
But ... I would probably choose to rebuild this layout.
Looking forward to hear your answers and to
- If you remove this layout, then you would not have anything causing a crash?
Thanks for your thoughts. Much appreciated.
The file is on shared hosting on FM Server 13. 9 Clients accessing via FM12 and FM 13 (all day). And a handfull accessing intermittently via WebDirect
There are basically 4 main tables - clients (36 records), contracts (153), properties (20,214) and jobs (32,894)
99% of the time there are no issues whatsoever going between these tables and updating the records. Most of the work is done/scripts are in the jobs table where users collate found sets, send out related letters etc, and keep track of/update the progress of the jobs etc.
Over the last few months it has froze say 4 or 5 times.
We have to date no idea of what causes it.
When this file freezes other databases on the shared server still function normally.
Via a web interface created by the hosting company we then find that we can turn the database off but not on again.
The hosting company when we phone finds that the server has become unstable and reboots (see their comments in the first post)
I have run recover on a copy and found nothing untoward save 'Item count changed from 239 to 906 in: library catalog 'PROPERTIES''
However just before I recovered the file I deleted all the scanned document from the table:Properties as there are up to 12 per property!
In the past when the clients phone I've just tried to switch it off an on again in the web control panel and when that doesn't work contact the hosting company.
Any way, yesterday immediately the clients phoned to say it had froze again, I found I could open the database remotely with FM 13 Adv and navigate and edit records normally in the client, contract and property tables using various layouts. I could even amend job records via a portal in the property layout. However when I clicked on a navigation button to go through to the jobs list it froze. I could force quit FM Pro Adv 13 and go back into the database and experience the same. Unfortunately I didn't try to enter any other layouts based upon the jobs table.
Once it is rebooted it's all fine again. Note: This nav button that caused my freeze must be used hundred of times every day by everyone using the database without issues.
Unfortunately this is not an issue I can replicate.
With other files in the past if I can pin point an iffy layout I've removed fields till I found the rouge one and rebuilt the layout, but this isn't the case with this issue. The layout works fine 99.9% of the time.
Any server questions I'll pass on to the hosting company and get back to you.
The server log suggested the server was unstable.
How exactly? I saw you mention the one error from the log to say that the file could not be opened. But that is *AFTER* closing the file in the first place so there must be more entries in the log leading up to the closing.
Also: what do the statistics log have to say for the time leading up to the freeze?
(Obviously since you are on a shared folder, the issue could very well be that someone else's file is hogging resources, not yours...)
The thing to do would be to look for patterns across the timings & activities for the freezes and correlate that to what you can see in both the event log, the stats log and the OS's system log.
I've finally found what causes it!! When uploading a file (drag and drop from the desktop) but only from certain machines.
The database goes into a loop and needs a force quit. This then has a knock on effect when others go to this layout, it freezes and they too have to force quit. If new users then login they experience the same layout freeze. If you then close the file on the server, you can't reopen it as FM says the file is already open so we have to reboot the entire server.
Interesting thing is that out of a dozen or more machines (various macs and pcs, OS and FM versions) it only happens on 2. One running FMP 14.0.1 and the other FMP 13.0.4, both on windows 7.
So we've found the cause. Now to find the solution. I'm assuming it's something like a conflict with their version of adobe something or other. So over to the IT guys.
We seem to have had the exact problem as well. One data file (using data separation) has crashed a couple of times in the past week or two, which was only obvious when we noticed that multiple users were logged on up to 7 or 8 times each, as if they had been disconnected and their session was still alive after they logged back on, and some users could no longer log in at all. When we closed the file from the admin console and attempted to reopen it, the interface file opened but the data file wouldn't, saying "could not be opened; already open by another application". The only way to get it relaunched was a full server reboot. Interestingly (if not alarmingly), after the reboot, when we opened the file on the server, it had to perform a "verify" operation on it, probably due to it being closed incorrectly.
After reading this post, I completely locked down the ability to drag-and-drop image files onto containers (there were users doing this exact thing from various Windows machines, mostly version 7), and recreated a sort of contextual-menu system using popovers and a button bar.
We'll see if it solves the problem...
Sorry, only just picked up your post.
The company uses an IT consultant who (for some obscure reason) rolled all the versions back to FM Pro 12 and we haven't had the issue since. Now users using 12 when there's a lot of features written in 13 that they can't access is not viable. But the IT person insists it's a FM issue. So why isn't everyone in the world experiencing it?
Any way another IT company I know who run their own FM server reckon it's to do with the IP address locking. Which will only get cleared on a server reboot. Although they've not experienced it with FM they've come across it many times in other situations, so that's the avenue we are exploring at the moment. But as the IT and I are all external, getting permission to go on site and break their database is not high on their list. Yet!
We have had similar issues - Filemaker client applications crashing when uploading or dragging a pdf into a container field that is set to store images on server - anyone have any luck fixing this problem that has existed since FileMaker Server 13? Does anyonw think its tied to Adobe Reader updates on thier local computers?
Martin, if you are uploading a file via drag and drop this can cause a world of problems. It should be uploaded via FMP. I could be missing something here . . .
Depends on whether this is uploading a file into a container field; or uploading a FileMaker file onto Server.
File into container field should be ok.