Otra vez "matar" o "suicidar" una sesión

[Florencio Beltran de Heredia]

Hace unos días Kike preguntó com o "matar" una sesión desde el servidor.

Vuelvo a preguntar como matar, o mejor dicho, como "suicidar" la propia aplicacción VFP.

Tengo el problema tantas veces comentado de que algunos usuarios dejan las aplicaciones abiertas durante la noche y no las cierran. Habitualmente hago labores de mantenimiento a primera hora del día, pero a veces no puedo porque no cerraron bien la aplicación.

Yo quiero poner edentro de la propia aplicación VFP una función de manera que a una determinada hora (por ejemplo las 22 horas) la propia aplicación se suicide lanzando un proceso que cierre todas las tablas ordenadamente y finalice la aplicación. 

Determinar la hora y cerrar las tablas a través de una función no es ningún problema. El problema es donde colocar la función para que esté continuamente comprobando la hora del día. 

Hay que tener en cuenta que el usuario puede estar en cualquier sitio de la aplicación, menú principal, formularios, reports, etc.

No es posible utilizar el programador de tareas de Windows porque tendría que emplearlo en cada uno de los usuarios y son varias docenas de ellos, algunos en localidades distintas. Todo hay que hacerlo con VFP

Cualquier idea será bien recibida

Florencio

[Carlos Miguel FARIAS]

Tienes que crearle un timer al screen para que chequee el horario. Cerca de tu horario de cierre, mandas un msgbox con timer para que avise que vas a cerrar. Si no hay usuario, pasado el delay del msgbox, empiezas a  cerrar los formularios activos (hay una collection en _screen que apunta a todos los abiertos). Y luego haces un clear todo y en general esa es la solución.
Saludos: Miguel, La Pampa (RA)

[Florencio Beltran de Heredia]

Muchísimas gracias por la respuestasMiguel.

Una duda ¿que quieres decir con poner un timer al "Screen"). ¿A que le llamas "Screen"?

Saludos

Florencio

[Carlos Miguel FARIAS]

_SCREEN, el formulario básico, toda aplicación fox tiene "su escritorio" que es un formulario llamado (apuntado) por el nombre de sistema _SCREEN (ojo, mayúsculas/minúsculas es igual).

Cuando trabajas con el entorno de desarrollo, la pantalla que vemos "detras" es el formulario _screen

Normalmente, es un buen lugar para agregar variables que deben usarse en todos lados, porque _screen es global por si mismo, y entonces no hace falta crear variables globales, con los problemas de "pisoteo" que ello implica.

Acá por ejemplo, cambie color fondo, letra y tamaño del _screen y obtuve una pantalla tipo AS/400 .

Saludos: Miguel, La Pampa (RA)

[Jorge Kiernan]

PROBLEMA: si la aplicación en el puesto de trabajo entro en modo de SUSPENSIÓN O HIBERNACION nada de lo que pongo en el exe de mi aplicación hace nada (ya que no está procesando), pero para el servidor las tablas y archivos siguen estando en uso ya que la aplicación sigue "activa" pero dormida. 

O sea, la solución via timmer es limitada y casi nunca funciona. 

Y evitar que las máquinas entren en suspensión no es posible.

¿Alguien tiene una receta para por programación, poder cerrar las aplicaciones y archivos que están abiertos? 

Con la idea de que el programa que en el servidor va a hacer el mantenimiento preventivo, si detecta que la tabla quedo abierta, la cierre de prepo. 

Estuve explorando los comandos del servidor que permiten cerrar archivos, y más allá del tema de permisos que es un escollo pero salvable, y las diferencias entres las diferentes versiones de servidores de los clientes que obligará a flexibilizar la lógica, me encuentro que estos comandos hacen referencia a los archivos con un id variable y no con el nombre real del archivo, lo cual es sumamente lógico y razonable ya que el mismo archivo se abre N veces.

No encontré como averiguar dichos id a partir del nombre real del archivo, por lo cual los comandos que encontré no logro aplicarlos.

Gracias por los aportes.

El 27 de febrero de 2015, 4:56, Florencio Beltran de Heredia <florenciobel...@gmail.com> escribió:

[Carlos Miguel FARIAS]

Una PC suspende o hiberna luego de cierta cantidad de tiempo sin tener atención del usuario.

Lo lógico es que la aplicación, se cancele más rápido de lo que la PC se "frena".

En mis aplicaciones, por seguridad, configuré que ningún formulario permanece "activo" más de cierta cantidad de tiempo si no hay una actividad del usuario sobre él.

