FMP7: Do You Use Globals for Data Entry?

[grantwood]

Hello,

I prefer to have dedicated layouts for data entry, and these layouts are usually displayed in separate "mini-windows". Then, after doing some custom validation, I transfer the data into corresponding non-globals.

Also, the data entry is done in a separate table, where each logged-in user has his/her own record. I was just curious if other developers do something similar, or if I'm overcomplicating things. It's just that in a multi-user solution, I prefer to keep users out of actual records as much as possible.

Regards,

Sean

[CyborgSam]

In FM6 I used global fields so the user could cancel entry/edit without saving changes.

In FM7 I use a combo of Open Record, Revert Record, Commit Record and Re-Login. A layout is view only for a user. Clicking the Edit or New button does a re-login to a more privileged account which has write access to the layout. Before exiting the layout, the user must Save (Commit Record) or Cancel (Revert Record). This works in both FileMaker Client and IWP. It was designed mainly for IWP, I didn't want to force the user to use the Status Area for record creation/editing (IMHO it's not at all intuitive nor a good GUI).

I haven't finished a full product with this scheme yet, so if anyone knows of gotchas please let me know!

[grantwood]

Thanks for the reply CyborgSam.

So, in trying to understand your editing process, when you click on "Edit", do you do something like the following:

1) Try and open the record for editing by using Open Record/Request

2) Go to a dedicated editing layout where "Save record changes automatically" is unchecked

3) Have two buttons on this layout: Cancel, which runs a Revert Record step, and Save, which runs a Commit Record step

What happens when a user clicks on "Edit" and then goes to lunch? How can you unlock that record?

Also, I'm not really fond of that "Save changes to this record" dialog. Can we bypass that?

Regards,

Sean

[CyborgSam]

Some more detail, I'll use edit instead of new as an example.

1) User clicks Edit, Open Record, if no error go to step 2, otherwise it's busy, so let user know & do nothing else.

2) Re-login with privileges allowing editing on same layout.

3) If user cancels, Revert Record & Re-login as normal user.

4) If user saves, validate data, if OK Commit Record & Re-login as normal user.

The going to lunch is a good question: what does FileMaker do if a user is logged off due to inactivity: is the record committed, reverted, or what, and does this behavior vary between the client & IWP. I'll research this if nobody has an answer.

One way to keep track of the state of which buttons are active is to use a stack. When the user clicks edit, I push the state of all my toolbar buttons onto the stack and set them appropriately (disable everything except Save, Cancel & Help). When they click cancel or save (and the data is valid) the stack is popped and the previous state of the buttons restored. I use the stack because it's easier to track & change the state throughout the database than to have every script have to test for the previous state.

I've got to get my demo file of all this done, it's a lot clearer to look at it...

[grantwood]

CyborgSam,

If one of your users is doing some editing, and s/he happens to click outside of a field, does a "Save changes" dialog display? That seems annoying B)

[CyborgSam]

No. Under the Layouts menu, Layout Setup..., General, I check the Save record changes automatically checkbox. I prefer to do my own validation, record saves, etc.

[grantwood]

I see. I was worried that the changes wouldn't revert if that option was checked.

When you click "Save", you don't explicitly commit the record until all of your custom validations pass. Is that correct?

Also, when someone is editing and inadvertently clicks outside a field, then that change is permanent, even after reverting the record. Is this correct?

[CyborgSam]

> When you click "Save", you don't explicitly commit the record until all of your custom validations pass. Is that correct?

Yes.

> Also, when someone is editing and inadvertently clicks outside a field, then that change is permanent, even after reverting the record. Is this correct?

No. The user has to perform an action that would auto-commit the record. I don't know for sure what all the actions are that will do that.

Attached is a quick DB I threw together to test this (no documentation). Click on a line in the list and edit it, then click Cancel or Save and see what happens. Note: This database is just a proof-of-concept, so doing anything other than clicking in/out of fields and clicking the two buttons will probably auto-commit the record.

Commit.zip

[CyborgSam]

WRONG, I WAS WRONG!

Clicking outside of a field when in FileMaker client does commit the record and the change is saved even if a Revert record is performed. I believe what I said above is true in IWP.

I'll do more research, I forget how I got around this in the past.

[grantwood]

Thanks for verifying that Filemaker perfoms an auto-commit. Bummer. That's why I'm still doing data entry in global fields.

Plus, global fields will allow me to put record locks on for a specified amount of time. So, when you click "Edit", you get 5 minutes (or whatever) to make your changes.

But of course, using global fields increases the number of relationships I have to use. Yuk.

I'd be very interested in knowing how you worked around the problem before.

Regards,

Sean