Re: Strategy to allow one user to drop another from the server

2017-03-07 Thread Douglas Cryer via 4D_Tech 
Kirk,

We had a similar requirement.  In our case it was users remaining logged on 
after they had gone home.  We needed them to be kicked off in order to run 
maintenance and so the backup was not slowed.

I used execute on client to display a dialog to the user informing them that 
they would be logged off in x seconds/minutes.  In our case they had a choice.  
If they were really there and wanted to continue working they could click one 
response, or they could click quit.  After the specified time the user was quit 
out.  It would be easy enough to write a corresponding reply to the original 
user to inform them that the target user did not wish to quit.

Regards,  Dougie


telekinetix Limited- J. Douglas Cryer
Phone : 01234 761759  Mobile : 07973 675 218
2nd Floor Broadway House, 4-6 The Broadway, Bedford MK40 2TE
Email : jdcr...@telekinetix.com   Web : 
http://www.telekinetix.com 

 

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Strategy to allow one user to drop another from the server...

2017-03-06 Thread rooftop99--- via 4D_Tech 
Execute on Client, of course!!  Thanks Chip, Chuck, and Timothy!


> On Mar 6, 2017, at 2:45 PM, Timothy Penner  wrote:
> 
> Calling QUIT 4D with EXECUTE ON CLIENT with a uniquely named/registered 
> client has already been mentioned (twice), that's probably what you need. 
> Here are some links to get you started:
> * REGISTER CLIENT: http://livedoc.4d.com/4Dv15.4/help/Command/en/page648.html
> * GET REGISTERED CLIENTS: 
> http://livedoc.4d.com/4Dv15.4/help/Command/en/page650.html
> * EXECUTE ON CLIENT: 
> http://livedoc.4d.com/4Dv15.4/help/Command/en/page651.html
> * QUIT 4D: http://livedoc.4d.com/4Dv15.4/help/Command/en/page291.html
> 
> Just in case you want alternatives, here are a couple other ideas:
> 
> * If the user is an Administrator or Designer you could present the 
> Administration Window with OPEN ADMINISTRATION WINDOW then allow them to drop 
> the user. Although there are other things they could also do from this user 
> interface that you may not want them to do so be careful:
> http://livedoc.4d.com/4Dv15.4/help/Command/en/page1047.html
> 
> * You could automatically logoff idle users with the "Tech Note: Idle User 
> Detective" http://kb.4d.com/assetid=76221
> This Technical Note discusses and demonstrates a technique for monitoring 
> user inactivity, displaying a countdown dialog and warning when a user is 
> approaching an established user inactivity timeout, and how it will quit 4D 
> in Remote mode when the timeout has expired.
> 
> -Tim
> 
> 
> 
> Timothy Penner
> Technical Services Engineer
> 
> 4D Inc
> 95 S. Market Street, Suite #240
> CA 95113 San Jose
> United States
> 
> Telephone : +1-408-557-4600
> Standard :  +1-408-557-4600
> Fax :   +1-408-271-5080
> Email : tpen...@4d.com
> Web :   www.4D.com
> 
> 

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Strategy to allow one user to drop another from the server...

2017-03-06 Thread Timothy Penner via 4D_Tech 
Calling QUIT 4D with EXECUTE ON CLIENT with a uniquely named/registered client 
has already been mentioned (twice), that's probably what you need. Here are 
some links to get you started:
* REGISTER CLIENT: http://livedoc.4d.com/4Dv15.4/help/Command/en/page648.html
* GET REGISTERED CLIENTS: 
http://livedoc.4d.com/4Dv15.4/help/Command/en/page650.html
* EXECUTE ON CLIENT: http://livedoc.4d.com/4Dv15.4/help/Command/en/page651.html
* QUIT 4D: http://livedoc.4d.com/4Dv15.4/help/Command/en/page291.html

Just in case you want alternatives, here are a couple other ideas:

* If the user is an Administrator or Designer you could present the 
Administration Window with OPEN ADMINISTRATION WINDOW then allow them to drop 
the user. Although there are other things they could also do from this user 
interface that you may not want them to do so be careful:
http://livedoc.4d.com/4Dv15.4/help/Command/en/page1047.html

* You could automatically logoff idle users with the "Tech Note: Idle User 
Detective" http://kb.4d.com/assetid=76221
This Technical Note discusses and demonstrates a technique for monitoring user 
inactivity, displaying a countdown dialog and warning when a user is 
approaching an established user inactivity timeout, and how it will quit 4D in 
Remote mode when the timeout has expired.

-Tim




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Strategy to allow one user to drop another from the server...

2017-03-06 Thread Charles Miller via 4D_Tech 
On Mon, Mar 6, 2017 at 4:23 PM, rooftop99--- via 4D_Tech <
4d_tech@lists.4d.com> wrote:

>
> In a large client/server install we are implementing a function to allow
> one user (client) to drop another from the server.  It seems that
> regardless of how much training is given, inevitably someone during the day
> walks away from their computer (lunch, etc.) with a record opened.
> Managers of the department who need access to the locked record attempt to
> contact the offending person.  If they can’t they call the development team
> to drop the user from the server. I would like to cut out the middleman -
> me…grin.
>
> I am just curious how others are handling this…?  I have two possible
> strategies in mind:
>
> -  Run a monitoring loop on each client that will test a flag.  If flag is
> true, quit 4D.  (Easy, but adds another resource pull on the server/client.)
> - Have 4D execute a command line statement to kill the app on the
> offending machine.  (Fairly easy)
>
> Any thoughts?  I am hoping I overlooked something and someone will say -
> “4D already has this function, just call xyz command..."
>
> Thanks,
> Kirk


make sure you register each client with a unique name. and then do an
execute on that client a method that quits 4D. Please not if you do this
changes to open records will not be saved.

Regards

Chuck


-- 
-
 Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
 Informed Solutions, Inc.
 Brookline, MA 02446 USA Registered 4D Developer
   Providers of 4D, Sybase & SQL Sever connectivity
  http://www.informed-solutions.com
-
This message and any attached documents contain information which may be
confidential, subject to privilege or exempt from disclosure under
applicable law.  These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution, disclosure,
printing, copying, storage, modification or the taking of any action in
reliance upon this transmission is strictly prohibited.  Delivery of this
message to any person other than the intended recipient shall not
compromise or waive such confidentiality, privilege or exemption
from disclosure as to this communication.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Strategy to allow one user to drop another from the server...

2017-03-06 Thread Chip Scheide via 4D_Tech 
execute on client (Quit 4d)

getting it to right client might be the trick  :)


On Mon, 06 Mar 2017 13:23:11 -0800, rooftop99--- via 4D_Tech wrote:
> Hi,
> 
> In a large client/server install we are implementing a function to 
> allow one user (client) to drop another from the server.  It seems 
> that regardless of how much training is given, inevitably someone 
> during the day walks away from their computer (lunch, etc.) with a 
> record opened.  Managers of the department who need access to the 
> locked record attempt to contact the offending person.  If they can’
> t they call the development team to drop the user from the server. I 
> would like to cut out the middleman - me…grin.
> 
> I am just curious how others are handling this…?  I have two 
> possible strategies in mind:
> 
> -  Run a monitoring loop on each client that will test a flag.  If 
> flag is true, quit 4D.  (Easy, but adds another resource pull on the 
> server/client.)
> - Have 4D execute a command line statement to kill the app on the 
> offending machine.  (Fairly easy)
> 
> Any thoughts?  I am hoping I overlooked something and someone will 
> say - “4D already has this function, just call xyz command..."
> 
> Thanks,
> Kirk
> 
> P.S. This is an all Windows based 4D installation...
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**