You can't do that

[GCC]

> 
> Ah, some new ground :-)  In the case of the parent/child 
> rule, which would just be one small example, I think this 
> could be done by adding some fields to the map file, or 
> perhaps creating an auxiliary "rules" file instead.  This 
> file would exist for each filepro file, similar to the way a 
> map file exists for each file.  There could be a Y/N field to 
> specify wether or not this is a child table, and Y/N field to 
> specify if it is a header.  If it is a child table then there 
> could be a field to specify a name of a parent table, and 
> index and a key.  If a header table, then you would specify a 
> child file name, and an index and key.
> 
> Then filepro would just need to do some additional checking 
> (only if this rules file exists and if this particular rule 
> is filled in) when the code attempts to add or delete 
> records.  This would be no burden on performance to existing 
> applications or programmers - you wouldn't even know it was 
> there - unless you needed to!
> 
> Jeff Harrison
> jeffaharrison at yahoo.com

Jeff,

Since I have been away and not read all of the responses, this may be a repeat
of something already said.

This may be fine and good got 1 relationship and header & it's details.  However
this begs the question of additional relationships.  

One creates an order which generates an invoice; which generates and accounts
receivable record(s).  If one has an inventory system which commits inventory
before shipping, that inventory records is affected.  Now suppose someone tries
to delete the order and it hasn't been paid.  What "Rule" would be applied?

This is the programmer's responsibility and should be handled in programming.
Do you allow delegation of the order?

If you are archiving orders and an order is within the date range to be
archived, and it hasn't been paid, do you archive it?

The permutations of what files are affected by any given action are the
programmer's responsibility.  And, if one sets up rules with the program, one
can document what is happening with a comment by the routine.  This should
forewarn another programmer of the purpose of the routine and what should be
looked out for when making any changes or additions.

The major problem, and one "Enforced Rules" can't help is not knowing or
remembering what programs may be affected by new programming.  We have all
probably run into this with system we wrote.

Richard Kreiss
GCC Consulting