relational fields and @rf

Jay R. Ashworth jra at baylink.com
Tue Jul 5 06:48:58 PDT 2005


On Tue, Jul 05, 2005 at 06:27:27AM -0700, Jeff Harrison wrote:
> --- Christopher Yerry <christopheryerry at yahoo.com>
> wrote:
> 
> [snip]
> >  
> > Besides
> > - It requires record locks (I have not used them in
> > any program in 14 years. Their are better ways to
> > handle this)
> > - It locks records and cannot run reports (yes I
> > know you can shut it off but it could cause a
> > problem if it is supposed to be locked)
> 
> [snip]
> SQL uses record locks too.  And, no you can't turn
> filepro's record locking off.  If you are updating a
> record then filepro automatically locks everyone else
> out from being able to update the record.  Perhaps you
> refer to a file lock?

I believe he means lookup -p locks.

And, actually, PostGreSQL has joined (and I think actually surpassed)
some of the commercial SQL engines in offering multi-version
concurrency control, so no, you don't have to row-lock at all anymore;
each transaction sees a coherent view of the data.

> > I am not a filepro basher. I do believe @rf is an
> > improper solution and should never be used. It
> > encourages bad programming practices. Common code
> > for multiple tables would be a huge step up.
> > Multiple copies of the same code is suicide!!!! and
> > their is no other way of doing it!!
> 
> I guess you mean @af?  As I mentioned previously, I
> disagree on the word "never".  However, I agree that
> this can be abused.

Sure. 

As I noted early on -- denormalizing requires careful thought.  But
even SQL wallahs do it all the time: if the people aren't smarter than
the DBMS, you have the wrong people.  :-)

> Regarding common code for multiple tables, you can do
> this.  It has been possible for quite some time now. 
> You can specify an alternate processing table (that is
> stored in a central location) from the command line. 
> For example: "dreport filename -f output -z lib/output
> -a"  You can also use "call" or "chain" to get a
> similar functionality.

Though the other aspects of writing library routines, mostly in
parameter passing and variable name collision avoidance, remain.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      If you can read this... thank a system administrator.  Or two.  --me


More information about the Filepro-list mailing list