relational fields and @rf

[Jeff Harrison]

--- 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 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.

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.

Jeff Harrison
jeffaharrison at yahoo.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com