Need advanced CREATE VIEW

Hi,

I've been running into some race conditions.

I thought I could solve them with an error routine triggered by a failed
FLOCK or RLOCK. The error routine would save the current file state
with a CREATE VIEW and close all files to allow the other user(s) to
complete their tasks and then restore the view and continue with normal
program execution.

The problem is that CREATE VIEW doesn't save the record pointers. I
thought I could circumvent this by saving RECNO(i) in an array and then
restoring. But I ran into problems.

The major problem is that you can't simply GOTO the saved record number
in each table when there are relations involved. You have to go to the
record number in the master table first and then to each child table.

If there is more than one level of relations, you have to work down the
relation tree.

I realize I could write code for each specific instance where a RLOCK or
FLOCK was used to save that particular state, but that would be crude
and time consuming. I would much prefer a general solution.

Has anyone worked out a solution to this problem? I could really use
some help.

Thanks, Frank

Roger
Sun May 16 11:17:28 CDT 2004

Hi,

CREATE VIEW looked promising when I started out in FPW
but I quickly realised that it had almost no practical use.

I can't think of any reason why you would want to close all open
tables (and then re-open them) in the event of a failed RLOCK()
or FLOCK() function.

Have a look at the SET REPROCESS command.

As you haven't explained exactly what you're trying to do,
it's difficult to provide a definitive answer, however as a general
rule, if you want access to a specific record in a master/parent
table then you should attempt a record lock at that stage ... eg:

lnReproc=Set("Reprocess")
Set Reprocess to 1 && just try the lock attempt once
If !Rlock("myMasterTable")
MessageBox("Someone else is ... please try again later")
Else
* Do whatever you want
EndIf
Set Reprocess to (lnReproc)

HTH

-Roger
--
Roger Ansell
Adelaide, Australia

My real email address is ransell at senet dot com dot au

"Frank Dreyfus" <fdreyfus@nyw.com> wrote in message
news:Xns94EB5905A462Cadfslur0mdoaur03jadl@207.46.248.16...
Hi,

I've been running into some race conditions.

I thought I could solve them with an error routine triggered by a failed
FLOCK or RLOCK. The error routine would save the current file state
with a CREATE VIEW and close all files to allow the other user(s) to
complete their tasks and then restore the view and continue with normal
program execution.

The problem is that CREATE VIEW doesn't save the record pointers. I
thought I could circumvent this by saving RECNO(i) in an array and then
restoring. But I ran into problems.

The major problem is that you can't simply GOTO the saved record number
in each table when there are relations involved. You have to go to the
record number in the master table first and then to each child table.

If there is more than one level of relations, you have to work down the
relation tree.

I realize I could write code for each specific instance where a RLOCK or
FLOCK was used to save that particular state, but that would be crude
and time consuming. I would much prefer a general solution.

Has anyone worked out a solution to this problem? I could really use
some help.

Thanks, Frank

Roger
Sun May 16 11:27:05 CDT 2004

Sorry, I hit the "send button too soon" ...
Remember to unlock!! <s>

lnReproc=Set("Reprocess")
Set Reprocess to 1 && just try the lock attempt once
If !Rlock("myMasterTable")
MessageBox("Someone else is ... please try again later")
Else
* Do whatever you want
Unlock in "myMasterYable" && forgot to add this
EndIf
Set Reprocess to (lnReproc)

-Roger
--
Roger Ansell
Adelaide, Australia

My real email address is ransell at senet dot com dot au

"Frank Dreyfus" <fdreyfus@nyw.com> wrote in message
news:Xns94EB5905A462Cadfslur0mdoaur03jadl@207.46.248.16...
Hi,

I've been running into some race conditions.

I thought I could solve them with an error routine triggered by a failed
FLOCK or RLOCK. The error routine would save the current file state
with a CREATE VIEW and close all files to allow the other user(s) to
complete their tasks and then restore the view and continue with normal
program execution.

