You can't do that

[Fairlight]

Accidentally coming in on a thread I've skipped most of.

This public service announcement was brought to you by Chad McWilliams:
> > John Esak said:
> > 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 

That'd be my first guess--programmer error.

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

Well, a lot of people have believed a lot of things.  Had a situation 2
nights ago where we were doing CSV exports so my software could translate
them to proper XLS files.  Problem was, I had a sanity check that I'd
-never- have expected to be triggered--go off.  But only from within
filePro as a system() call.  If you ran it standalone in fP and took the
file externally, it passed through my program as expected.  Inside fP, as a
system() call after the export was supposed to be done, it detected missing
fields--a mismatch I checked for to make sure every row had the same number
of fields as the first row did, assuming the first row to be a baseline
column count.  Further investigation showed the file was five lines short,
to boot.

Turns out that we thought it might be a disk caching issue, so a sleep for
5 seconds was put in.  Still no joy.  Finally I said, "Put in an explicit
close on the export."  The developer didn't think it was necessary, as that
was supposed to be implicit at least since the DKNF and Too Many Open Files
stuff was all fixed.

But low and behold, you do an explicit close on the export, and all the
data is flushed properly, and the data integrity was fine.

Some of the "accepted wisdom" out there is not quite in tune with reality.
And this is not the fault of the developer--I respect them greatly.  They'd
thought it didn't need an explicit close as has been propogated in the
community, and I think even I've even heard that they're not supposed to be
required.  So much for that theory.  But I rarely trust anything
implicitly.  Even in perl, where I -know- all file descriptors are flushed
before close on file exit, I do manual close() statements on every handle
before exiting, at whatever point is necessary--even on a signal handler
that catches SIGINT.  I know it -does- work there, but I still opt to be
safe.

Expect the unexpected.  I'd rather have a little superfluous code that I
can be sure is not my fault if it goes wrong, than not have enough and have
something bad happen.

I always write and then close lookups separately and explicitly in filePro
as well.  Always.  I don't trust the "common wisdom" that that's not
supposed to be necessary.

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/
FairView Image Viewer for Integration:          http://fairview.fairlite.com/