Field Validation

[Matt Klein]

Hi All -

I have a solution in which I lock certain fields, using validation by calculation, in a record when the value of a field is set to "locked". It works versions of FileMaker prior to 7.

It is no secret that with FileMaker 7 field validation by calculation happens at time of record commitment and that field validation by calculation in versions prior to v7 happens at field exit....

I have two questions:

1. Am I the only one who finds this bad? My clients can spend an hour in one record, without committing it, making changes to fields without being told that they can't do that until the record is committing and having to Revert the entire record to the state of last commitment. Yikes.

2. Does anyone have a good way to simulate the old way? I thought of using the auto-enter calculation function to run a script that would commit the record using a plug-in. It probably work, but for each field that needs this validation I also need to have the auto-enter calc. Just seems clunky.

I also thought of using Custom Privilege set settings until I found that the "Limited..." option for fields doesn't allow conditions to be set via calculation.

Anyone?

[Matt Klein]

Actually using the Auto-enter calculation to run a script to commit the record on field exit doesn't work well because when you commit the record the field focus is lost and FileMaker doesn't allow using a calculation to Go To Field. So, it would be a navigational nightmare.

[Matt Klein]

Wow. 40+ views of my post and no one has any ideas? I am not sure what that says in the grand scheme of FileMaker 7. BTW, I love FileMaker 7. Just trying to find ways around it's quirks of which I have found many.

[comment]

I try not to use field level validation at all. As a user, I find it extremely annoying: if I am not allowed to change the value of a field, I shouldn't be allowed to try - and it makes little difference if I find this out now or later.

Either use separate layouts for editing locked/unlocked records, or disable entry to the locked fields and make them buttons calling a script: If not locked, Go To Field.

[Matt Klein]

I try not to use field level validation at all. As a user, I find it extremely annoying: if I am not allowed to change the value of a field, I shouldn't be allowed to try - and it makes little difference if I find this out now or later.

Either use separate layouts for editing locked/unlocked records, or disable entry to the locked fields and make them buttons calling a script: If not locked, Go To Field.

Thanks for the reply. As annoying as field validation may be, it has it's place especially when you don't want to lock the entire record which is easily achieved through privileges. Making the fields unenterable except by clicking on them is a solution. The problem I have with that is that I deal with transcripionists who want to keep the need for leaving the keyboard for a mouse-click to a minimum.

[Ender]

I'm with comment. I rarely use field validations, instead I use scripts or calculated flags to check that fields are entered correctly. I have my navigation scripts branch to the either a view or entry layout based on the status of the record and the level of the user.

[Matt Klein]

I'm with comment. I rarely use field validations, instead I use scripts or calculated flags to check that fields are entered correctly. I have my navigation scripts branch to the either a view or entry layout based on the status of the record and the level of the user.

So, on these special layouts, the users cannot tab through the fields. Is that correct?

[Ender]

On the Entry screens, some fields are view only, but on the View screens, all fields are view only.

[Matt Klein]

On the Entry screens, some fields are view only, but on the View screens, all fields are view only.

So, on the Entry screens, you have accomplished view only status of fields by not allowing entry to those fields & are not in the tab order and those fields that are not view only can be entered & are in the tab order. Is that correct?

[comment]

There are many options here. Fields can be made viewable, but not accessible by using merge fields. Fields can be selected for copy, but not edited by using a calculated field to display their content. Fields can be conditionally removed from a layout by using the 'visibility' portal trick. You could load an entire record onto global fields for non-destructive editing. Ultimately, it all depends on the circumstances. So far, I have never needed to conditionally enable entry into a field on a layout, so it's hard for me to imagine what you're after.

[Matt Klein]

There are many options here. Fields can be made viewable, but not accessible by using merge fields. Fields can be selected for copy, but not edited by using a calculated field to display their content. Fields can be conditionally removed from a layout by using the 'visibility' portal trick. You could load an entire record onto global fields for non-destructive editing. Ultimately, it all depends on the circumstances. So far, I have never needed to conditionally enable entry into a field on a layout, so it's hard for me to imagine what you're after.

