Very Computer

by **Darrel Dav** » Tue, 03 May 1994 05:10:10

I have come upon an interesting problem in our new FPW app. There
are five users on a system that accesses the same tables. When the
data input screens are opened, they all go to the 1st record. Since
we are using exclusive off, the record is (correctly) locked. What
I would like is for the a procedure somewhere in the screen to say,
when rlock()=.F.
skip 1
until it finds a record that is available to the user. Where do I
put this? In the screen setup? in the WHEN block?

Any help appreciated.

-> Darrel <-
--
--------------------------------------------------------------

* *
--------------------------------------------------------------

by **Justified And Ancien** » Tue, 03 May 1994 07:24:40

>I have come upon an interesting problem in our new FPW app. There
>are five users on a system that accesses the same tables. When the
>data input screens are opened, they all go to the 1st record. Since
>we are using exclusive off, the record is (correctly) locked. What
>I would like is for the a procedure somewhere in the screen to say,
>when rlock()=.F.
>skip 1
>until it finds a record that is available to the user. Where do I
>put this? In the screen setup? in the WHEN block?

You should put it in the screen setup procedure. Or, you can check
the READ NOLOCK box on the screen generator.

But do you really want them editing the information directly out of
the database?
--

=My thoughts, my posts, my ideas, my responsibility, my beer, my pizza. OK???=

by **Allen J. Friedm** » Wed, 04 May 1994 21:08:04

: I have come upon an interesting problem in our new FPW app. There
: are five users on a system that accesses the same tables. When the
: data input screens are opened, they all go to the 1st record. Since
: we are using exclusive off, the record is (correctly) locked. What
: I would like is for the a procedure somewhere in the screen to say,
: when rlock()=.F.
: skip 1
: until it finds a record that is available to the user. Where do I
: put this? In the screen setup? in the WHEN block?

Actually, I would approach this problem another way. When the screen
first comes up, the GETs could be disabled, via a check box on the field
dialog in Screen Builder. I would implement an 'Edit' button that enables
the GETS and locks the record. This means that a user can look at records
all day long without locking any records, and only lock when a record is
to be changed.

As others have pointed out, you should also consider indirect GETs to
memory variables, so that nobody is actually editing a record.

by **Nicholas W. Tayl** » Thu, 05 May 1994 02:23:09

>Subject: Re: Where do I put rlock() procedures in screens?
>Date: 3 May 1994 08:08:04 -0400

>: I have come upon an interesting problem in our new FPW app. There
>: are five users on a system that accesses the same tables. When the
>: data input screens are opened, they all go to the 1st record. Since
>: we are using exclusive off, the record is (correctly) locked. What
>: I would like is for the a procedure somewhere in the screen to say,
>: when rlock()=.F.
>: skip 1
>: until it finds a record that is available to the user. Where do I
>: put this? In the screen setup? in the WHEN block?
>Actually, I would approach this problem another way. When the screen
>first comes up, the GETs could be disabled, via a check box on the field
>dialog in Screen Builder. I would implement an 'Edit' button that enables
>the GETS and locks the record. This means that a user can look at records
>all day long without locking any records, and only lock when a record is
>to be changed.
>As others have pointed out, you should also consider indirect GETs to
>memory variables, so that nobody is actually editing a record.

I'm writing a program now that does exactly this with SET EXCLUSIVE
always OFF. My program has three distinct modes: Browse, Add, and Edit. In
Browse mode, the program simply does a SCATTER MEMVAR after moving to a new
record. Each relevant field has a WHEN clause that returns .F. if not adding
or editing, with the unique ID *never* being modified.

In Add mode, I simply do an APPEND BLANK and an immediate RLOCK() since
the record pointer now points to the newly appended record, along with a
SCATTER MEMVAR BLANK. When I'm ready to save, a Save button calls one big
validation routine checks the whole record for errors, placing the cursor over
any offending fields for immediate change. A simple GATHER MEMVAR and
automatic updating of the unique ID field save the record.

In Edit mode, since the program comes from Browse mode, I simply RLOCK()
the currently viewed record and proceed like in Add mode when saving. BTW,
this makes implementing an Undo function rather easy. Hitting undo does
either a SCATTER MEMVAR BLANK or SCATTER MEMVAR, depending on the mode.
Escaping out of either mode is also easy--just UNLOCK and return to Browse
mode. The only caviat is making sure to disable any navigation controls while
in Add or Edit modes.

Hope it helps. Indirect memvar editing is *always* safer and more reliable
than direct editing of database records except in the smallest of APPs.

--Nick "will code FoxPro for food" Taylor

*-------------------------------------------------------------------*

Programmer - Computing Applications Division
Oak Ridge National Labs, Martin Marietta Energy Systems presiding

*-------------------------------------------------------------------*
The founding fathers were just a bunch of guys trying to get out
of paying their taxes, after all! -- NWT