Thank you for your post.
Usually, when a database "locks up", no menu command is available nor is the cursor available. Therefore, I need a little more information.
What fields are on the layout? It appears you are in Browse mode. I want to make sure you aren't in Preview Mode. Can you confirm? What were you doing just prior to noticing this problem?
Any information you can provide may help me narrow down the possible causes.
Thanks for your reply.
Here's the situation in more detail. The solution is a business database for my woodworking business. It began on FMP 3 back in 1996. It ran on FM 5.5 until a year or so ago when I upgraded to 8.5, and pulled the dozen-ish files into 4 files. I upgraded to FMP Advanced 10 about 2 months ago, and now am running it as a single file with 29 tables presently. The problem seems to have come up since I started using FMPA10, and combined the solution to a single file. I've been trying to clean the thing up, clear out fields and calculations that are no longer used, refine the relationships, etc. I've been tinkering with it a lot, so I'm sure I've done something that isn't kosher.
You are right that it technically is not a lock up. It only affects an individual window that I'm aware of. The window will not accept any input. I cannot enter any field. The cursor will change to hand over a button but the button will not function. I can click on another window and it will be normal, but when I go back to the first window it still will not respond to the mouse. It behaves just like Preview mode, except it IS in browse mode as far as I know. (The window changes to page width in preview mode, and the layout is wider than that, so it would be visually obvious.) A few days ago, I clicked on "New Window" on the status bar on a "locked up" window. The new window behaved normally. The existing window remained unresponsive when I came back to it.
The layouts are often pretty complex, with many fields and a couple portals on them. The problem has shown up on layouts for several different tables. It usually happens after I've made an entry. It's possible that the last thing I did involved a drop down list but I can't be sure. A few times I will click on an existing window to find it unresponsive.
Does this give you anything to go on?
I can get this type of behavior if my script opens a new window, disables user abort and then pauses. Any chance this is what is happening?
I don't use that step in my scripts. So far, I'm the only one using the file (and I trust myself not to screw up the data too badly). I can see how it would cause the same kind of situation. But my situation only seems to affect individual windows (and not the same one consistently). Wouldn't a paused script still allow editing in the window?
I'm going to go back in AGAIN and recheck my calculated fields to see if I've bungled something in there. That seems the most likely thing to me at the moment.
"Wouldn't a paused script still allow editing in the window?"
That's generally why developers use this trick (open a window and pause). We're simulating a modal dialog and want the user to interact only with this window before triggering a script that resumes the paused script and closes the window. It depends on how you've designed the layout that's visible in the window.
A couple of other ideas:
Try recovering the file and test the recovered file for this problem. I've had a few cases where there was corruption hidden in a file and didn't discover it until I attempted to convert the file to a new version.
Try reverting to an older back up copy. If the back up copy works, you've now got two files to compare to see what design changes have made the two files different. That might expose a clue.
I tried recovering the file. Filemaker found and fixed a good number of problems. I'm now running the recovered file. Hopefully that will be it. I'll let you know.
Thanks a lot!
It's now been 2 - 3 days with no problems. Recovering the file did the trick!