Ayer mismo cometi la torpeza de usar una variable global en memoria en un trigger… Por supuesto, la variable en el vServer siempre estaba vacia por mucho que la cargase correctamente en el vClient…
¿Alguna solucion? Algo he leido por ahí de usar una funcion en 3er plano que devuelva no se que, pero no encuentro nada practico en el foro… Y tampoco en la base de conocimientos.
¿Algun enlace?
Tengo unos doce triggers a los que tengo que pasar un dato local al vClient… Y no me gustaria cargarme los doce triggers y programarlo todo en el vClient… Usando triggers todo queda mas limpio…
Se puede traspasar el valor de una variable global en memoria, desde 1er plano (vClient) al 3er plano (vServer), simplemente disparando un proceso en tercer plano. Ese proceso debe tener una variable local, donde cargaremos el valor de la variable a traspasar, antes de disparar el objeto. El proceso solo debe contener una linea, que modificara la copia de la variable del vServer con el valor de la variable local (modificar variable global).
Por supuesto, esto puede tener problemas de concurrencia… Si varios usuarios “traspasan” su variable a la vez al vServer, a saber cual pilla la ultima…
Para casos como el que planteas y “posyaque” para alguno mas. suelo utilizar una tabla.
El ID de la tabla lo creas de tipo alfa, ademas pones un campo nombre y si quieres para evitar la concurrencia de usuarios, un campo enlazado a la tabla de usuarios.
Cuando necesites pasar datos entre cliente y servidor, creas un registro. Imagina que quieres grabar lo que ahora tienes en una variable llamada permiso para el usuario 1 y que valga por ejemplo “Accede”
En el ID de la tabla grabarías “PERMISO”, en el campo nombre grabarías “ACCEDE” y en el campo usuario, “1”
Después sólo tendrías que cargar la lista por el id (o por ID + USUARIO), leer la ficha que necesites (en este caso “PERMISO”) y asignar el valor del campo nombre.
Esta tabla la puedes hacer en disco o en memoria… a gusto del consumidor.
Gracias, Vila. Tu enfoque es muy util, y seguramente implemente algo asi en el futuro.
Os cuento porque surgio la necesidad (no vaya a ser que algun fiera sepa hacer esto mejor)…
El problema fue GetClientIP(). Utilice la IP del vClient para guardar la traza de que maquinas modificaban los datos. Al principio con GetClientIP() todo funcionaba como la seda…
Hasta que empezaron a usar Terminal Server (o como se llame ahora) para el acceso con vClient. Hala, a la porra GetClientIP(), no funciona en este caso (bueno, si funciona, pero devuelve la IP del servidor TS lógicamente).
A mi compañero de sistemas se le ocurrio una solucion, bastante guarra por cierto: hacer un PING por nombre desde la sesion TS hacia la maquina del usuario (el nombre de la maquina del usuario esta disponible en un variable de entorno), guardar la salida en un TXT y leer el TXT para extraer la IP. Mas guarro imposible. Pero funciona…
Y despues de poner todo eso a funcionar, y tener la IP en una hermosa variable global en memoria, me encuentro el problema de que solo puedo usuarla en el vClient, si la uso en el vServer no pilla el valor… Y resulta que mas o menos el 50 % de las veces que la uso es en el vServer.
¿Se os ocurre alguna forma de hacer esto mejor? Tiene que haberla…
PD: Ya dispongo de una tabla de usuarios, podria tener un campo TEMP_IP auxiliar con persistencia a nivel de sesion sin problemas… En esa misma tabla ya guardo el sysUserName… Se supone que la variable sysUserName funciona sin problemas en 3P ¿verdad?
Podríamos empezar a pensar, ¿por que necesitas que el vClient le mande un valor en variable al vServer?
sysUserName te funciona seguramente por que las altas empiezan en el vClient y ahí si tienen valor. Usar la IP…y si te abren dos vClient, ya te la lian, yo usaría un UUID.
Al final me ha quedado asi. Mezclando las ideas anteriores y las mias. Creo que esta bastante mejor que antes…
En la tabla de usuarios añado un nuevo campo IP_SESION de tipo alfa. Es esa tabla ya tengo el sysUserName.
Cuando arranca vClient, calculo la IP (si es sesion TS con el metodo guarro del PING, si no es TS con getClientIP()) y la guardo en un variable global en memoria V_CLIENT_IP. Justo despues guardo en la tabla de usuarios esa misma IP, usando para buscar el registro sysUserName.
Ademas, he creado una funcion sencillita que sin parametros (usa como parametro implicito sysUserName) va a la tabla de usuarios y me devuelve la IP.
Bueno, pues todo esto parece funcionar adecuadamente… Cuando estoy en 3er plano uso la funcion que me da la IP de la tabla, y cuando estoy en 1er plano uso la variable global. Sin necesidad de andar traspasando variables…
Por supuesto, si el mismo usuario abre varias sesiones en maquinas diferentes, este sistema fallara al usar la funcion (aunque no fallara al usar la variable). No me preocupa demasiado. Todo esto es para registrar desde donde se hacen cambios. No es nada critico para el sistema.
Ahor voy a ver si consigo unificar el tema de la funcion y la variable: no me gusta tener que usar dos metodos segun el plano en que este (acabaré equivocandome seguro).
En vatp://pruebas:pruebas@v7cloud6.velneo.com:8894/0PS_Varios_iapp tienes un ejemplo de traspaso de valores entre el 1º y 3º plano en el ejercicio titulado Procesos_3P. Se usa una variable global en memoria de tipo Array con control de sesiones. Arranca varios vClient en tu máquina y verás que puedes ver el progreso de cada Proceso en 3P de forma independiente. Es otra alternativa de la propuesta de Vila (ayudavelneo) a la tabla en disco.
De todas formas como comenta Manuel, ¿por qué te interesa guardar la IP? En un entorno de Terminal Server seguramente las IP’s serán dinámicas y no te van a dar información de qué máquina y/o usuario ha conectado en cada instancia. Lo más práctico es que guardes en el histórico el Usuario conectado, nombre de máquina y el ID de la Sesión.
Lo que obtengo es la IP de la maquina cliente, o sea, del PC fisico que toca el usuario. En nuestra empresa la mayoria de las IPs son fijas. Ademas, segun el tercer bloque de la IP, conozco el centro de trabajo (central=0, oficina1=1, oficina2=2…).
Esto se cumple tambien para las IPs dinamicas, dado tambien tenemos DHCP.
El direccionamiento IP esta montado asi y me sirve para saber el Centro de trabajo, que es lo que en realidad me interesa.
@victorgt
A lo mejor digo una tontería, pero ahí va
En el proceso principal y en el de 3P, creas una variable local para la IP Cliente (pues en el proceso principal si obtienes la IP del cliente) creas un manejador de objero del proceso que vayas ha ejecutar en 3P, haces un set variable local objeto y a continuación disparas el objeto
Con esto no necesitaras tanlas ni arrays
Creo que puede valer