You can't do that

[Chad McWilliams]

> Okay, it's just that I have NEVER, not even once run into a 
> situation where there are child records with NO header 
> record. I think if that happens, there is something 
> improperly written.  However, I have heard of this happening 
> to others who are the best filePro programmers I know... so, 
> I suppose I must grant that it can happen somehow even to the 
> best of us. Just haven't ever seen it yet. So, implementing 
> code to ensure that it never happens, when it never has... is 
> sort of silly to me. At least, there are hundreds of things 
> I'd rather see in filePro first.
> 
> John
> 

This brings up something I've been curious about.  Here's the situation:

Order entry screen with 2 screens.  The first screen contains the header
information.  The second screen is where items are added.  The data is
stored in master/detail files.  Users are connecting over a remote link
(anzio over ssh).  The user would enter information for the header, then go
to the second screen and enter the detail items.  Before they would exit the
order the link would go down.  When the reconnected and tried to pull up the
order, it wasn't there (that is the header wasn't).  I could look in the
detail file and see the detail items, but the record in the header file was
not there.  The problem was fixed by issuing and explicit WRITE when
switching from screen 1 to screen 2.

Should that explicit WRITE be necessary?  For some reason (and please
forgive me if I'm remembering wrong), I was thinking I was told (or read
somewhere) that the record is written out when switching screens.  I have no
problem putting in the WRITE, as this wasn't my code to begin with.  But
this type of thing could be leading to other people's problems as well.

-Chad McWilliams