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