Comunicación en PCs y acceso a BD

[roman]

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.

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

[jachguate]

Empezado por roman

acerca de RemoteDatamodules, ClientDataSets y Providers

Por alli van los tiros..

Empezado por roman

me falta para ver cómo un cliente le dice al servidor cositas como "muéstrame en mi ClientDataSet la lista de usuarios"

En realidad, vas a tener un client dataset por cada Query o tabla de tu RemoteDataModule, asi que estos estaran "especializados" de entrada.

Empezado por roman

. me falta ver cómo podría hacer consultas más complicadas.

. Esto es en la capa intermedia... podes meter cualquier sentencia SQL en un TQuery, conectarla a un provider, e "invocarla" desde el cliente...

Empezado por roman

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.

No he trabajado de esta manera con las INDY, pero si ya lo encontraste... pos ya'sta, no??

Empezado por roman

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.

Eso es cierto... pero en mi humilde opinión, creo que ese costo es justo... habrá que ver.

Empezado por roman

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.

Esto depende de la complejidad de las consultas, y de la cantidad de datos que viajarian. Por este otro lado, un cliente, incluso no tendria que mandar toda una consulta SQL al servidor... sino un comando (con los parámetros adecuados) para que el servidor ejecute una consulta ya conocida por este.

En fin... solo son ideas, creo que funcionaría de ambas formas, siempre dependiendo de los detalles de tu aplicación...

Hasta luego.

[roman]

Hola jachguate

He estado no diré que estudiando sino leyendo algunas cosas y vagando por aquí y por allá. Veo que lo de los RemoteDataModules es más sencillo (igual me equivoco pero de entrada así parece) de lo que pensaba. O mejor dicho, que Borland colocó todo para que fuera prácticamente igual que en una aplicación de una sola capa.

De alguna manera veo que son dos opciones las que se ajustarían a lo que quiero: DCOM y Sockets. En varios lados mencionan la dificultad de configurar DCOM aunque como todavía no lo he probado más que en local pues no sé a qué se refiera dicha complejidad y por otro lado pareciera que los sockets darían más flexibilidad en cuanto al tipo de clientes que podrían acceder en un futuro. Pero veo que el problema con los sockets es que, tal como se maneja con los RemoteDataModules, la capa intermedia maneja un único cliente a través de ScktSrvr.exe que administra todos los accesos.

Poco después de mi mensaje anterior me di cuenta que la pregunta de las consultas SQL "especializadas" era un poco tonta, esto es, si puedo colocar un TTable (como en el demo de Delphi) seguro puedo colocar cualquier DataSet en la capa intermedia y esto incluye claro cualquier tipo de Query. Pero entonces me viene otra duda: muchas veces nos encontramos aquí sugieriendo construir consultas "al vuelo", ¿cómo se haría esto aquí?

Esto de los dos canales (DCOM e Idy o ScktSrvr.exe e Indy) entiendo lo que dices, quizá sea un justo precio pero pienso: si hago una comunicación por sockets ¿para que establecer otra igualmente por sockets?

Buscándole vi gente que propone usar una capa intermedia mediante Indy y ADO olvidándose de DCOM y ClientDataSets. No lo he visto en detalle pero quien lo propone parece ser muy convincente en cuanto a sus posibilidades o por lo menos contestó puntualmente a casi todos los peros que le ponían. Viendo esto me acordé entonces del demo que viene con las Indy (TCPDataSet) en donde usan componentes Indy junto con un dataset en memoria, el TKBMMemTable, que parece que tiene un buen manejo de envio y recepción de cursores mediante una binarización de los datos. A fin de cuentas, esto es lo que hace DCOM ¿no? empaquetar los datos de alguna forma para que sea fácil transportarlos. Si esta opción fuera viable me permitiría usar el mismo canal de comunicación para el envío de consultas así como de otro tipo de información.

Bueno, sé que por ahora sólo divago pero realmente nunca he trabajado así y apenas empiezo a picarle aquí y allá.

Una pregunta sí hago sin embargo:

En la capa intermedia, de cualquier forma que se haga habrá, a fin de cuentas varios accesos simultáneos y supongo que de alguna manera hay que controlar las concurrencias. Si uso DCOM o ScktSrvr.exe este manejo ¿ya está dado? O tengo que preocuparme de hilos y demás yerbas. Si uso Indy no sé porque pienso que sería más sencillo en cuanto a que Indy ya maneja un hilo por cada cliente.

Bueno, no espero que contestes ya que realmente no estoy diciendo ni casi preguntando nada pero seguiré curioseando.

// Saludos

[Toni]

Hola amigos,

Solo comentar unas cosillas:

Si utilizas remote data modules bien sea con DCOM o con sockets no tienes que preocuparte de las conexiones en la capa intermendia, pues las gestiona automaticamente. Ahora bien los problemas con la concurrencia si que tienes que gestionarla tu desde el cliente.

Utilizando ClientDataSets puedes manejar un conjunto de datos remoto de forma local hasta que realizas un ApplyUpdates(); y envias los cambios al servidor, si en ese momento hubiese algun problema de concurrencia lo podrias tratar en el evento OnReconcileError del mismo.

Otra cosa, tambien puedes utilizar sin problemas varias conexiones por sockets por diferentes puertos para cada uso. Uno para el acceso a los datasets y otro para los mensajes a los usuarios.

Saludos,

[roman]

Hombre, muchas gracias por tus comentarios Toni.

Más o menos me quedan claros los conceptos pero esto

Empezado por Toni

Ahora bien los problemas con la concurrencia si que tienes que gestionarla tu desde el cliente.

no lo entiendo. ¿No tendrían que manejarse desde el servidor?

// Saludos

[jachguate]

Empezado por roman

¿No tendrían que manejarse desde el servidor?

Desde el servidor de aplicaciones... que a su vez es el cliente de la base de datos...

Hasta luego.

[Toni]

Todo esto es en terminos generales, depende de la acción a realizar.

De todas formas me venia a referir que tu desde el cliente (interfaz de usuario) en determinados casos tendras que decidir si quieres realizar una operación que modifique un unico registro o varios y si envias los cambios uno a uno o en conjunto al servidor de aplicaciones.

Y en el momento del envio (ApplyUpdates) desde el propio cliente tienes que decir en cada caso si ocurre un error de integridad o concurrencia que acción realizas.

Todo es muy relativo según como enfoques tu aplicación, claro esta.

Saludos,