Todos los formularios los creo a partir de una clase que incorpora un timer que luego de cierta cantidad de tiempo inactivo (estando al frente) se cierra.

De esa manera, en un lapso que deberás mensurar para elegir el apropiado, tu aplicación tiene que quedar en la pantalla de inicio (o cancelada) si el usuario no está trabajando con ella. Es más, si la aplicación tiene control de usuario propio, debe quedar este deslogueado.

No solo por razones de que se hiberne el equipo, si no por seguridad. Si el usuario fue  a Tolomeo y se encontró con Kawasawa, se demora mucho y no puede dejar por descuido la aplicación (y los datos que accede) expuesta a un "travieso" que haga destrozos. Ni te cuento los que se van a almorzar y hacen sobremesa o los que se fueron apurados a casa y dejan todo abierto.

Saludos: Miguel, La Pampa (RA)

[Victor Espina]

De acuerdo contigo Miguel.

En mi opinion, la mejor solucion al escenario de la estacion "dormida" es lograr que tu aplicacion se cierre automaticamente ANTES que la estacion entre en ese estado.  La forma de lograr esto es finalizar la aplicacion luego de un cierto tiempo de inactividad (lo cual se logra con un TIMER y un evento ON MOUSE), que sea menor que el tiempo que le toma a la estacion entrar en suspension.

Ahora, tomen en cuenta que no siempre es facil obligar a una app de VFP a terminar.  La mejor forma, y la mas segura, es cerrar todos los archivos abiertos en todas las sesiones (lo cual se puede lograr con un AUSED()) y luego mandar a finalizar el proceso en Windows.  Para esto, puedes usar este codigo:

http://www.victorespina.com.ve/wiki/index.php?title=Finalizar_la_aplicacion_actual_mediante_un_Abend_(VFP)

Saludos

Victor

[Jean Pierre Adonis De La Cruz Garcia]

Con respecto a que no se puede hacer nade al respecto de la Hibernacion o Suspension, veo que no es asi, claro que ustedes puedes decirles a la PC si entra en Hibernacion o No, ustedes pueden programarlas

Panel de control\Hardware y sonido\Opciones de energía

Hay pueden entrar y decirles si la maquina entra o no en Hibernacion o Suspension despues de cada tiempo, entonces, es muy simple, si yo a mi PC Cliente, lo programao, para que entre en Hibernacion o Suspension despues de 10 Min, de inactividad, desarrollo a mi Sistema un pequeño modulo que cuando haya inactividad del Sistema despues de 9 Min, que se cierre mi sistema correctamente, cerrando todas las tablas en modo de programacijn, y asi evitare que esten abiertas despues de hibernad o suspender.

A la vez, a mi Sistema Princiupal, le adiciono un modulo, que me indique que pc, esta activo mi sistema, ya es cosa de adecuarse a las necesidades.

Espero que se pueda entener lo que digo,

Cualquier consulta adicional la pueden seguir haciendo, somos muchos que podemos aportar algo distinto.

[Florencio Beltran de Heredia]

Muchas gracias a todos por las respuestas. Es suficiente para encontrar la solución. Buen trabajo y buen fin de semana

Saludos

Floren

El jueves, 26 de febrero de 2015, 23:09:14 (UTC+1), Florencio Beltran de Heredia escribió:

[Jorge Kiernan]

estas soluciones no me sirvieron:

EVITAR QUE SUSPENDA EL EQUIPO: No me es posible, Cada usuario configura su máquina a su manera. Y tratar de quitarles esto puede provocar una insurrección.

HACER QUE EL SISTEMA SE CIERRE X INACTIVIDAD así lo tengo hecho, tomando por actividad cualquier tecla, movimiento del mouse sobre cualquier objeto, etc, relindo y super hot, pero no sirve, los usuarios casi me linchan y tuve que flexibilizar el tiempo, que cada usuario en definitiva configura ¿a que valor? adivinen... lo más alto que pueden, siempre más que el tiempo de suspensión del equipo.

SABER CUAL ES EL EQUIPO QUE QUEDO INACTIVO, lo implementé, solo para amargarme más la vida. Al entrar al sistema guarda el usuario con fecha y hora de ingreso, y cuando sale fecha y hora de salida. Maravilloso, así se cual fue el turro que se fue a su casa dejando la PC suspendida, con el acceso protegido con contraseña que no tengo, en una oficina cerrada con llave.

Por eso estoy buscando por el lado del servidor, un control automatizado de la consola de actividad, para cerrar de prepo las cosas.

¿Alguien tiene idea de como lograrlo?

