Getting Stuck in a database Bug?

[mrpez1]

I have a Filemaker server 5.5 based solution that utilizes a top menu database that launches sub databases. From within the subdatabases there is a button that says "Menu". When pressed this button executes a script in the menu database to make it pop up so that the user can open a different subdatabase. This usually works fine. On occasion (one in 20 times?) the subdatabase from which the menu button is pressed will flash and then "get stuck". You can't minimize it, or go to another database through the windows menu (All the others are greyed out). All you can do is close the offending database. If you keep hitting the menu button, it will flash and stay in the same database. The external script that is triggered in the menu database is just the start up script (ending with refresh window bring to front). I've spoken to Filemaker and have an open case with them but out of the three people I've spoken to, two have told me my problem doesn't exist because they've never heard of it. The other one told me to do a recovery on everything which turned up nothing.

Any ideas? Anyone else ever experience this problem?

[Lee Smith]

How many files are involved?

[-Queue-]

my problem doesn't exist because they've never heard of it.

ROTF Two-year-old logic from the experts at FileMaker. Haha!

If I can't see you, then you can't see meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!

<Peek-a-boo!>

[Anatoli]

And what is in that subdatabase script? Has button Pause or Exit. Try Exit...

[DonH]

Tho I've never seen this problem (about the only one I haven't LOL) there are some general guidelines you can do to troubleshoot.

1) Determine if there is a common element to the failures. ie The same subdatabase, you just entered data, did the same steps etc etc

2) Have it pause before executing so you can dump the contents of any variables affected. In this case maybe have it show where it is trying to go. Possibly it is getting the wrong information for where it should be going.

3) Check the "DUH" factors. Is the db in single? Multiuser?

[mrpez1]

No common thread....Different Subdatabases do it, but not all the time. Like I said, maybe one in 20 executions of the script will cause the hangup. The Subdatabase script originally just exectuted the start up script in the menu database. They're all multi-user and usually work properly. That's what has me thinking this is a Filemaker Server bug.

My Menu startup script does get a little funky in querying a third database's global field (Gateway) to figure out who is currently logged into the solution then shows a custom layout depending on which user is logged in. To eliminate that process as the cause of the problem, I made a new script that just refreshes the Menu database's window and brings it to front when the menu button is pressed in a subdatabase (after the start up script is run, the proper layout is showing anyways) This script has the same problem 1 out of 20 times (or so) when executed from the subdatabase.

The solution itself is 25 files.

[ernst]

You do not happen to be in pause mode when this occurs?

[mrpez1]

Nope, No pause mode. I do have a freeze window step in the start up script... That's about as close to pausing as the scripts get.

[ernst]

Well, I use a construction like you describe with about 20 files on FM Server 5.5 and have never encountered this kind of problem. On MacOS this is.

You could try to use a client as server on the same machine, with the same files and see what happens.

Weird problem though...

Ernst.

[mrpez1]

I'm on Win2k... Figures...

[Anatoli]

Why freeze?

[mrpez1]

Here's a screenshot of my startup script. I use a variation of this script in pretty much all my databases.

Why freeze? I just stuck it in there because I like the idea it won't be showing the toolbars turning off or changing layouts while the solution opens.

[ernst]

What happens if you -temporarily- change the script to just:

Goto Layout [business layout]

[Vaughan]

I want to know what steps are in the script the main menu uses to open the sub-databases. If it uses Open [file.fp5] then that's your problem: if the file is already open nothing appears to happen.

If you really want the file to change to a layout, maximize the window and bring itself to the front then you need to make a script in each file that does all this and ends with Refresh Window [bring to front] (this last step is important). Call this "opener" script using the Perform Script [external] step instead of using the Open [] step.

[mrpez1]

The subdatabases' script to pop the menu database back up is simply:

perform script [sub Scripts, External: "start.fp5"] (sometimes I get a * at the end, not sure what that is about)

To answer the previous post about what happens if the start up script is changed to not check the user name: nothing. I made a new script in the menu database that just had refresh window, bring to front and substituted it as the external script in the subdatabases and still had the same problem (maybe 1 out of 20 times like before).

[stanley]

This doesn't sound like a FM Server problem to me - does the same behavior exhibit itself when you use the system as a single-user, on a single machine (i.e., NOT via FM Server)?

Also, what are the script steps in the subscript - because that's where the problem is most likely to lie.

-Stanley

[mrpez1]

Stanley,

Never seen the problem in Single User. I designed the solution and tested it using a client as the host. The problem started coming up once I put the files on the server.

See post #84276 for the subdatabase script.

[stanley]

Yeah, I saw that post. What I wonder about is what the script being called looks like. The script you showed looks fine, so that shouldn't be the problem.

Another thing is maybe the file paths are screwed up, from being moved onto the server. If you open the files single-user on the server machine using just FMPro, does it function?

-Stanley