A field has Validation during data entry = required to be not empty (Display custom message on error). While creating a record but before entering anything in this field, a user tried to quit FM. The validation message popped up as usual. Clicking OK does not return the user to the invalid field. It just causes the dialog box to disappear and immediately reappear. We had to force quit FM. (Fortunately this was on a test file so no data was at risk).

Any suggestions as to ways of avoiding this or at least getting FM to let us put something in the field?

Lynn

This doesn't happen for me in a test file I just created... is the user just quitting using the file:quit menu or with a script?

If it's not a script, try creating another file to reproduce this... also make sure you're using the most recent version 7v3 of FMP.

Dana

Yeah, I discovered the same thing just before I left last night. The file where the problem occurs is hosted by another computer. The error occurs when the user who is connected remotely tries to quit FM by choosing Quit from the menu. When I get a few moments, I will create a test hosted DB to check.

(I have actually been working on my primary project most of the morning so far!)

All computers are running OS X 10.3.9 and FM7v3.

Lynn

I am going to have to dig deeper. I created a test file with the same account privileges and hosted on the same computer as the (large, complex) file which fails. The test file simply acts as I expect. On Quit it pops up the dialog and when I click OK it takes me to the field with the validation error. It also terminates the quit.

The file with the problem has relationships to several other files (it was upgraded to FM7 from a legacy system). There are also a number of scripts, but nothing is active at the time and place of the failure.

Any ideas?

Thanks,

Lynn

Does the problem occur only when the file is hosted or if it is opened locally too?

If filemaker is quitting, I guess it would run any closing scripts in any of the open related files. Have you made sure that all of the closing scripts (in all open files) are disabled to rule them out too?

I just tried it on the host. Same infinite loop behavior. No users were connected (I think). I am fairly certain that no shutdown scripts exist on any of the hosted DBs. I checked that there are none on the file that has the problem.

Lynn

Can you open it with developer and turn on the script debugger to make sure that no scripts are causing problems?

I do not have Developer.

Lynn

I took a copy of the four related files off-line. Running on a single computer the problem does not occur.

My boss does not want me experimenting with the test files running on the host computer - too much risk of corrupting something else - so I am trying to figure out what else to try.

Lynn

Can you post clones of the files here for others to try and reproduce the problem?

Dana

Here are the clones. Full access account is "admin" with password "admin". The host account is "host" with password "host". The user accounts are "User1" and "User2" both with password "user". The main file is WO 05-06 clone.fp7 and will attempt to open under the host account.

I have not verified that the problem occurs with this file set, but the only things I changed were the account names and passwords, and the file references. All file references are local so if all the files are in the same directory it should be OK.

Lynn

Can you try and upload them again? I couldn't get the download to work in either Safari or FireFox, or even <shudder>Windows IE6</shudder>

It says something about Warning! Unexpected Character....ASCII etc...

Dana

I got that, too. I did verify that the archive unstuffs to working files. Trying again....

Lynn

Get the same error again. I'll try re-stuffing the files.

Trying again.

Lynn

that worked... I'll have a look at it and see if I can reproduce....

Well I haven't found the exact cause, but it is definitely intermittent... I first tried turning on script debugger, and it didn't appear to run any scripts, since it didn't drop into the debugger. But when debugger was on, the problem didn't happen... If I just try to create a record in the file w/o debugger on, I can observe the same behavior. (I assume you're talking about the nomenclature field here)

I have found a way out of the loop without force quitting, however. If you hit return twice in a row very quickly, the first one dismisses the dialog, and the second one enters a return character in the field before the dialog has a chance to pop up again. Then the field isn't empty, and the application quits normally.

I tried messing around with the validation and the lookup for the field and it seems that making changes to these values sometimes makes the problem go away.

1. If I leave the validation on but remove the custom message, the loop doesn't happen.

2. If I turn the custom message back on, the loop reappears.

3. If I leave the validation alone, but then turn off the lookup... then go back in a reenable the lookup, the loop seems to go away for good (as far as I can tell)

Definitely seems like a bug... but not an obvious single cause.

Hope this helps,

Dana

At least it was not something trivial that I simply overlooked. This DB has grown liike the House that Jack Built since the early 1990's so it could have a lot of crazyness that has crept in over time. The boss won't let me spend any time to rewrite it taking full advantage of FM7's new features (and what we have learned), so I guess he will have to put up with a few bugs.

Thanks for the suggestions.

Lynn

Reed,

I implemented option 3) of your suggestion. It worked, at least the first time. This is not something I plan to test repeatedly.

Thanks for your help.

Lynn