You can't do that

[Jeff Harrison]

--- John Esak <john at valar.com> wrote:

[snip]
> Don't waste your breath Scott. It was precisely
> clear what you meant. The
> above comment comes from the same person who just
...
[Brian bashing snipped]
I don't think you are being fair in the context of
this thread.  If you look at what Brian said regarding
this topic in this thread you will see that it is not
childish and it is very relevant.  I don't really
remember nor do I think that it is relevant what Brian
may have said in other threads.

> And, by the way, to try and drag the content of this
> topic back to the high
> ground, Jeff's suggestion for "rules" that filePro
> supplies, does, as you
> suggest, seem to be just asking for programming that
> really would be done
> better by the programmer. I agree.  Why add another
> level of complication to
[snip]

Well this is ground we already covered so I will spare
you a full reply, and hopefully we can agree to
disagree.  Like anything in application development it
would only be as complicated as you make it.  Also,
Filepro is full of things that can already be done
another way.


> And, if I might agree with Nancy's estimation of
> some of this... Jeff's
> argument that a 2nd programmer can mess things up
> quite nicely... She is
> right, but even the 1st programmer can mess things
> up badly if he/she does
> not approach modification of an existing code set
> with great care. I don't
> believe pre-imposed (canned) rules will help.

The rules would be just as "pre-imposed" as edits are.

> Writing your own rules in the
> first time along WILL help. If you don't want a
> child record of a file being
> removed because it impacts on many other things...
> be certain to write that
> rule (i.e., programming) into your original code.

Again, I think we are re-hashing here - lets agree to
disagree.  One can't write a rule in processing that
would enforce what you are talking about.  Nothing
would stop a programmer from writing a seperate
process that ignores any rule that you may put in
place in your processing table.

> Someone adding/modifying
> the code would simply have to be aware of what is
> required.

Therein lies the problem!

> Unless, we start
> dictating that filePro start carrying databases and
> the equivalent of a
> database container, there would be no real place to
> put such "rules" anyway.

[snip]

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

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