Memo magic is really distressing filepro user

[Fairlight]

Top-posted for John's comfort...

See, I'll agree that if one looks at the mechanics of export, it shouldn't
close implicitly for exactly the reason you cite.  I can't argue with your
logic.  Incidentally, that was precisely the problem this gentleman had;
there was a race condition between end of exporting and a command that
was to do something with the file via system().  We even tried inserting
pauses, to no effect.  That buffer plain does -not- flush no matter how
long you give it.  We're talking about an attempted 15 second sleep failing
to produce results.  It's just obviously not hitting the VFS layer for
commit to disk.

My suggestion would be for the engine to do something akin to fsync(2) at
the end of every granular export operation, after the internal write(2)
call(s) is/are completed, but before the next opcode.  Then it would
give the appearance of acting like other things that implicitly close,
yet maintain its logical consistency with its intended purpose.  It may
impose some performance degradation on a busy system (especially one with
IDE drive chains) whose VFS layer is bogged down, but the upside is that
your data should never be incomplete unless the program crashes, even if
the programmer completely ham-fists their code.  It'd be functionally
equivalent to turning on sync in NFS; sure, you take a definite performance
hit (with NFS v2 it was on the order of 90%, but NFS has -way- more
overhead involved than this would), but you're also as sure as you can be
of your data integrity.

Technically, the onus still probably belongs on the developer at the 4GL
level to know what's going on.  The only problem with that is that fP does
so much elsewhere that's seemingly inconsistent with the current behaviour
that the developer might get confused or just plain forget.  Hence, I
suggest emulation of the same safety net that fP provides pretty much
everywhere else.  

Maybe it could be optional via an env var--on by default to catch it for
most people, but if you turn it off you take full responsibility for
making sure you do things right while negating any ensuing performance
hit.

Just a suggestion/opinion...

mark->

> John Esak said:
> 
> Now, this is not a bug either... since why should a close be issued when
> things aren't still finished. HOWEVER, the funny, ironic thing about this...
> is I had just (like 3 months ago complained to Ken... and I hope followed
> with a memo to support) that after doing an export to a .csv file... (going
> to be used as an Excel spreadsheet), when I got to @done I wanted to add
> some "totals" to a last line in the file. Process kept aborting saying that
> the export filename was not available. So, it had apparently been closed
> befor @done.  Ken agreed that this file should not be "implicitly" closed
> just because there are no more records to process... and should be available
> in @done.