You can't do that

[Jeff Harrison]

--- GCC <gccconsulting at comcast.net> wrote:

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

I see no reason why in this scenario you could not
designate one table as the header table for multiple
child tables.  You would just set up a separate rule
for each child table.  Likewise, a child record for
one table could be a header record for another - it
would just take another rule.

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

You mention a lot of tables, but you have not
mentioned what the exact relationships are.  The type
of rule that I am describing here would not be
applicable in every situation.  An example of where it
would apply would be in the inventory record that you
mentioned.  If the rule was set up properly you would
not be able to delete an inventory record if there
were outstanding orders for that item.

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

I'm not sure what you mean here.  Anyone that does
application development in filepro would be able to
override the rules.  The fact that the rules are there
should be sufficient warning to them that they should
not, though.  If they do override them and corruption
ensues, then they would have some 'splainin to do.

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

I don't think you would want to make the rules that
complicated.  I'm not saying you would have a rule for
every situation.

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

One could and should make the documentation that you
suggest.  Sometimes programmers even do.  Alas, in my
experience this has not stopped the corruption. 

> The major problem, and one "Enforced Rules" can't
> help is not knowing or
> remembering what programs may be affected by new
> programming. 

Wait a minute.  That is exactly where "Enforced Rules"
can help!  Say for example a certain field should have
an even value, and the programmer forgot this along
the line somewhere.  If a rule for this was put in
place then this is now one item that would be safely
protected from corruption.

> We have all
> probably run into this with system we wrote.
> 

Nope, John has not.  :-)

Jeff Harrison
jeffaharrison at yahoo.com

Author of JHExport and JHImport.  The easiest and
fastest ways to generate code for filePro exports and imports.

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