Gracias por su tiempo.

[Jean Pierre Adonis De La Cruz Garcia]

Tengo 2 ipotesis, 

1. quizas, solo estas experimentando en las maquinas de una empresa u oficina, la cual no te dejan que tu tomes las deciones como encargado de sistemas.

2. No tienes la suficiente autoridad como para tomar la decision de que deben de adaptarse a las reglas del encargado de sistema.

Pero bueno, ya cada uno toma las decisiones, te dare otra alternativa mas facil, lo que mas me agrada ami. AUTOMATIZACIOn

la logica es, a determinada hora, desactivar la Hibernacion, para que no te genere ese problema.

Activa la hibernacion

powercfg /hibernate on
desactiva la hibernacion

powercfg /hibernate off

La otra alternativa, pero debes buscar informacion por tu parte, es por medio de Automatizacion, saber cuanto es el tiempo que esta programado la Hibernacion cada pc, y decirle que se cierre 1 min, antes de iniciar la invernacion.

Claro ahi si debes de tomar logica de programador, y de esa manera ya no te gritaran los demas empleados,y te diran que los dejes que ellos hagan lo que quieran y tu no te metas, jejeje

felizmente es viernes, no pensaba reirme.

 

[Antonio.xt]

<< estas soluciones no me sirvieron: >>

Esas soluciones si te sirrven, pero no te dejan implementarlas.

Yo creo que aqui debes de informar de la seriedad del asunto, no es posible que los usuarios sean los que decidan el tiempo de inactividad de su PC (si se puede, pero no debe ser asi), si la empresa tiene interes en poner controles debe tambien ir quitando esos malos habitos, los usuarios deben de entender, sino no te pueden hacer responsable de que algo falle.

[Victor Espina]

El problema que vas a tener ahi es que, del lado del servidor, lo unico que podras hacer sera mandara a terminar el proceso en Windows, pero de ninguna forma podras mandar a cerrar las tablas que estan abiertas en esa sesion.

Victor

[Staff de Desarrollos EfiMax]

Jorge:

 

evitar que las máquinas entren en suspensión no es posible

 

En realidad si puedes evitar que se suspendan e invernes con el administrador de energía de cada PC.

 

No he seguido el hilo desde el inicio, pero si cargas el entorno de la BD en el Load del formulario y pones un timer digamos t=1000*60*10 al formulario le puedes dar un tiempo máximo de vida de 10 minutos de inactividad, toda vez que cada vez que se presione un botón en el formulario  reinicias el tiempo de tal forma que al alcanzar el t meta desencadenas el Thisform.Relesase() del formulario previo close data y descarte de la edición del usuario, con lo cual el tiempo máximo de espera de inactividad que espera el servidor al usuario es de 10 minutos a que cierra la BD (inactividad real en el sistema no cosas como mover el mouse o estar trabajando con el face con el sistema en segundo plano).

 

Suerte.

 

 

 

____________________________________

Carlos Omar Figueroa López

Ingeniero Industrial y de Sistemas

http://www.efimax.com.mx

[Fernando D. Bozzo]

Hola Florencio:

Te dejo un par de ideas complementarias que implementamos en nuestro sistema:

1) A las 23:00 hs, ¡a dormir! => El sistema cierra las ventanas abiertas y se cierra solo, ya que hay un timer de sistema que verifica la hora cada 30 segundos (no hace falta más). Vos podrías poner la hora que te parezca mejor.

2) Si se deja un archivo bandera, ¡todos fuera! => El mismo timer, cada 30 segundos verifica si en el servidor hay un archivo bandera (por ej: SALIR.TXT) y si lo encuentra comienza el proceso de cierre. Esto te permite escribir ese TXT cuando quieras para forzar una salida "administrativa" de mantenimiento. Incluso podés aprovechar el TXT para poner un mensaje dentro y mostrarlo con un mensaje --no -modal-- en la aplicación para notificar al usuario de lo que va a suceder

3) Si algo de lo anterior falla, ¡Arakiri! => El control de errores en el timer debe ser bueno, cosa que si se detecta algún error no controlado, se mata el proceso de la aplicación


Dejo adjunto un programa llamado "matar.prg" que con solo ejecutarlo (DO MATAR.PRG) mata la sesión de FoxPro que lo invoque, o el EXE de FoxPro que lo ejecute.


Saludos!

El jueves, 26 de febrero de 2015, 23:09:14 (UTC+1), Florencio Beltran de Heredia escribió:

[Florencio Beltran de Heredia]

Gracias Grupo. La verdad es que ya había logrado mi propósito con las ideas de varios de vosotros. 

