Dear Alan Secker:
On Feb 12, 8:30=A0am, Alan Secker <a...@[EMAIL PROTECTED]
> wrote:
> N:dlzc D:aol T:com (dlzc) wrote:
>
> > Dear Alan Secker:
>
> > "Alan Secker" <a...@[EMAIL PROTECTED]
> wrote in message
> >news:qrqdnU7k6IxXGyzanZ2dnUVZ8rCdnZ2d@[EMAIL PROTECTED]
> >> I have just had a program crash at a commit
> >> instruction. The code looks like this:
>
> >> name->(reclock())
>
> > ... do you mean "rlock()" ?
>
> No reclock() comes from an article in Clipper
> Adviser going back yonks. I have used it since
> forever. It is an enhanced locking scheme.
I cannot find documentation on it. Does it have a return value, based
on success / failure?
> All the users use the same program in the same
> way including the same RDD.
>
> I do know that if name->trade_code was indexed, the
> next line would crash the program but it isn't.
>
> I will just have to do some of-line testing.
!!! Check return value !!! Off-line won't show a "dining philsopher"
problem.
What RDD?
> >> name->trade_code :=3D space(4)
> >> name->(dbcommit())
> >> name->(dbunlock())
>
> >> Although I have use this order of statements
> >> all over this (huge) program without any
> >> problems before, is my ordering incorrect?
>
> > I don't think so, it seems the correct order.
> >=A0Some things in the NG indicate that though you
> > have locked and unlocked, changes won't hit
> > the disk any sooner than you commit.
>
> Are you saying commit is literally a waste of
> space?
Negative. It is a time intensive process that is critical in a heavy-
traffic DOS (or Super-DOS aka. WinDoze) environment. If you could
commit every 10th record changed, you might speed up your process,
with the risk of two different updates to the same record. And it
still is no guarantee the "double cross" will not not occur anyway.
DOS is like that. You don't get protections until you go with SQL or
some such.
Maybe you need to move the unlock and commit into a separate function,
and play with it. The Clipper docs seem to indicate that assigning a
new lock, unlocks the previous lock in the same work area. So
"unlock" may be redundant, up until all operations on the file are
completed.
David A. Smith


|