4 Replies Latest reply on Jan 20, 2011 3:55 PM by FentonJones

    Commit record without relinquishing lock?

    DebiFuchs

      Title

      Commit record without relinquishing lock?

      Post

      Is there a way to commit a record without (even temporarily) relinquishing the record lock?

      The closest I can come is this:

         Commit Records/Requests

         Open Record/Request

      But this is not close enough...it has happened on a server-side script that a record I'm trying to keep locked has become unlocked between these steps, even when close together.  I'd like to prevent this so my script can complete (and commit data several times along the way) without losing the record to another user anytime during the process.

        • 1. Re: Commit record without relinquishing lock?
          FentonJones

          How about a special Lock_server_only field (number)? After testing the record to see if you are indeed going to modify it (and that you have access to it), set the "server lock" field to 1 in that record, and commit. 

          In everyone else's Privileges, Records access, Edit, create a calculation which evaluates true only if not "server locked," so no one else can edit that record while you have it locked. I believe if they cannot edit, they cannot cause a lock themselves.

          You would need a special Account for Server scripts to use, and a Privilege Set (with lots of access, but not Full Access), and use it for all scheduled scripts. This is a good idea anyway, as it is one of the few ways to disconnect that "user" to stop a run-away loop in a server script.

          Calculation for Edit access, in all user Privilege Sets (except the server one):

          not Lock_server_only  // or Lock_server_only ≠ 1 (however you want to phrase it)

          You would absolutely need to clear that field after editing, no matter what happened, so the record was available again. I suppose you could also run a Find, and clear any, after all was done, just to be sure. None should be locked at that point.

          • 2. Re: Commit record without relinquishing lock?
            DebiFuchs

            Thanks, Fenton.  That would get me 90% of what I need.  However, unless I am mistaken:

                - scripts running with full access could grab the record anyway

                - developers running with full access could grab the record anyway

                - typical users who try to modify the record would see the misleading message "Your access privileges do not allow you to perform this action."

            I wish there was a Commit Records/Requests[Keep Record Open] option.

            • 3. Re: Commit record without relinquishing lock?
              philmodjunk

              - scripts running with full access could grab the record anyway

              True, but these same scripts could check the record's lock status before attempting to modify the record. (And use a looping script instead of Replace Field Contents, though that's not a could tool to use in most multi-user situtations anyway.)

              • 4. Re: Commit record without relinquishing lock?
                FentonJones

                Yes, it's a tricky situation.

                1. "Scripts running with Full Access could grab the record anyway."

                I did not think of that. And no, I don't know how to stop that happening. But there is a way to "mitigate" the problem. Which is, during your loop, check if you have access to each record as you go. If not, capture the unique primary ID of that record and put into a Variable or global field (of return-separated values). I'd put them into a global, and use it with Go To Related Records, to isolate them again quickly.

                After the main loop has run, see if any records got skipped. If so, go back and try them again. With some pauses, it could try this several times. In the case of another script having blocked them the 1st time, they should be free again fairly soon. Though, yes, since they'd not been explicitly locked by you the 1st time thru, some user could get into one; or some user could already have been in one; but that's always true, unless you run your scheduled script off-hours. 

                2. There should be no one running the database as Full Access except the developer(s). For one thing, in a hosted file situation they could crash while a Manage Database dialog was open, which could damage the files (permanently, unless you move the data). You can give their "expert" person all access, but not Full Access. That also has advantages, such as during normal times you know no one (else) is running with Full Access.

                3. I don't see how you could suppress that "no access" message for attempted data entry into a locked record, nor can you modify the message. Not that there's much else you could say. But they likely sometimes get the message once in a while already, because of normal user activity, someone else in the record.