Again, Thanks for the replies guys.

Those are all good ideas. My thing is that I like to keep the database as clean as possible and as easy to maintain as possible. All of your suggestions would certainly work, but create extra fields, layouts, and scripting and thus maintenance.

Thanks again for you replies and ideas. I appreciate it.

[Ender]

So, on the Entry screens, you have accomplished view only status of fields by not allowing entry to those fields & are not in the tab order and those fields that are not view only can be entered & are in the tab order. Is that correct?

No. For disabling editing of fields, I usually just change the Field Behavior to not allow entry in Browse Mode. This makes it so it cannot be entered and takes it out of the tab order (though taking fields out of the tab order can also be done by editing the tab order and omitting some.)

As far as the extra work goes; well, "the user is king." Even if it means it will take an extra layout, or a couple extra fields, if it makes things easier to use, then it's worth it. Validation error messages, on the other hand, tend to annoy users, especially if they get trapped in a validation dialog they can't get out of (like if the field is not available on the layout they are on.)

I find It's better to show the parts of the data the user has access to, using subtle cues to indicate what's editable, what required, when the data-entry is complete, etc.

[Inky Phil]

You could load an entire record onto global fields for non-destructive editing.

I am preparing to rewrite my solution (I have a working system but I started with nil experience and it can be vastly improved) and one of my ideas is to to do all the work in globals, if you like have a mini one record system where all data is input and all calcs are performed within the global world, and to use my tables simply to store data and related data to populate my globals as needed.

Your statement as above almost makes it seem as though this is a rather extreme measure so I am wondering - is this an acceptable way of working or is it frought with as yet unforseen dangers and difficulties.

Anybody any views?

TIA

Phil

[comment]

It is a measure - I don't know how extreme.

I see a lot of sense in CREATING records in globals, in a multi-user solution. I don't know another way to ensure continuity of serial numbers in case of user aborting.

When EDITING data, this enables script validation. And I don't know a user that would understand Filemaker's 'Commit Record' dialog. One thing to watch for would be two users trying to edit the same record at the same time.

It seems you are more interested in a total data-logic separation. There is an entire section here devoted to this, and I'm not getting into that.

[Fenton]

As comment says, you would want to stop 2 users from making editing changes at once, which could be a problem if you use globals for editing. In 7 there have been great improvements to stop record-locking when editing in globals. But in your case you'd want to lock the record. There is an explicit Open Record script step for this. Then finish off with a Commit Record.

[Inky Phil]

Thank you Comment and Fenton. Your advice has helped, as always

Regards

Phil

[Søren Dyhr]

you would want to stop 2 users from making editing changes at once, which could be a problem if you use globals for editing. In 7 there have been great improvements to stop record-locking when editing in globals. But in your case you'd want to lock the record. There is an explicit Open Record script step for this. Then finish off with a Commit Record.

If say the record as such makes a multiline key in a bookingsystem, and you wish to change something - might it give the other users a false picture of occupied and free resources just to Open Record, to this have we developed another solution also exploiting the Albert Harum Alvarez scratch board tecnique from an old Adviser i didn't manage to find.

We simply remove the record into a set of global fields , when the alteration to the booking is done is a new record created, so it looses it's original status in FIFO cue ...the way we do it isn't revolutionary - it's been done before. But a new goal for me is to make the script short and fast ...so I involved Evaluate( and GetField( instead of using a series of Set Field( for every field in question. At least it makes the whirl thue debugger more object oriented ...

--sd

[comment]

To me, the purpose of using globals for creating/editing records is to postpone ANY changes to the database until the user has finished and is ready to commit. The scenario that I have in mind is user starting to do something, then being interrupted, and perhaps at the end aborting or forgetting all about it.

Locking the record being edited, not to mention deleting it(!) would not work in these circumstances. Frankly, I don't know what would - perhaps some kind of audit trail/syncing combination, i.e. comparing modification stamps of individual fields?