The problem is that CREATE VIEW doesn't save the record pointers. I
thought I could circumvent this by saving RECNO(i) in an array and then
restoring. But I ran into problems.

The major problem is that you can't simply GOTO the saved record number
in each table when there are relations involved. You have to go to the
record number in the master table first and then to each child table.

If there is more than one level of relations, you have to work down the
relation tree.

I realize I could write code for each specific instance where a RLOCK or
FLOCK was used to save that particular state, but that would be crude
and time consuming. I would much prefer a general solution.

Has anyone worked out a solution to this problem? I could really use
some help.

Thanks, Frank

Frank
Sun May 16 12:58:17 CDT 2004

"Roger Ansell" <notmyreal@emailaddress.com> wrote in news:2gpigfF58jacU1
@uni-berlin.de:

> I can't think of any reason why you would want to close all open
> tables (and then re-open them) in the event of a failed RLOCK()
> or FLOCK() function.

Thanks for the feedback.

The problem is that in a typical (for me) situation, several users have
overlapping tables open for read access. This is fine. But if two or
more users now need exclusive access to a record or file, they may
occasionally get into a race condition where user A needs table 1 and
user B needs table 2.

It's not good enough for user A to just not lock table 1 (as you
suggest) because user B will never release table 2 until A closes table
1.

I thought it would be a fairly simple matter for user A to close all
tables thus allowing user B to complete his work. User A could then
restore everything as it was a continue merrily along.

But the problem with record pointers gets in the way of a general
solution for this.

I could possibly solve this with transaction/rollback control but that
would require an enormous amount of work and many many program changes.

A simple save of the open file environment would be simple to implement
as a call to an error procedure.

Any ideas would be greatly appreciated.

P.S. I don't know why you say "...haven't explained exactly what you're
trying to do". Hopefully the above description will help.

Thanks, Frank

Andrew
Mon May 17 04:38:06 CDT 2004

Frank Dreyfus wrote:
> "Roger Ansell" <notmyreal@emailaddress.com> wrote in
> news:2gpigfF58jacU1 @uni-berlin.de:
>
>> I can't think of any reason why you would want to close all open
>> tables (and then re-open them) in the event of a failed RLOCK()
>> or FLOCK() function.
>
> Thanks for the feedback.
>
> The problem is that in a typical (for me) situation, several users
> have overlapping tables open for read access. This is fine. But if
> two or more users now need exclusive access to a record or file, they
> may occasionally get into a race condition where user A needs table 1
> and user B needs table 2.
>
> It's not good enough for user A to just not lock table 1 (as you
> suggest) because user B will never release table 2 until A closes
> table 1.
>
> I thought it would be a fairly simple matter for user A to close all
> tables thus allowing user B to complete his work. User A could then
> restore everything as it was a continue merrily along.
>
> But the problem with record pointers gets in the way of a general
> solution for this.
>
> I could possibly solve this with transaction/rollback control but that
> would require an enormous amount of work and many many program
> changes.

Like Roger, I found CREATE VIEW an interesting feature that turned out to be
practically useless.

Your situation sounds like a classic case for pessimistic record locking. I
don't know what your application looks like but when I want to avoid this
situation I write screens that try to lock when the user clicks "edit". The
record remains locked until a "save" or "cancel" is performed by the user
and any other user requesting an edit of the same record receives a message
"this record is currently being edited by another user. Please try again
later."

Don't forget to
SET REPROCESS TO 1
the default behaviour is to attempt locking indefinately.

This is a lot easier to handle than a comparatively complex routine that
tries to close the tables (for how long? I guess you're hoping the other
client can update before they are reopened) and restores the environment.

--
HTH
Andrew Howell

Al
Mon May 17 06:54:41 CDT 2004

In the old days, there was 2 ways to solve this

1. lock or open tables always in a specific order,
like alphabetically, so that any race condition did
not occur.

2. have a specific table whose sole purpose is to
be locked whenerver a user wants to perform the actions
in question.

