You can't do that

[Jeff Harrison]

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

[snip]
> All right. Allowing that the comment may not be
> stupid... both it and your
> agreement with it are still easy to disagree with...
>  Your foundation for
> the argument and using taking away edits as the
> analogy is confused. The
> proper analogy if you want to use edits, would be
> not to take them away...
> but to add another level of "rules" to the edit
> language. Then you would be
> comparing apples to apples...

No, not at all.  I think you are missing the boat
here, and perhaps confusing what I am saying with
another thread where some changes to the edit language
were suggested.  I am not talking about adding rules
on top of the rules that are already in place.  The
edit table is a table of rules that the filepro exe
consults when certain data events occur.  I'm just
talking about adding another table that would enforce
different rules - it would be at the same level as the
edit table - and it would have nothing to do with the
edits at all.

> the other comment was
> pretty ridiculous and I
> can see where Scott would think it so.  Adding more
> complexity to edits
> would certainly not help anything.

Again, you are confusing this with that other thread. 
There was no suggestion in this thread to change the
way edits work at all.

> As for the rules
> you suggest adding to
> filePro somewhere... it sounded originally like you
> meant the processing
> table area... 

Once again you are confusing what I said.  The
modifications to the processing area that I suggested
were in reference to creating user defined functions.

[snip]

> I'll let my previous statement stand
> that this is not a
> reasonable place for them and there is no existing
> place for them since
> there is no overviewing structure to a group of
> tables. Currently, as you
> know, filePro tables are not related in any way...
> solely through lookups
> can there be some association and/or grouping.
> filePro is a "flat file"
> system... which would be analogous to free-tables in
> other RDBMS systems.
> And they, too, by the way, would have no rules that
> interplay between
> themselves because free tables are "outside" of a
> database container.
> 
> I think asking for this is like asking for primary
> key joins in filePro. It
> is simply not going to happen. Why not shoot for
> things that CAN happen and
> would enhance the product?
> 

I have previously detailed one way for this to be
implemented without the complexity that you seem to
fear.  If *I* can come up with something like this
just think of what the real brains can do!

Also, I have had some private replies including one
from someone within fptech that agree that some of
these things would be worthwile and would have zero
adverse impact on existing applications.  I have been
asked to submit a summary so that they can review
these for possible inclusion in a future version.

Jeff Harrison
jeffaharrison at yahoo.com

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


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs