Muchas gracias Cadetill por tu explicación, la vi ayer pero no tuve tiempo hasta hoy de leerla con detenimiento.
El método me parece muy bueno. Podrías hasta llegar a hacer un programa sobre replicacion de Ib/firebird. En tres semanas o así es posible que yo empiece a probar algo así.
Cita:
|
por cada registro generado (satisfactóriamente), lanzamos un SQL de Delelte. ¿Por qué esto? Imaginemos que estamos generando el XML de los artículos nuevos. Lanzamos el SQL sobre ArtiTMP y generamos el SQL. Mientras se ejecuta el proceso de generación, pueden haber nuevas inserciones en el maestros de Artículos, por lo que se generaría un registro nuevo en ArtiTMP. Si borramos con un delete general después del proceso... ese artículo se perdería. (no obstante, con este método algo más seguro.. también hemos tenido algún que otro problemilla de falta de algún código en las tiendas )
|
Quizá sea una tontería lo que digo pero, ¿no sería posible solucionar esto en la base detos mediante dos tablas temporales por cada tabla real, una para los envios y otra para las recepciones? De esta manera tendrías un ArtiEnvTMP y un ArtiRecTMP para el ejemplo que das.
Al leer tu descripción me he preguntado cómo sería un sistema en el cual los datos fuesen sensibles a todos los puntos del mismo. Quiero decir que en tu caso y en el de abel la información que se va modificando en una de las tiendas afecta a inmediatas y futuras operaciones de esa tienda, como la modificación de su stock, etc. Cuando se manda el cierre y otros datos tampoco afecta el de uno con el de las otras. Pero, ¿y si la modificación de algo en una de las tiendas afectara en lo que pueden hacer o no las otras?
Creo que en este caso que pongo sí que tendrían que estar conectadas permanentemente y en tiempo real con la central. Un ejemplo de esto sería el programa AMADEUS utilizado desde hace muchos años por las agencias de viajes para reservas de plazas en tiempo real. Me gustaría que alguien me pudiese explicar cómo está hecho exactamente.
28-11-2003
Modo Hilado