En cualquier caso, para que le pueda servir a alaguien, todo se basa en añadir una clase basada en el objeto timer que coloco en el objeto _screen.

Más o menos así:

with _screen

.visible=.f.

.Height=528

.Width=795

.caption=".........nombre aplicación...."

.icon='.........ico'

.closable=.f.

.ADDOBJECT("IMAGEN1","IMAGE")

.IMAGEN1.PICTURE=".....logo.....gif."

.IMAGEN1.top=350

.IMAGEN1.left=100

.IMAGEN1.VISIBLE=.T.

.windowstate=2

.visible=.t.

.ADDOBJECT("oTemporizador","temporizador_salida")

endwith   

La clase temporizador_salida se basa en un timer, que cada 10 minutos comprueba si se han sobrepasado las 10 de la noche. Si esto ocurre, cierra ordenadamente las tablas y provoca un cierre de la aplicación.

No obstante, en vuestro comentarios hay dos o tres buenas ideas que voy a implementar y mejorar. Una de ellas es provocar la salida de los usuarios, no solo a las 10 de la noche, sino cuando yo quiera, símplemente dejando un archivo bandera SALIR.TXT. jejeje, me llamarán sin saber que ha pasado. Sólo notaran que se ha cerrado la aplicación sin previo aviso

El jueves, 26 de febrero de 2015, 23:09:14 (UTC+1), Florencio Beltran de Heredia escribió:

[Jorge Kiernan]

Respuestas varias en un mundo complejo.

Fernando, tengo implementadas este tipo de soluciones, y no me cubren todos los casos.

BANDERA: El archivo "bandera" en mi caso se llama bloqueo.txt y es verificado exitosamente... siempre que las máquinas estén activas.

A DORMIR A partir de las 21 horas, el sistema le pregunta al operador si está por ahi o no, si no recibe respuesta afirmativa en un par de minutos, se cierra. Y asi cada 30 minutos hasta llegar a medianoche. Pero nuevamente, si la máquina entro en suspensión nada está procesando, y no hay timer que valga.

Carlos, no puedo tomar control de cada configuración de cada equipo, que por otro lado están desparramadas por unas 10 locaciones físicas diferentes, pertenecientes a 6 empresas.

Jean Pierre

HIPÓTESIS NO CONTEMPLADA soy proveedor externo de los sistemas, así que mi autoridad en ese aspecto es solo moral. En algunos casos ni siquiera tengo un interlocutor válido dentro de la empresa.

Por todo eso es que estoy buscando explorar el cierre  de los archivos desde el servidor.

Victor. desde la consola interactiva del servidor lo he podido hacer ... en realidad lo ha hecho el soporte técnico interno de la empresa, que si tiene acceso al servidor, pero ha podido rastrear las aplicaciones abiertas y cerrarlas, liberando los archivos en uso.

Seguiré buscando a ver si encuentro la manera. Gracias a todos.

[Fernando D. Bozzo]

Hola Jorge :

Aquí otro "externo", aunque prestando servicio dentro del cliente :-)

Desde el lado del servidor podés hacer un programa que corra como servicio y que se ejecute con credenciales de administración (lo llamamos usuario-app), pero limitado, que tiene permisos solo dentro del servidor y no en toda la red, de forma que use un timer para realizar tareas administrativas o de mantenimiento para la aplicación, como reindexar o reemplazar algún archivo y matar las conexiones de los equipos clientes a la aplicación del servidor usando wmi al igual que hace Windows con la consola que muestra los recursos compartidos en uso y quién los tiene.

Pero lo que realmente te puede salvar es no dejar las tablas todo el tiempo abiertas, que suele ser el error más común y que más corrupción de datos ocasiona.
Las tablas solo deben abrirse para actualizar o consultar, y el resto debería trabajarse en cursores locales. De esta forma no se pierde nada.

Saludos

[Jorge Kiernan]

Fernando, gracias por el dato, voy a buscar por el lado de wmi.

Lo que describis es justamente lo que estoy tratando de lograr.

En cuanto a lo de la apertura de los archivos, suelo abrir todo al comienzo desde el entorno de datos y que se cierre al salir del formulario, que trabajan con sesión privada de datos, aunque luego el origen de datos de los objetos que se van a modificar están sustentados en cursores. 

La apertura de los archivos es algo que lleva un tiempo sensible, de ahí que dejo todo abierto hasta que salga. Podría ver lo que decis de cerrar los archivos y reabrirlos en la grabación, a ver que resulta. 

Gracias por las ideas.