escaping idle users back to menu

[Rkreiss@verizon.net]]

-----Original Message-----
From: Kenneth Brody <kenbrody at spamcop.net>
Sent: Saturday, February 12, 2011 5:38 PM
To: Richard Kreiss <rkreiss at verizon.net>
Cc: 'FilePro Mailing List' <filepro-list at lists.celestial.com>
Subject: Re: escaping idle users back to menu

On 2/12/2011 5:02 PM, Richard Kreiss wrote:
[...]
> The problem my client has is that they have many employees working remotely
> through terminal server.

So, we're talking Windows, not *nix.  In that case, all of the suggestions 
about "idleout" are irrelevant here.

> As they are working at client sites, they
> sometimes get distracted and their session times out and disconnects.  In
> and of itself, this is not a problem.  However if they are in update mode,
> this will lock the file and create other problems with tasks scheduled to
> run at night.

So the session is disconnected, but the programs are left running?  (Does 
this mean that, if they reconnect later, they're back to where they left off?)

Yes

> Their disconnected session is then logged off.

What do you mean by "then"?

A system manager goes into the terminal session manage, selects the disconnected session and logs it off

> One other problem arose which we just discovered and fp support does not
> understand why this should be a problem.  On the terminal server machine,
> c:\fptemp is where fptmp is set.

What does PFTMP have to do with record locks?

Nothing to do with record locks except that after deleting the 1550 or so files in fptemp, users were able to enter comments.  Before these files were deleted, when a user tried to enter a comment, the session froze.

> Over the last 5 years for one reason or
> another, there were somewhere between 1500 and 1600 files left in this
> directory.

While that may affect filesystem performance, it shouldn't have any other 
effect on filePro.

See my comment above.  Files deleted, program works.

> The other day, every time someone tried to access the
> market_memo file, the system locked up and the session had to be closed by
> clicking on the<X>  in the window.  After these files were cleared out, the
> programs have worked properly.

Sounds like it might be an O/S or filesystem bug.  (Or, perhaps a long-shot, 
there were so many files in that directory, that all of the "unique" names 
were already used?)

Though I suppose it depends on what you mean by "access the file".  Going 
into *clerk doesn't have anything to do with PFTMP, whereas running a report 
does.

>  A task has been added to run at 1AM on
> Sunday when no one will be in the system.
>
> As for rebuilding auto indexes, it makes sense if an index has gone bad for
> some reason and all work has to stop to rebuild the index Especially if the
> work day runs from 8:30 AM EST to 9PM PST.

Do you have any reason to believe that an index has gone bad?

Yes, filePro reports that automatic index X needs to be rebuilt.  This entails getting 10 people in the office off and 1 - 20 remote usersd off.  That means all work stops.

Now you may be correct about the file names. By deleting any orphan files once a week, they should not run into this situation again.  This may also solve the index problem as most of the time it was on market-memo.

> One other thing, the program adding records to the market_memo file has been
> changed from using a popup update to the file, to popup update - and using
> dummy fields to get the comment being added.  Only when the memo info has
> been confirmed will it get posted.  This removes the chance that a session
> will be left open while someone had a record locked in the marketing file
> and in the market_memo file.

What about the record that they're sitting on?

To afd a comment, @key is used.  They are not directly in the marketing record (update mode);
As such, if the session stops or crashes, nothing is lost from the record.

In this application, most update are done using @key and either poping up a screen or updaing one field with input popup nn.

Browse lookups also make usde of @bk to update related information.

Richard
>From phone

[...]



[The entire original message is not included]