Except in rare cases I've always made do with the default locking for data-aware forms. But now I need to handle locking myself.

The scenario is as follows: I have a table with a multipage form, with 7 pages. But it's not a standard MPF. I've made it from an MDI frame and 7 child-windows. There's a commuter function on the frame that orchestrates everything that has to do with reading, writing, changing child, etc. Not to run into resource problems I've decided that only one child will be open at a time (there may be other windows open at the same time). When the user switches to a different page, I close the current child and open a new one. That's the crux. How do I keep other users from snatching the record from beneath the first user's nose?

(1) Turn off locking in all the child windows and let the frame commuter do the locking and unlocking?

(2) Keep locking in child windows as it is, and somehow patch the gap? Is that possible?

(3) Wait with closing a child until the next one is open? It will after all only mean one extra open window at any time.

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

oystein.reigem@hit.uib.no

Home tel/fax: +47 56 14 06 11.

Why not handle the locking programatically? Lock the record when the id is entered on the main window and unlock it when the main window is saved, cleared, or closed.

Kathleen,

Alternative (1), then. The logical and proper alternative.

It's just that I've never done this before, and never learned about it. I need details.

About locking: In case somebody else's got the record - do I loop for a certain amount of re-tries? With a short wait between each? Or do I give up right away?

About unlocking: If the app or PC crashes before the record was unlocked - will the lock stay and become problematic to other users?

Any other possible pitfalls?

TIA,

- Oystein -

Oystein,

If you set your forms to "ignore self-locks" then you can open a new form before closing the first one. That way the lock is maintained without any breaks at the workstation. Your worst case scenario is that you have two forms open simultaneously but only for a second.

dbakke@srpcs.com

SRP Computer Solutions

Oystein ..

Your question is not so trivial (as you knew all along). Here is what I do under similar circumstances:

1. In the READ event of the main (or controlling form)

  Locked=0

  Locktry=0

  Loop

      Locktry+=1

      If Locktry ] 10 then

• use Msg or something to prompt for additional retries

      end

      Lock Whatever_the_file_is,KEY then

          LOCKED=1

      End Else

• Check for Self-Lock or Another User Locking

• You can probably ignore Self-lock

• If another user then use MSG to handle the error

      End

      Until locked

   Repeat

Exit_Point:

If Locked then

 @USER1=KEY  ;* this is global across windows

• you may want to see if this data exists or if it is a new record

end else @USER1=' ;* clear the variable

RETURN (0/1), depending on whether you want to continue or not

2. In the WRITE event of any of the windows that the user is allowed to save the record from…

 KEY=@USER1

 If KEY then

• process your write

• Forward_Event or whatever

• do your unlock

     @USER1='

 End

The trick is to use a global variable that won't get trashed across multiple open windows.

HTH

Don Miller

C3 Inc.

Oystein ..

Forgot to respond to your other issues..

I always put an UNLOCK ALL statement in the screen that initializes the application (typically on the Create Event). Otherwise if the app takes a nosedive or the desktop environment gets whacked, this will clear any leftover locks from a previous session (that is if Oengine will start, otherwise you'll have to reboot anyway and that will clear locks, but an UNLOCK ALL won't hurt.

Usually, I don't put a loop in attempting to set locks. I'd rather give the user a chance to Retry or Cancel on a button. If it's one of your own locks (perhaps from another unrelated form), ignoring a self-lock can be a big headache. You can usually figure out whether the lock was set by one of your logically related forms or by something else that might do harm. We have a single form that has a total of 14 logically related forms (some on tabs, others on "hot" pictures (as push buttons)). In the Create parameter of the first and controlling form, we have a table of the forms that are part of the whole transaction. The lock (or locks, as the case may be) are set on the READ event of the controlling form. Instead of using @USER1 (which I posted to you), we use a labelled common variable which contains the Locked keys in the related tables which are being maintained. We need to have control of these associated data elements since the original and changed data elements in these forms need to be tracked

in order to process the incremental updates that will occur at save time. Our reason for this approach was simply running out of physical size on a single form (the old 127 or whatever the max number of controls is. Experimentally, I found that much over 90 controls and the whole thing gets really unstable.).

HTH

Don Miller

C3 Inc.

Many thanks to all of you!!!

- Oystein -

Oystein,

Well don't keep us in suspense, what did you decide to do?

dbakke@srpcs.com

SRP Computer Solutions

Don,

Now let me suffer my cold in peace. I've delayed the decision to Monday.

- Oystein -

Don/Don/Kath,

…All of you!!!

I think I'll try Don B's easy solution first, and upgrade to proper programmatic locking if necessary.

(There's a piece in the puzzle I haven't thought through yet - so far I think it's unrelated to locking - and that's saving and restoring the content of a child temporarily so I don't have to write the row every time I switch child. I've read some relevant postings (Don B and Carl?).)

Don M - I'm fairly certain I need the programmatic locking stuff for some other forms later. Thank you very much again!

- Oystein -

Oystein,

I'm not sure I understand your "puzzle". Would setting the flag to not clear the form after write help?

dbakke@srpcs.com

SRP Computer Solutions

Don,

I just said there is more stuff I need to fit in. And perhaps that stuff sways the decision.

If you can restrain your curiosity for now I promise to come back with oodles of questions later!!!

I don't clear the form.

- Oystein -

View this thread on the forum...