saving a record in the middle of data entry

[Barry Wiseman]

On 7/2/2010 12:38 PM, Mike Schwartz wrote:
>      Using filePro 5.0.14 and SCO Unix 5.0.7, I designed a very tightly
> packed data input screen that looks like a mini-spreadsheet.  There are 32
> rows or 6 fields in each column (16 groups of 6 on the left half of the
> screen and 16 groups on the right half of the screen).
>
>      I realize that this is a lot of data entry for one screen.  I'm worried
> that users might get part way through the screen, then lose all their work
> if their internet connection drops.
>
>      I'm would like to set up some kind of "save" routine that will execute
> at certain points as they are doing data entry.  I could execute this save
> routine using something like @wef after every few columns of data entry.
>
>     Before I reinvent the wheel, do any of you have any pushkey routines or
> other ideas that will allow me to save the record periodically and then
> return the users to the same spot on the screen with the least amount of
> interference in the data input?
>
>     I'm also considering copying the screen periodically to an archive file
> or some such thing.  I just need a method that will be relatively fail-safe
> if a user's internet connection drops.
>
>     These screens will be used in fairly high volume data input, where I
> expect the users to get quite proficient in data entry, so I want to
> minimize the time delay or other user interference during this "save"
> process.  The high volume of data entry is what is prompting me to put so
> many data fields on one screen, so that the users don't have to press
> "esc-esc" so often and can see the column totals and compare them to the
> totals on their 32-line data entry sheets before they press "esc-esc".
>
>      I've reviewed some of the pushkey suggestions from past emails, and I
> see that there are some good ideas there.  If I don't get any other good
> ideas, I'll try writing something based on those ideas.
>
>
> Thanks!
>
> Mike Schwartz
>

Mike, I would avoid a pushkey solution that involves forcing a SAVE and then reloading the record and positioning the cursor.  This is surely gonna introduce some lag in the data entry process whenever it fires, and that will be a real annoyance at best to the users.  Instead, I would go with an external file, which you've already considered.  An occasional @WLF (or _every_ @WLF if you like) could do a single "gosub saveit" to write the data entry thus far into the 2nd file. When the primary record has been saved successfully, delete the 2nd.  When entering a record in the primary file, if the 2nd record exists, you can put up a "Recover unsaved data entry (y/n)" prompt and act accordingly.