al

"Frank Dreyfus" <fdreyfus@nyw.com> wrote in message
news:Xns94EB5905A462Cadfslur0mdoaur03jadl@207.46.248.16...
> Hi,
>
> I've been running into some race conditions.
>
> I thought I could solve them with an error routine triggered by a failed
> FLOCK or RLOCK. The error routine would save the current file state
> with a CREATE VIEW and close all files to allow the other user(s) to
> complete their tasks and then restore the view and continue with normal
> program execution.
>
> The problem is that CREATE VIEW doesn't save the record pointers. I
> thought I could circumvent this by saving RECNO(i) in an array and then
> restoring. But I ran into problems.
>
> The major problem is that you can't simply GOTO the saved record number
> in each table when there are relations involved. You have to go to the
> record number in the master table first and then to each child table.
>
> If there is more than one level of relations, you have to work down the
> relation tree.
>
> I realize I could write code for each specific instance where a RLOCK or
> FLOCK was used to save that particular state, but that would be crude
> and time consuming. I would much prefer a general solution.
>
> Has anyone worked out a solution to this problem? I could really use
> some help.
>
> Thanks, Frank

Frank
Mon May 17 22:10:06 CDT 2004

"Andrew Howell" <ajh@work> wrote in
news:uf$FhX$OEHA.556@tk2msftngp13.phx.gbl:

> This is a lot easier to handle than a comparatively complex routine
> that tries to close the tables (for how long? I guess you're hoping
> the other client can update before they are reopened) and restores the
> environment.
>

Hi,

What I was intending was to close all the user's files and give him a
screen indicating the file or record that can't be locked and giving him
a Retry button.

It seems to me that this would be a clean solution to a knotty problem.
Assuming, of course, that it is doable.

I am still hopeful that I'll be able to find a solution. Call me
Pollyanna ;>)

Thanks, Frank

Frank
Mon May 17 22:14:36 CDT 2004

"Al Marino" <intelliform@NOTab12THISverizon.net> wrote in
news:ef4AyXAPEHA.3744@TK2MSFTNGP11.phx.gbl:

> In the old days, there was 2 ways to solve this

What about today? ;>)

>
> 1. lock or open tables always in a specific order,
> like alphabetically, so that any race condition did
> not occur.

This isn't practical in the present app. It's not that all users are
doing the same thing. For the most part, they are all doing different
things that require different combinations of open tables. It's only on
occasion that the race condition occurs.


>
> 2. have a specific table whose sole purpose is to
> be locked whenever a user wants to perform the actions
> in question.

I don't know how this would be applied. It would tell me that someone
has a file (or files) open but would not help me resolve the race
condition. Unless I'm missing something.

Thanks, Frank

Anders
Tue May 18 04:45:23 CDT 2004

There's OLDVAL and CURVAL functions to see if someone has updated a record
you're working on.
-Anders

"Frank Dreyfus" <fdreyfus@nyw.com> wrote in message
news:Xns94ECEC804513Eadfslur0mdoaur03jadl@207.46.248.16...
> "Al Marino" <intelliform@NOTab12THISverizon.net> wrote in
> news:ef4AyXAPEHA.3744@TK2MSFTNGP11.phx.gbl:
>
> > In the old days, there was 2 ways to solve this
>
> What about today? ;>)
>
> >
> > 1. lock or open tables always in a specific order,
> > like alphabetically, so that any race condition did
> > not occur.
>
> This isn't practical in the present app. It's not that all users are
> doing the same thing. For the most part, they are all doing different
> things that require different combinations of open tables. It's only on
> occasion that the race condition occurs.
>
>
> >
> > 2. have a specific table whose sole purpose is to
> > be locked whenever a user wants to perform the actions
> > in question.
>
> I don't know how this would be applied. It would tell me that someone
> has a file (or files) open but would not help me resolve the race
> condition. Unless I'm missing something.
>
> Thanks, Frank