You can't do that

[GCC]

> >
> > Library routines would not work for this because there
> > would be nothing to enforce the use of these routines
> > on the programmer.  And who is to say that an error
> > would not get introduced into these routines anyway?
> 
> Nope, we disagree again. Sorry. Just too crazy to impose any 
> kind of rules
> on a system and structure that is by its design free from 
> constraint. Your
> very first example, for example, is completely foreign to 
> me... (or you
> stated it badly, perhaps) The idea that you can't have a 
> parent record if
> there is no child data... well, it's too strange for me. THAT is an
> exception, not a norm, and pretty highly undesirable in my 
> mind. So, would
> be almost any other rule along these lines that you can 
> define. Ane as for
> library functions not working because nothing would enforce 
> them, or alert
> you.... well, the first library function you seem to need in 
> your scenario
> of rules could easily be one that enforces library functions. 
> I don't think
> the kinds of rules you are suggesting would help anyone. I think
> understanding the program completely and how it is going to 
> function is more
> important and will server anyone better than enforced rules. 
> Perhaps, some
> of the things you want could be turned on and off with an environment
> variable PFNOVICE=ON/OFF and such. That is the only way I 
> would like to see
> such implemented, if at all. I think they would be of 
> extremely limited
> value in any case. filePro is all about complete flexibility 
> including the
> possibility of making and constructing errors.

John,

Think of what he is saying as header and detail records.  He wants to insure
that there is a header record for all associated detail records, I think.

Now, I consider this a programmers responsibility.  However, one would need to
turn "break off" to keep someone from canceling out of a routine prior to the
header record being created.

Of course, how one writes their program also influences how one manages this
problem.  And, that is the crux of the issue.  Having filePro "control" this
functionality would greatly restrict how one writes their programs.  Again
removing the flexibility inherent in filePro.

Richard Kreiss
GCC Consulting