When a form reads in a row, @RECORD and @ID normally get populated. I have forms with some programmatic stuff following READ, that relies on correct @RECORD and @ID values being present. But when the record is locked @RECORD and @ID are not set, so the process fails.

What is the reason @RECORD and @ID are not populated when the record is locked?

Can I (the program) populate @RECORD and @ID myself, or might there be unwanted consequences? If I can that would save me from some work.

One more thing: When experimenting with locked records I normally see an empty @RECORD, but I think I once saw evidence of @RECORD not being empty but containing the previous row read. (@ID was empty, though.) Is there an explanation for that? (For all I know it's just a side effect from other programming in the app.)

- Oystein -

This is odd, as I found @RECORD to be populated with record locking in a FORM.

Where exactly are you checking @RECORD?

If in the READ event are you doing a FORWARD_EVENT prior to checking @RECORD?

You could always use a GET_PROPERTY(@WINDOW,'RECORD'). Just be aware that the changed value in a control will not find it's way into the record extracted thusly unless a LOSTFOCUS event was invoked prior.

Warren,

] This is odd, as I found @RECORD to be populated with record locking in a FORM.

Hmm. I must warn you I'm a total locking amateur. But Don Bakke seems to agree with me in this posting about a different subject: .

Are there circumstances when a locked @RECORD is populated and circumstances when it's not? My app is MDI. I've found a couple of things that are different with MDI, but have no real reason to suspect MDI this time. Except that Don often uses MDI too.

Btw - you say your @RECORD is OK but is your @ID correctly set too?

] Where exactly are you checking @RECORD?

The form is a table-bound MDI child (or rather one of many possible such child windows). The checking of @RECORD happens in some handler on the MDI frame. This handler places a key in the child form's key field, sends a READ event to the child, and afterwards checks @RECORD. The child has no READ handler of its own.

] If in the READ event are you doing a FORWARD_EVENT prior to checking @RECORD?

Question does not apply, I think.

] You could always use a GET_PROPERTY(@WINDOW,'RECORD'). Just be aware that the changed value in a control will not find it's way into the record extracted thusly unless a LOSTFOCUS event was invoked prior.

Later in the same handler I have a GET_PROPERTY(@WINDOW,'RECORD') that also fails, in the same way as @RECORD.

Great to have some input. Hope to get this stuff cleared up.

- Oystein -

When a form reads a record that has been locked the form will read the record as read only and not populate @record or @id. You may however populate it yourself.

Ahh, I see the errors of my ways. If the record is locked by another station or previous process @RECORD and @ID are not being filled. I never tested this situation as edits are not saved/allowed if the record is locked.

I could see this as a problem if you wanted to print a report via a form interface.

What about the record property of the window?

John

Warren,

I could see this as a problem if you wanted to print a report via a form interface.

Exactly, which is what we do all the time.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Same as @record. It is not populated when the record has been locked.

Bob,

What happens when there are Symbolics on the form? Are they left blank?

Thanks,

John

I don't have access to OI until Monday…but…

What happens if the FORM is read-only, e.g. disable write event and record locking?

While I can understand the design concerns with protecting @RECORD, @ID and CURSORS I wonder why a different solution other than use-at-your-own risk was not implemented.

Foxpro had similar issues when they went to the Windows environment. They "solved" this problem by allowing private data sessions. In a way similar to the push select/session in Arev but a lot less complicated for the programmer.

Documentation on Data Sessions

I understand the need for backwards compatibility but it would seem to me that "private data sessions" could be implemented in a way that would not affect the behavior of existing applications.

I haven't followed this thread in detail but I have successfully fiddled with changing a record key in a kludge to overcome a problem with seq keys. As I recollect I had to tweak something in the OI Windows Common variables.

This may be completely irrelevant but if it helps …

Okay, if locking is disabled for the form @record, @id and WINDOWS properties RECORD and ID are populated.

Is there a property that tells me the lock status of the record/key in a FORM?

You could always check Window Common RowLocks@ - if null no lock, if locked, row id.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Yeah, time to dig out my print out on your article on the Window common.

This is one of those gotchas that are a RPITA when porting from ARev to OI. Almost all of the ARev screens have softkeys to print reports/forms/merges/labels, do exports or send email. 99.99% of them use @RECORD/@ID.

Yeah we added ZZ_SetAtRecord(Window, atRecord) and zz_GetAtRecord(Window, atRecord, atId) functions so we didn't have to change our code ;)

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the Works forum...