{{tag>category:"OpenInsight 32-Bit" author:"Oystein Reigem" author:"Warren Auyong" author:"Bob Orsini" author:"John Bouley" author:"Donald Bakke" author:"Richard Guise" author:"support@sprezzatura.com"}}
[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]
==== @RECORD and @ID and locked records (OpenInsight 32-Bit) ====
=== At 19 JAN 2005 06:46:29AM Oystein Reigem wrote: ===
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 -
----
=== At 20 JAN 2005 11:36PM Warren Auyong wrote: ===
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.
----
=== At 21 JAN 2005 05:01AM Oystein Reigem wrote: ===
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 [i]frame[/i]. 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 -
----
=== At 21 JAN 2005 08:18AM Bob Orsini wrote: ===
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.
----
=== At 21 JAN 2005 08:42AM Warren Auyong wrote: ===
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.
----
=== At 21 JAN 2005 10:09AM John Bouley wrote: ===
What about the record property of the window?
John
----
=== At 21 JAN 2005 01:19PM Donald Bakke wrote: ===
Warren,
[i]I could see this as a problem if you wanted to print a report via a form interface.[/i]
Exactly, which is what we do all the time.
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 21 JAN 2005 01:49PM Bob Orsini wrote: ===
Same as @record. It is not populated when the record has been locked.
----
=== At 21 JAN 2005 04:29PM John Bouley wrote: ===
Bob,
What happens when there are Symbolics on the form? Are they left blank?
Thanks,
John
----
=== At 22 JAN 2005 09:23AM Warren Auyong wrote: ===
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?
----
=== At 24 JAN 2005 12:28PM Warren Auyong wrote: ===
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.
[url=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fox7help/html/dgtskUsingDataSessions.asp]Documentation on Data Sessions[/url]
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.
----
=== At 25 JAN 2005 05:52AM Richard Guise wrote: ===
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 ...
----
=== At 28 JAN 2005 03:44PM Warren Auyong wrote: ===
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?
----
=== At 28 JAN 2005 06:29PM support@sprezzatura.com wrote: ===
You could always check Window Common RowLocks@ - if null no lock, if locked, row id.
support@sprezzatura.com
The Sprezzatura Group Web Site
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
----
=== At 29 JAN 2005 08:58AM Warren Auyong wrote: ===
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.
----
=== At 29 JAN 2005 09:08AM support@sprezzatura.com wrote: ===
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
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=6CE56F7D29D4D6F985256F8E0040AE63|View this thread on the Works forum...]]