Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mq!alan
From: alan@mq.COM (Alan H. Mintz)
Newsgroups: comp.databases
Subject: Re: rlock() in SCO foxbase+.
Summary: I think that's what I said.
Keywords: foxbase, rlock
Message-ID: <85@mq.COM>
Date: 28 Sep 90 00:14:48 GMT
References: <553@safn2.UUCP> <79@mq.COM> <1990Sep25.234729.5299@mccc.uucp>
Organization: Micro-Quick Systems, Inc.
Lines: 40

In article <1990Sep25.234729.5299@mccc.uucp>, shevett@mccc.uucp (Dave Shevett) writes:
> =APPENDs require flock() (which cannot be performed on a file that is rloc()d
> =by another user. Note that you can flock() a file in which YOU have rlocked
> =a record - the flock() simply supercedes the rlock().
> 
> Careful here.  The 'append' function standalone requires a flock().
> However, I think 'rey' is running inside a procedure, therefore is 
> probably doing APPEND BLANK.  In this case, the normal sequence is:

I think that is what I said, unless I misunderstand you. What I meant to say
was that, in order to do the APPE BLAN, you needed to do an flock()
first. 

I consulted TFM on the subject - this is WRONG. Apparently,
APPEND BLANK only locks the database HEADER and does not require that you
flock() first. It apparently asserts some "other" kind of lock on the
database header that does not conflict with any other kind of lock except
EXCLUSIVE use. This makes sense, since the lock is not under user control, 
and can therefore be managed by an internal handler.

I was completely dumbfounded by this. The application that I learned dBase
on always did an flock() before APPE BLAN. Does anyone know if this was
required under a previous incarnation of Foxbase, dBase III/III+, etc. ?

> On another tack - has anyone seen 'Invalid Signal Received' cropping up
> when returning to a function called after a READ MENU TO mVAR 
> function?  It happens 5 out of 7 times on a customer's machine, and
> it's *EXTREMELY* annoying.  How about getting an error 'Feature Not
> Available' at the same point, eh? (oh - SCO Xenix 2.3.1, SCO Fox
> 2.1.1, '386/20 w/4megs RAM, DigiBoard/8i)

I see this error on our developement system when someone re-compiles a
module that is being run by another user. It comes down to the run-time
interpreter losing it's place in the file. This would also happen if
the "compiled" .fox file is corrupted. Try re-compiling.
-- 
< Alan H. Mintz             | Voice +1 714 980 1034       >
< Micro-Quick Systems, Inc. | FAX   +1 714 944 3995       >
< 10384 Hillside Road       | uucp:     ...!uunet!mq!alan >
< Alta Loma, CA  91701 USA  | Internet: alan@MQ.COM       >