5.0.14 - freechain

[Richard Kreiss]

I have a client that us3ed to complain that the cursor would jump to the upper left field on the screen from the bottom.  I had to stand watching him add payments to see what was happening.  He was drumming his fingers on his desktop and would then hit the up arrow key.  I had to add code to the processing to make sure that the cursor did not jump to the wrong field. I blocked the arrow keys from doing anything when in that field and used @fd to make sure that if the previous field was the dummy field that the cursor returned to the starting field.

In this case, I am not present when the error occurs.  If it is this clerk, I will have more difficulty in finding what she is doing prior to the rebuild of the free chain.  This operation stops all of the other order clerks from entering new orders.  An order can be between 2 and 250 lines.  On average each clerk is entering about 100 detail lines before going to the next order.  Each clerk usually enters about 250 orders.  That adds about 125,000 detail records each day for 5 days.  That's a lot of records in the order detail file.  The order header file has over 7 million records and the rebuild is best done on the server as this is the fastest way.  The filePro windows is closed using the X(This is not the best way to handle this but so far it has not created any issues.  Keep in mind that although filePro comes of the server, it is running locally on the computer accessing it.  The data files may stay on the server but the processing runs on the local computer.  This is why some operations are faster when run directly on the server. This includes index rebuilds, freechain rebuilds and some outputs.


Richard Kreiss
GCC Consulting



> -----Original Message-----
> From: Filepro-list <filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com>
> On Behalf Of Fairlight via Filepro-list
> Sent: Sunday, October 4, 2020 10:50 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: 5.0.14 - freechain?
> 
> On Sun, Oct 04, 2020 at 09:42:24AM -0400, Jose Lerebours via Filepro-list thus
> spoke:
> > The user's station strikes me as odd as having anything to do with
> > this - I always thought that filePro was exclusively a server side
> > application and no data manipulation happens at the client thus other
> > than being able to connect to server, the client side could be a rock.
> 
> Five'll get you ten that if you take the same user and put them on another
> previously-thought-good station, it'll start occurring there instead.
> 
> People see things like this and want to blame the hardware.  The very first thing
> to look at is user habits, usage patterns, and behaviours.
> 
> All things being equal, the user is the biggest variable.  The codebase is identical,
> the binaries are identical, and barring bad RAM (which would generate far worse
> and more widespread problems), the thing most likely to vary is how the user
> does what.
> 
> m->
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 12399 bytes
Desc: not available
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20201005/99c41160/attachment.bin>