FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Hola Maniche.
Hoy matizaría un montón de cosas de aquellos mensajes míos, pero en esencia fue y sigue siendo posible hacer que varios conjuntos de datos clientes conserven su "bitácora de cambios", aun después de aplicar éstos al servidor de forma exitosa (lo normal o "nativo" es que una vez aplicados se borre esa bitácora). Lo que le planteaba a juniorSoft (a quien le mando un saludo) funciona con DataSnap, pues TClientDataSet, MIDAS, forma parte de DataSnap (si bien el puro componente TClientDataSet sirve para más cosas). Pero en esto de las bases de datos hay cierta buena práctica que se valora con el tiempo y a la cual uno debe intentar orientarse (aunque a veces cuesta trabajo o no gusta): Que el inicio y el cierre de una transacción de base de datos no dependan de diferentes órdenes o envíos de la aplicación cliente, sino que una sola orden del cliente sea el desencadenante tanto para abrir la transacción, como para grabar los cambios y cerrar la transacción. Esto es una de las diversas razones para tener una "capa intermedia", un programa normalmente sin interfaz de usuario llamado servidor de aplicaciones que, instalado en una computadora respetable y poco propenso a mal funcionamiento, sirve de apoyo al motor de bases de datos, programa al que sí le damos el derecho de abrir y cerrar transacciones abiertamente. DataSnap facilita enviar "todo en un paquete", para que se cumpla el que sea una sola orden del lado cliente la desencadenante de toda la transacción, esto cuando se usan conjuntos de datos "anidados" (nested data sets), pero hay que subrayar que ese esquema está pensado para los casos donde todos los conjuntos de datos de la transacción están organizados en un árbol de relaciones maestro-detalle (a no ser que se quiera abrir y cerrar la transacción explícitamente desde el cliente). Mi necesidad de que pudiera aplicarse un esquema "transaccional" a varios conjuntos de datos que no necesariamente estuviesen relacionados entre sí, fue lo que me llevó a estudiar y redefinir los métodos de TClientDataSet que menciono en los mensajes anteriores del hilo. Pero si bien soluciona esa necesidad de manejar cambios de tablas diversas en una sola transacción, pierde una pieza importante: que el servidor de aplicaciones evite abrir la transacción (y por tanto no empiece a guardar datos) antes de que el lado cliente termine de enviarle todos los cambios de todas las tablas involucradas. Cómo recuperar esa pieza que se pierde por no usar conjuntos de datos anidados es algo que me interesa estudiar, y creo que todas las ideas que se tengan son bienvenidas (se me ocurren cosas como usar el OwnerData de un único ApplyUpdates, o dotar a los TDataSetProvider con la capacidad de "retener" los cambios) . Por lo pronto, Maniche, si fueras tan amable de exponer con detalle y claridad tu interés en el tema para ver qué solución podría ser la más adecuada... Saludos. P.D. canelita, perdona por no responder en su momento. TClientDataSet tiene bastantes cosas sobre las que se puede profundizar. Aquí en el foro hay varios hilos que tratan sobre esa clase y no se diga la cantidad de páginas Web que explican algunos de sus más útiles aspectos. Si lees esto nos dirás si todavía buscas documentación o en el mejor de los casos nos compartirás algunos enlaces hacia lo que hayas encontrado. |
#22
|
||||
|
||||
Hola, por error he borrado el mensaje de Maniche, que es a quien ha contestado Al González
A ver si se puede rescatar... Disculpas. Saludos. |
#23
|
||||
|
||||
Para quien le interese, aquí hay un estupendo tutorial de TClientDataSet.
|
#24
|
||||
|
||||
No pasa nada, Casi, somos humanos.
Los domingos no es uno de los tres días de la semana en que reviso mi buzón de correo electrónico, pero hoy hice una excepción para recuperar de ahí la notificación de Club Delphi que me llegó con el mensaje borrado del usuario Maniche. Lo pongo íntegro: Cita:
Saludos y a dormir tranquilo esta noche. |
#25
|
||||
|
||||
#26
|
||||
|
||||
Hola Amigos de ClubDelphi, Gracias Al GonzaleZ por responder a mi pregunta, Disculpas por no responder antes estuve con un refriado muy fuerte.
Bueno he preparado un ejemplo que voy a adjuntar para todos los interesados. Ya que todos pueden dar sus aportes para llegar a la solución del problema mencionado. Decirles también que lo que estoy compartiendo está funcionando con ADO Components, DCOM y MIDAS. La idea es que funcione con DATASNAP. Explico el ejemplo que estoy compartiendo: La idea es hacer en DataSnap una forma de hacer actualizaciones de multiples Datasets hacia el servidor con una sola llamada y todo esto sea controlado en una sola transacción. Para evitar que por cada Dataset se haga un APPLYUPDATE. Que esto significa varias llamadas ya sea por Insertar y/o actualizar un registro en el servidor de base datos. Claro también para decirles que la idea es trabajar con atributos de tipo IDENTITY y con FK. Detallo lo que les comparto: Servidor: Se ha creado una conexión a una tabla users que también comparto el script. Dentro del servidor se ha creado un método llamado "UpdateDeltas" que este recibe los nombres de los Providers y Deltas a Actualizar. Si revisan el código ahí verán que todo eso se envía en un arreglo de Variants. Según las pruebas que he realizado con el ejemplo en la parte del servidor no hay problemas. (Eso Creo...) Cliente: Para invocar al método definido en el servidor "UpdateDeltas" se pueden hacer de 2 maneras: 1. Usando el componente TSQLServerMethod que configurando la clase del servidor datasnap se tiene el componente listo para invocar al método. OJO: Yo he configurado el componente pero no me está funcionando ya que si ven el código desde el cliente se envían 2 parámetros OLEVARIANT y el componente al momento de configurar los parámetros del método los pone como VARIANTs y ahí me sale errores que no soporta los parámetros. SI ALGUIEN CAPAZ PUEDE VER QUE PUEDE ESTAR PASANDO... no creo que los de embarcadero no hayan considerado los parámetros OLEVARIANTS para los métodos en DATASNAP. 2. Obteniendo las Clases al Servidor (El algunos foros lo conocen como las clases Proxis) y en este caso si me está permitiendo invocar el método definido en el servidor y poder ejecutarlo con los parámetros OLEVARIANTS. Cosa rara porque se supone que es lo mismo. Ahí espero sus comentarios. Continuando después de definido la llamado al método del servidor se ha definido un procedimiento llamado: ApplyUpdates que ahí lo que está haciendo es preparar la lista de Deltas y Providers los cuales van a ser enviados al Servidor por el método definido en los puntos 1 ó 2. Espero haya podido ser un poco claro en la explicación, por ello mejor les he enviado el ejemplo para que se les haga más fácil entenderme. El ejemplo que les comparto todo esta funcionando con la excepción de un procedimiento ReconcileDeltas que lo que hace es de todos los Deltas actualizados en el servidor actualizarlos en los ClientDataSets correspondientes. Aquí me está saliendo el problema y me muestra un error: “Mismatch in datapacket." Amigos espero no haberlos confundido, sigo investigando cual puede ser la causa de los 2 problemas que se me han presentado tanto en usar el componente TSQLServerMethod con parámetros OLEVARIANTS y al momento de hacer RECONCILE de los Deltas actualizados en la Base Datos. Capaz ya a alguien les haya pasado algo similar y de verdad resolver lo que he publicado nos va ayudar bastante a minimizar las llamadas al servidor. Muchas gracias y Saludos. Maniche |
#27
|
||||
|
||||
Amigos me confirman si han podido ver el Archivo Adjunto, Lo hice al momento de responder pero no lo veo. Ojala Uds. Si.
Si no pudieron ver. Como puedo subirlo al foro? al tema? Gracias. |
#28
|
||||
|
||||
Hola, ¿a qué archvo adjunto te refieres?, ¿de qué tipo es?, ¿cuánto ocupa?
|
#29
|
||||
|
||||
Lo que pasa casimiro que al momento de responder al Tema he creado un ejemplo y lo he adjuntado a la respuesta. Me refería a ese archivo si Uds. del foro los pueden ver.
La verdad que no domino mucho las opciones de este foro por ello que opte por preguntar. Espero me comprendas ahora. |
#30
|
||||
|
||||
Cuando estás creando un mensaje cualquiera, por ejemplo si contestas este mismo, verás un poco más abajo la opción de "adjuntar archivo", puede ser un zip, rar, etc. aunque el tamaño es pequeño.
Por eso te pregunto ¿qué tipo de archivo es y qué tamaño tiene? Además que me parece recordar que si tienes menos de 10 mensajes todavía no podrás adjuntar nada. En todo caso puedes enviarlo a, por ejemplo, mi correo y ya lo enlazo yo mismo. Mi correo... pinchando en el nombre de mi nick, 'Casimiro Notevi', se abrirá un menú y ahí tienes la opción. |
#31
|
||||
|
||||
El Archivo es pequeño y capaz es por lo que mencionas que no tengo los mensajes suficientes para poder adjuntar archivos.
Lo he publicado en : https://rapidshare.com/files/3523146110/DSXE3.zip; Espero todos puedan tener acceso a poder bajarlo. Me confirman para ver otra forma de hacerlo. Muchas Gracias por su apoyo. |
#32
|
||||
|
||||
Sí, se puede descargar, por cierto, ¿qué es?, ¿algún ejemplo?
pd: en teoría tampoco puedes poner enlaces si tienes menos de 10 mensajes |
#33
|
||||
|
||||
Cierto amigo Casimiro es un ejemplo de lo que estaba explicando anteriormente en mis respuestas.
Que bueno que puedan ver el ejemplo anterior así va a permitir que todos aportemos a la solución y nos ayude. De seguro nos va ayudar a todos. Saludos. |
#34
|
||||
|
||||
Cita:
Link Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
cache con idhttp | mak8888 | Internet | 0 | 10-09-2007 12:38:44 |
tamaño de cache de bd | omarbrdz | Firebird e Interbase | 3 | 14-09-2005 15:26:39 |
IBDataset actualizacion en caché | Osorio | Conexión con bases de datos | 0 | 07-07-2005 19:06:07 |
Problemas con la cache usando IBX | glopez | Firebird e Interbase | 5 | 01-09-2004 17:07:52 |
Transacciones y/o cache | kayetano | MySQL | 1 | 25-06-2003 20:30:46 |
|