Locking records from further editing

[trmupstage]

I've been looking for hours but still have not come across any posts that tell how to lock records. We will have a number of records being shown in a portal. When the "Status" field is set to "Complete", I want to prevent anyone from making further changes. Up till that point, it is fine for them to make changes. It seems like there should be a function called "lock record" or something like that, but I can't find anything. Could it be called something else? I'm using version 7 and version 9. BTW, 9 has some great new features. I was glad we bought it.

Thanks for the help

[Steven H. Blackwell]

Lock Field (number) set to 1 auto enter

Edit records allowed when lock field=1

Change to 0

Edit is not allowed when lock field =0.

Steven

[bcooney]

Or the flip side, flag_RecordLocked, auto enter nothing. The script that locks the record sets flag_RecordLocked to 1. (So, you need more than just a field change. You need to script the field change. Actually, who marks the record as complete? Admin only, yes? Therefore the "Mark Complete" button is only available to the admin access priv set, right?)

Then, in Access Privs, set it so that Edit is not allowed in the table for this priv set when flag_RecordLocked = 1.

I find flags = 1 more easily understood than equal to zero. It's really just a preference.

[trmupstage]

Thanks for the quick responses. Do I understand it correctly, that to make this work, I need to setup a new privilege set. I would then setup custom privileges for the edit of the particular table based on a calculation of: LockField = 1

Do I have that right? I would then make a script change the value of LockField to 0 when the record is complete. The user will actually hit the button that completes the record. We just have too many times where they go back in searching for something and they end up changing the data.

Like some other things with FM, it takes a bit to get your head around it.

[trmupstage]

I got that going. Now when the Lock field changes value, the user can no longer edit the record. One more thing though. They are still able to run the scripts that are attached to buttons in the record. Any way to change that? I know I can add some traps to the scripts to prevent them from running if the Lock field is set. I just don't know if there is a better way.

Thanks for all the help.

[Steven H. Blackwell]

Same concept.

If Lock=1, then OK to run script. If lock=0, then can't run.

Steven

[Steven H. Blackwell]

I suppose, Barbara.

But generally 1=True and 0 or empty=false. At least in FileMaker parlance. It seems to em therefore, that you can run the script or edit the field when the flag =1. if it=0 then you cannot do either.

Steven

[bcooney]

That's why I think the Lock=1 should read "the record is locked" and that you can't edit it.

[bcooney]

Well, the easy way out is to have two layouts. One is read/write, has all the buttons, etc. The other is read-only. Perhaps loses some of the buttons (except the ones that let you navigate).

In your navigation script, check the flag to see if the record is locked. If so, go to the read/only layout.

[Dchall_San_Antonio]

If y'all don't mind, I'd like to ask the question again. I will be distributing run-time versions of an invoicing program to about 100 users. It is important that the user not change, for example, his pay rate field entry without creating a new project record. If he changes his initial entry it will mess up his end of quarter accounting. This sounds like the same question; I just did not understand either answer. So far I have been the only user and know about the possibility for making the mistake, but I would hate to see some unsuspecting user goof up and have the IRS come after them.

Currently there is no 'Status Complete' button, but that seems like a good way to lock a record. I would rather not use two layouts (I do understand that and have been trying to avoid that alternative in other layouts). If either of you, or anyone else, could explain what you said once more, to the novice that I am, I would appreciate it. I guess when the status button is clicked, there should be a notification that the record is locked and that the only way to make a change is to start a new record. Actually it could be limited to a few fields on the record.

[David Jondreau]

What are the tables involved?

Sounds like you have a Projects table and a Pay Items table. Do you have another table for the Pay Rate itself? You can have a Pay Rate field in the Projects table that looks up the Pay Rate field from your Contacts or Globals table. Then the Pay Rate for a Project would be locked in for all the Pay Items for that Project.

[Dchall_San_Antonio]

Two tables for input: project table and daily expense table. I do not have a pay rate table, just a field in the project table.

Here is some background to maybe help decide how to fix this...each of us negotiates a different pay rate for each project. Sometimes it is daily and sometimes hourly. Sometimes that rate changes in the middle of the project. When that happens, if the user goes to the projects page and simply changes his pay rate, then at the end of the quarter, the db will show the last pay rate and associate it with all the daily records for the entire quarter instead of just the days that rate applied. My solution to that problem has been to create a different project number to associate with the days with different pay rates. Hope that makes sense.

If I use a separate pay rate table, the user would still be able to go in to the project table and make the change. Days are related to pay rates through the project number.

[David Jondreau]

So what you need is to make the Projects pay rate uneditable after the first value is in there. What is the current interface for entering a pay rate? If you make the field "uneditable" either by preventing access through the layout or in the field definitions a user won't be able to change their pay rate for a project.

But then how do you enter a pay rate for a new project? Script it. Use a global and a script that checks to see if a pay rate exists for that project already and rejects the new one if it does.

[Dchall_San_Antonio]

As in the original post, I had thought if making a button to "confirm" the data was correct. By clicking that button, somehow that one record becomes uneditable. Attempts to edit it would bring up a message explaining the situation and how to correct it. If that is possible, I don't know how to script that button.

[David Jondreau]

You're distributing a run time to a 100 users and you don't know how write a script that will set a field? Nothing like jumping right in.

I don't know how you're creating Projects or when the rate first goes in, but create a button named "Add Rate" and attach the script "Add Rate".

#

#

If[isEmpty(Projects::Rate)]

#

Show Custom Dialog[//you'll put your "Please add rate" text and define an input field to equal Projects::Rate]

#

Else

#

Show Custom Dialog[ "A rate is already defined. You must create a new project code."

#

End If

#

#

[Dchall_San_Antonio]

You're distributing a run time to a 100 users and you don't know how write a script that will set a field? Nothing like jumping right in.

Nor do I know when a script is the most appropriate approach. I take that as just another sad commentary on the help and documentation that comes with FMP. When I have a question I can't look for it in the help/docs, because I don't understand the words used in the help. I don't speak another language, but these docs may as well have been written in Greek. In 38 years of using computers I've never seen anything less intuitive than databases. At least this forum is interactive, so I have a chance at making my question understood.

Note again that I had to reopen this thread because I did not understand the answers offered originally. I suspect what was said way above would have worked if someone had just put it into baby talk for me.

[Steven H. Blackwell]

You might want to sign up for some professional FileMaker training. Here is a link.

Steven