Portal row edit doesn't trigger validation

[parallax]

When I add or edit a record in a portal (FM9adv) one particular field validation rule doesn't trigger until I click outside the portal on the layout (Clicking on another row or adding multiple records doesn't seem to trigger it). The validation is for uniqueness on a field that has an auto-entered calculation. Other validation rules triggger as expected. This field is defined to validate 'Always'. Anybody have any suggestions?

[Matthew F]

Um, dunno.. Does it depend on the form of storage (indexing on /off)? Are their calculation fields or relationships that use this field?

[parallax]

I've never seen the behavior before, and as I said it isn't a problem with other validation rules. I tried it in two different layouts, turned indexing on and off. No complex relationships either - just two tables involved. Real FMP 101. I figured somebody on this forum would've seen the behavior and say "oh, yeh, that's because FM doesn't yadda yadda so that happens with a portal that blah-dee-blah.

Clearly I'm in uncharted waters.

[LaRetta]

What fields are listed in the validation? Any field listed must be present on the layout. Maybe that is why it is happening?

[comment]

I have tested this and I am getting the same result. It only happens when the field validation is set to 'unique' (and possibly to 'existing', I haven't checked this) AND the field has some auto-entered data/calculation. In this situation, the field is validated on record commit, rather than on field exit.

Validating 'always' and/or the field being in a portal has nothing to do with this, AFAICT.

When version 7 was released, Filemaker had a note in their Knowledge Base saying that:

Unique and existing field validations must be done at commit time in order to lock out other users from invalidating the checks made to the data. This means that instead of getting the validation error when you click out of the field for unique or existing validation, you will get it at the time the record is committed.

However logical that may sound, when 7.0v2 update came out, the release notes said:

1.2. Unique or existing validation on a field now triggers when you exit the field rather than when you commit the entire record.

It seems that this is true - EXCEPT when the field has auto-entry turned on.

[parallax]

Validating 'always' and/or the field being in a portal has nothing to do with this, AFAICT.

Ouch. I discovered that last night - I had been falsely assuming that the portal was involved because i thought that FM was cacheing the record changes and only forcing a commit on portal exit. But as you say it's more insidious.

It looks like I'll have to force data entry in a popup window and script the commit. How lame.

I can't wait for FM to add event triggers.

Thanks for your help.

[Vaughan]

It might be because the validation is "by calculation".

[chaspowell]

I am running into the same problem attempting to trigger a validation base on a value list. I have picked up somewhere that validation occurs immediately if information is entered directly into a field (Validation upon leaving field) but is delayed if information is brought in through a related field (I would assume portals would fall in this category as well as value lists). This leads to validation on commit rather than entry. I need a workaround for that as well.

I need to be able to validate immediately as of leaving field when you are using a value list radio button setup. Any help will be welcome.

[chaspowell]

I've got an idea maybe a commit script can be used in both of our cases. I am off to try it and will let you know what I find.