Cita:
|
Empezado por jachguate
evalua el uso de ClientDatasets, comunicados también por Sockets a la capa intermedia, pero aprovechando lo ya encapsulado en estos componentes.
|
Bien a bien no sé a qué te refieres. Lo que estuve leyendo hace un rato fue acerca de RemoteDatamodules, ClientDataSets y Providers aunque sólo llegué al ejemplito de Login que viene en la carpeta Demos\Midas que parece relacionado aunque todavía me falta para ver cómo un cliente le dice al servidor cositas como "muéstrame en mi ClientDataSet la lista de usuarios". Bueno, sí vi que podría colocar un dataset enlazado a la lista de usuarios en el servidor y conectado al clientdataset del cliente pero me falta ver cómo podría hacer consultas más complicadas.
Cita:
|
Empezado por jachguate
El problema del cuelgue de la pc... sin "despedirse" lo vas a seguir enfrentando... asi que vas a llegar tarde o temprano a una solución similar a esta; entonces por qué no dejar la que ya tenes? (me refiero a la lógica... la implementación, claro, seria desde la capa intermedia)
|
Bueno, es que cuando estuve echándole un ojo a los ejemplos de las Indy me quedé con la idea de que la lógica del timeout ya estaba de alguna manera ímplicita y por ello pensé que cuando el IdTcpServer detectara una conexión cortada, en ese momento mandaría la consulta SQL a la BD para registrar que la sesión había terminado.
Ahora, por otra parte, suponiendo que no voy tan mal encaminado con lo de los RemoteDataModules queda el asunto de los mensajes que los administradores mandan a los usuarios, pues si uso Indy por un lado y RemoteDatamodules por otro pues tengo dos canales distintos. Por eso había pensado que usando el mismo canal de los mensajes podía mandar el texto de la consulta SQL al servidor (lo que llamé AppControl) y éste mandaría la consulta a la BD.
Muchas gracias
jachguate por tu atención y nos leemos pronto.
// Saludos