I have this table-bound form. (Actually there are several table-bound child windows in an MDI frame. Only one child window is open at a time, except at changeover between child windows, when briefly two child windows are open. But I think the situation is similar to having a single form.) Reading is done through the form's READ event. I assume the system READ event locks the row it reads, or issues a warning if the row has been locked already (by another user). Saving, however, is done with a plain write statement. How can that save programming find out that the record was locked by another user?

Might be dead trivial to you.

It would be much better if there was a comprehensive article about locking I could read - both automatic (i.e, done by table-bound forms) and programmatic locking. Is there such an article? And is the subject of locking sufficiently covered in the help files? Ira?

- Oystein -

Oystein,

If you try and do a write in code you will need to try and lock the record first. Apparently there is/has been a traffic light metaphor used with regards to locking (thanks Aaron - I must acknowledge him after the last lot of abuse I got!). Just because there is a red light, doesn't mean you can't go through it, you just shouldn't!

Check the error code (there should be one as you should already have the record locked by the READ event). An error code of 415 means someone else has it locked, so you're in trouble. 414 means you have it locked and can safely do a write. (You might want to check those codes as I'm doing this from memory). Check @Record hasn't been changed as well because MDI_Frames and MDI_Children can affect it. If you must use a write statement it might be best to use Get_Property to get your data.

Alternatively, if it's a simple databound form, why not just do a send_event WRITE to the window? That handles all the locking issues for you.

HTH

Tim

Tim,

If you try and do a write in code you will need to try and lock the record first. Apparently there is/has been a traffic light metaphor used with regards to locking (thanks Aaron - I must acknowledge him after the last lot of abuse I got!). Just because there is a red light, doesn't mean you can't go through it, you just shouldn't!

Good. All this makes sense and doesn't contradict my observations.

Check the error code (there should be one as you should already have the record locked by the READ event). An error code of 415 means someone else has it locked, so you're in trouble. 414 means you have it locked and can safely do a write. (You might want to check those codes as I'm doing this from memory).

I've checked SYSPROCS*FSERRORS_400 and it seems you're right. If there are other relevant error codes it would be nice to know.

Check @Record hasn't been changed as well because MDI_Frames and MDI_Children can affect it. If you must use a write statement it might be best to use Get_Property to get your data.

I've got all the stuff with records and changes licked. It's just the locking I need to get in place.

Alternatively, if it's a simple databound form, why not just do a send_event WRITE to the window? That handles all the locking issues for you.

Agree. But that's where my system is different. I have several child windows with a few fields in each. My experience with letting the child windows' WRITE handlers run is that only the values from the current child get saved. Alle other fields are saved empty, i.e, get blanked out. So my app uses all means to keep the child window WRITE handlers from running.

There might of course be something I should have done differently with my programming that handles the child windows. I don't know.

HTH

Sure!

- Oystein -

Try to lock the record yourself and check the STATUS() variable. The online docs explain that 1 is your lock and 0 someone else's! Don't forget to unlock if you don't forward the event.

The Sprezzatura Group

World Leaders in all things RevSoft

You could use a single MDI Child with multiple pages. That way you could read/write the whole shooting match in one go.

Tim

You could use a single MDI Child with multiple pages. That way you could read/write the whole shooting match in one go.

I believe he has multiple MDI Child windows because this was the way he dealt with the prior 115 control limit. We have had to do the exact same thing. However, in our case, we have an elaborate mechanism of keeping the contents of @RECORD in a UDP when the user switches from one MDI Child and goes to the next. When they click on the Save button we programmatically write everything at once.

We are currently trying, and hoping, to convert this into a single multi-page MDI Child in OI32. We might not be able to make it since OI32 still has an upper limit and I am doubtful we can come in underneath it.

[email protected]

SRP Computer Solutions, Inc.

Oystein,

I just had the urge to offer this…

If I am going to control any part of the read/write of the form, I always follow the following rules…

1) Lock the row.

2) Read the row (maintain the lock).

3) Do any updates to the row…

4) Write the row.

5) Unlock the row.

Do not release the row lock after the read and before the write. "Relocking" the locked row before you write is not necessary.

If you are handling your own write event, I would follow it up with a clear event too.

The "Form Database Options" help explains how a form handles locking. So if you are going to "by-pass" one of the events that handles locking, you will have to handle it yourself.

I went through the same process when I moved to OI32. The 115 control limit has been increased to about 250 (I forget the exact number) If you get too many controls, odd things happen. That wasn't the major problem though. The Service pack was unable to write records ]64K so the SYSREPOSWINEXES records were unable to be saved. I think this is fixed with service pack 2.1

Don,

I believe he has multiple MDI Child windows because this was the way he dealt with the prior 115 control limit.

That's correct.

- Oystein -

Richard,

Thanks. Things are gradually getting clearer.

- Oystein -

View this thread on the forum...