Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Conexión con bases de datos
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Conexión con bases de datos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 25-11-2003
Avatar de abel
abel abel is offline
Miembro
 
Registrado: sep 2003
Posts: 59
Poder: 21
abel Va por buen camino
Consejo sobre componentes a usar en conexión por internet

Hola:

No sé si este es el foro adecuado, lo que necesito es consejo para un proyecto que me han encomendado.

Tengo que hacer una gestión para una cadena de zapaterías, hay un almacén central donde se hacen compras y se da de alta la mercancía y luego hay varias tiendas repartidas por la ciudad y poblaciones cercanas que sólo venden. Se trata de que en las tiendas puedan vender en tiempo real conectadas todas a la central.

He pensado hacerlo en firebird, por la experiencia que tengo con él, pero a través de internet, en las pruebas que he realizado con Fibplus e IBO me ha resultado un poco lento.

¿Qué me aconsejáis?, ¿qué componentes usar?, ¿qué debo tener en cuenta?...

Muchas gracias y saludos a tod@s.
Responder Con Cita
  #2  
Antiguo 25-11-2003
Avatar de Voutarks
Voutarks Voutarks is offline
Miembro
 
Registrado: jul 2003
Ubicación: Islas Canarias
Posts: 118
Poder: 21
Voutarks Va por buen camino
Creo que había un hilo donde se hablaba precisamente de esto.

En primer lugar, ni que decir tiene que las conexiones tendrán que ser adsl en todos lados, aunque sea la normal de 256 kb y en la central si es adsl de 2 mb mucho mejor.

Yo he hecho conexiones así, utilizando Zebedee. Éste es un programita que comprime los datos y los envia entre las máquinas por el puerto que tu elijas. La ganancia en velocidad no es mucha, pero como tambien encripta los datos y el programita es gratuito...

¿Que si es lento? Hommmmmbreeeeee......., pues, que quieres que te diga, muy rápido rápido no es, sobre todo cuando estás acostumbrado a trabajar en la red local, donde firebird va cono un rayo endemoniado; te acostumbras a las consultas cuasi-instantáneas y luego si tardan 1,3 segundos te parece que tardan mucho.

Pero tambien te digo: es manejable si te lo curras. Quiero decir que depende de como sea el programa lo trabajas y puedes llegar a conseguir resultados más que aceptables.

Me explico: en primer lugar tienes que seguir las reglas básicas de cualquier programa cliente servidor, me refiero a que las búsquedas hay que acotarlas muy bien, obligando al usuario a que especifique concretamente qué es lo que quiere buscar y luego devolverle un conjunto de registros reducido de acuerdo con lo que quiere. Nada de dbgrid's con 15.000 registros.

En segundo lugar, te comento lo que yo hago, aparte de lo anterior. Utilizo componentes FIBPlus pero creo que con los mismo IBX se pueden conseguir los mismos resultados. Hay transacciones de lectura y escritura separadas (por lo menos una de cada lógicamente). Las de lectura tienen el parámetro read de manera que no pueden escribir ni por un fallo tuyo o de tu programa. Éstas las usan componentes dataset que están conectados a grids de búsquedas, que, como dije antes, devuelven resultados que el usuario ha especificado y delimitado muy bien previamente. Ese conjunto de datos luego se queda en local y el usuario puede ordenar por el campo que quiera y hacer agrupamientos en el grid SIN tener que volver a mandar o recibir nada desde el servidor hasta que se haga una nueva consulta. En estos grids sólo se muestran algunos campos significativos, aquellos que el usuario utiliza para buscar y diferenciar claramente un registro de otro, y está claro que sólo son de lectura. Los dataset están basados en vistas de la base de datos, aunque por aqui se ha dicho que si estuvieran basados en procedimientos almacenados sería mayor su rendimiento: yo no lo hago así porque el rendimiento de la vista me parece bueno, ya que en este caso de lo que depende la cuestión no es rendimiento del servidor al hacer las consultas sino del tráfico de la red

Sigo: cuando el usuario hace doble click sobre una fila del grid se abre otro formulario con una vista completa de todos los campos de ese registro. El usuario puede entonces modificar el registro o eliminarlo si tiene permiso para eso. Hay un botón para añadir nuevos registros que abre otro formulario heredado del anterior que sirve para eso. Todas estas operaciones de inserción, modificación y borrado los hago con un componente llamado fibquery, que se comporta igual que el ibsql de las ibx. Incluso para leer el registro completo antes de mostrarlo utilizo dicho componente; para rellenar los combobox también utilizo este componente. No hay controles enlazados a datos de ningún tipo sólo los grids de lectura comentados anteriormente. Todos los formularios se basan en controles normales, los cuales "relleno" con una consulta mediante fibquery (o ibsql o similares) y cierro la transacción. Después el usuario rellena los campos o hace las modificaciones pertinentes y compruebo los datos, construto la instrucción sql, abro transacción, envio instrucción (insert, update, delete) y cierro la transacción. Digo que compruebo los datos en el programa antes de enviar la instrucción y si alguno no cumple las normas se lo hago saber al usuario y cuando esté todo correcto es cuando envío la instrucción. La comprobación de los datos está incluida dentro de la base de datos pero yo también los compruebo antes de enviarlos, es mejor así que enviar datos inválidos por la red y mandar un evento de vuelta.

Luego, los fibplus pueden, en los datasets, actualizar sólo los registros modificados, no se si tambien lo hacen las ibx, y eso es lo que hago.

Quien hay leido esto puede pensar '¡Vaya ganas de complicarse la vida!' y tiene razón. Se que más o menos esto se puede conseguir con menos trabajo. Los mismos fibplus tienen métodos para conseguir esto mismo, pero el caso es que quería hacerlo yo de esta manera. Me gusta controlar en cada momento lo que está pasando, abrir y cerrar yo explícitamente cada transacción, mandar cada instrucción sql. ¡Lo confieso, en tozudez no hay quien me gane!.

Ahora bien, los programas funcionan a las mil maravillas en red local. Y en internet ya digo, van aceptablemente bien, se puede trabajar.

Para terminar quiero decir que hay otras opciones, como trabajar con datasnap y trabajar en local y luego de vez en cuando conectar con el servidor remoto, mandar las modificaciones y recoger nuevos datos, al estilo cajero de banco. Así tambien podría ir bastante bien, pero sobre esta opción te podrán hablar mejor otros compaleros del foro.
__________________
Emilio J. Curbelo
Responder Con Cita
  #3  
Antiguo 25-11-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Cita:
Voutarks comentó:
Para terminar quiero decir que hay otras opciones, como trabajar con datasnap y trabajar en local y luego de vez en cuando conectar con el servidor remoto, mandar las modificaciones y recoger nuevos datos, al estilo cajero de banco. Así tambien podría ir bastante bien, pero sobre esta opción te podrán hablar mejor otros compaleros del foro.
Bueno, nosotros trabajamos así y la verdad es que nos va de maravilla.
Como en todo, hay cosas a favor y en contra
A favor: velocidad, independencia de cliente y servidor, ....
En contra: puede fallar la comunicación y perder datos por lo que hay que hacer algun programa de chequeo de datos para controlar estas pérdidas y poder hacer de nuevo el envío del paquete perdido

Lo demás, te remito a la excelente explicación del amigo Voutarks ya que, aunque funcionen en local, todo el tema de filtrados mediante SQL es muy importante.

Tambien depende de como se monte. Puedes tener un servidor en cada tienda y que las cajas apunte a éste (que sería el único que se comunicara con el almacén) o bien, cada caja independiente y que cada una sea la encargada de hacer sus propias comunicaciones

Te recomendaría hacer pruebas de los tres métodos aquí expuestos y te decantaras por el que más te gustara
Responder Con Cita
  #4  
Antiguo 25-11-2003
Avatar de __hector
[__hector] __hector is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Santo Domingo, Rep. Dom.
Posts: 1.075
Poder: 22
__hector Va por buen camino
Unas cuantas preguntas...

- Por que tienen que estar conectadas al servidor central?
- Es con el fin de ir sacando de almacen los productos que se van vendiendo?
- Que los productos que venden no tienen que estar fisicamente en la sucursal, de tal forma que en realidad lo que tenemos son varios almacenes, uno local por cada tienda, con su "propio" inventario?
- Con que fin REAL es la actualizacion de datos al servidor central?
- Te prueba utilizar otra tecnologia, no necesariamente Firebird?
- Y la capacidad de las lineas?

Todo esto, para mas o menos hacerme una idea general del problema, porque segun veo trabajaria de forma muy eficiente utilizando replicacion en el motor de bd, pero quizas ni eso sea necesario
__________________
Héctor Geraldino
Software Engineer
Responder Con Cita
  #5  
Antiguo 26-11-2003
Avatar de abel
abel abel is offline
Miembro
 
Registrado: sep 2003
Posts: 59
Poder: 21
abel Va por buen camino
Hola:

Muchas gracias por vuestras respuestas.

El motivo de estar conectado a la central es para mantener el stock de artículos, vender con precios actualizados, conocer las ventas a cada instante, etc...

Efectivamente, cada tienda es tratada como un almacén, así se controla lo que vende y necesita cada una de ellas en tiempo real.

En cuanto al SGBD y componentes a usar... estoy abierto a cualquier sugerencia, teniendo en cuenta que lo que busco es que todo funcione lo más rápido posible, como sería en una red local.

Muchísimas gracias.

Saludos a tod@s.
Responder Con Cita
  #6  
Antiguo 26-11-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Cita:
abel comentó:
El motivo de estar conectado a la central es para mantener el stock de artículos, vender con precios actualizados, conocer las ventas a cada instante, etc...
La pregunta que debes hacerte sería.... ¿Es tan crítico el echo de que el stock, las ventas,.... se sepa al instante? ¿Realmente no puede haber un desfase de 10, 20, 30 min. según tu quieras hacer las comunicaciones?

Componentes.... si es para FB 1.5 yo estoy probando los FIBPlus y me estan gustando. Pero tienes alternativas como DBX y otros. Es cuestión de que hagas tus propias pruebas y tu mismo decidas.
Responder Con Cita
  #7  
Antiguo 26-11-2003
Avatar de abel
abel abel is offline
Miembro
 
Registrado: sep 2003
Posts: 59
Poder: 21
abel Va por buen camino
Hola:

El hecho de que sea todo en tiempo real es por exigencias de la empresa que me lo ha solicitado.

¿Cómo sería la alternativa que comentas de actualizar cada xx minutos?

Saludos.
Responder Con Cita
  #8  
Antiguo 26-11-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Bueno, de forma rápida.

Las comunicaciones se hacen de Tienda -> Almacén, es decir, la que establece la conexión es la tienda y el que espera la conexión (por lo que siempre ha de estar conectado) es el almacén.

Tendrías que crearte un programa de comunicaciones que se disparara cada X minutos.

Al dispararse tendrías que hacer:
1.- Mirar que datos has de enviar al almacén
2.- Comprimirlos (para ello yo utilizo las ZLib -> para una demo y componentes, mira en mi web)
3.- Realizar el envío por medio de FTP
4.- Marcar los datos como enviados (por un campo Flag en la BD o como quieras)
5.- Mirar si en el almacén hay datos para descarga
6.- Si los hay, descargarse los datos (que tambien irán comprimidos), descomprimirlos y actualizar BD

Lo de controlar los datos a enviar se puede hacer de muchas maneras. Nosotros, por ejemplo, tenemos triggers asociados a las tablas que tenemos que "subir" y que rellenan tablas temporales (dentro del FB). Luego, sólo tenemos que leer esas tablas creando un fichero XLM por tabla para despues comprimirlos. Lo del XML es porque, al ser fichero de texto, ocupa poco y el envío se hace más rápido.

Luego, para la descarga de información, el procedimiento es más o menos el mismo. Si, por ejemplo, se crea un artículo nuevo, se pone en una tabla temporal (tambien por triggers). Cada X minutos se lanza un proceso que crea los XML pertinentes, los comprime y los pone en la carpeta de la tienda correspondiente (una carpeta por tienda que será donde se conectarán ellas)

Bueno, esto es de forma algo por encima. Si te interesa el tema, se puede ampliar la explicación, pero almenos es para que veais la idea
Responder Con Cita
  #9  
Antiguo 27-11-2003
Avatar de __hector
[__hector] __hector is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Santo Domingo, Rep. Dom.
Posts: 1.075
Poder: 22
__hector Va por buen camino
Excelente solucion, aunque la veo un poquito elaborada.

Si te sirve, mirate el SQL Server y la configuracion de replicacion entre servidores, que te iria a la perfeccion (sobre todo la merge replication). No se sobre replicacion en Interbase/Firebird, pero con SQL Server no tienes que programar mucho, solo crear par de paquetes DTS que hagan la actualizacion al servidor, o utilizar el wizard para programar la replicacion entre cliente y servidor.

Asi no tienes que preocuparte porque el programa este encargandose del manejo de la data... sino que eso ocurrira desde el mismo RDBMS
__________________
Héctor Geraldino
Software Engineer
Responder Con Cita
  #10  
Antiguo 27-11-2003
Avatar de Voutarks
Voutarks Voutarks is offline
Miembro
 
Registrado: jul 2003
Ubicación: Islas Canarias
Posts: 118
Poder: 21
Voutarks Va por buen camino
¡Cadetill, tu solución es magnífica! Se ve que está bien trabajada y es rápida.

Lo cierto es que mi explicación era general, tanto vale para red local como para internet pero no arregla bien los problemas de lentitud entre sedes remotas, pero implementando además tu solución creo que sería la manera correcta de hacer las cosas.

Hay otras opciones hechas como el IbReplicator de IbPhoenix pero es caro. Por otro lado el proyecto open source denominado FiBRE destinado a ofrecer replicación sobre firbeid parece algo estancado. Éste proyecto también utiliza XML como formato de transporte de datos.

Estoy muy interesado en tu enfoque, seria estupendo que detallases más los pasos a sequir.
__________________
Emilio J. Curbelo
Responder Con Cita
  #11  
Antiguo 27-11-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Bueno, vamos a detallarlo un poco más, a ver si me sale

Tenemos por un lado el almacén central y por otro las tiendas
Con este método, no hace falta que los 2 estén con el mismo motor, ya que los programas de recogida y envío de datos, pueden hacer las transformaciones (de hecho, éste es mi caso, las tiendas están en FB y la central está en As400)

Estructura:
Central:
Programa -> recepciona colas (archivos de envío y/o recepción) de entrada y prepara colas de salida
Tenemos una carpeta por tienda y, dentro de cada una 2 carpetas, In y Out. En la carpeta In, la tienda dipositará las colas de entrada (tiquets, cierres de caja,....) y de la carpeta Out recogerá las colas de salida (Artículos nuevos, cambios de precio,.....)

Tiendas:
Programa -> recoge las colas de bajada actualizando las tablas y envía los datos de ventas, cierres de caja,....
Tenemos una carpeta para guardar las colas de entrada (In) y otra donde se prepara la cola de envío (out)

Recordemos que los ficheros XML generados, serán comprimidos en un sólo archivo (en mi caso con las ZLib poniendole extensión ZLB)

Bien, dicho esto general, vamos a detallar.

Triggers:
Las tablas que queremos que "bajen/suban" de/a las tiendas, tienen triggers asociados que actualizan unas tablas temporales. Ejemplo: la tabla de artículos tiene un trigger asociado en el Insert, Update y Delete. Al dispararse el trigger (como sabemos la operación que se está realizando -> Insert, Update, Delete), creamos un registro nuevo en la tabla temporal con el código del artículo y todos sus datos MAS un campo que nos indicará la acción a realizar (1=Insert, 2=Update, 3=Delete). ¿Por qué se graban todos los datos? Más que nada es por eso de más vale prevenir que curar y de paso porque de esta manera, no se necesitan hacer joins para generar los XML y el proceso es más rápido.

Programa Central:
Tiene 2 Timers, uno para recepciones y otro para envíos. Para nosotros, lo más crítico son las recepciones, por lo que tenemos un timer vajo (15min). Los envíos de datos nuevos, no son tan críticos, por lo que tenemos un timer más alto (1h). Por supuesto, estos timers son configurables y se puede "forzar" un envío/recepción de datos.
¿Qué hace el programa? Bien, como queremos que sea lo más configurable posible, tenemos una tabla donde indicamos los SQL ha lanzar, es decir, las tablas a "bajar" a las tiendas. Un ejemplo de registro de esta tabla sería:

select campo1, campo2,..., campoN from tabla where condiciones

De esta manera, si en algún momento necesitamos añadir una tabla nueva a la tienda, sólo hay que añadir un registro a esta tabla y listos!!! No hay que modificar el programa nada en el programa.
Bien, una vez lanzado el SQL sobre esta tabla, lo que hacemos es generar un XML con la estructura y los datos de cada un de los resultados de lanzar los SQL contenidos en la tabla (no voy a entrar en temas de programación, sólo la teoría). Estos XML los ponemos en un directorio y, luego, sólo hay que recorrer todos los ficheros de ese directorio para hacer la compresión (recomiendo la librería ZLib ya que comprime más que el WinZip y, al no ser un compresor estándar, quizás es más seguro ya que los datos se mueven por internet). También seria posible utilizar un pgp para encriptar si se quiere hacer aún más seguro el envío de datos ya que hay una versión que funciona en linea de comandos.
El archivo resultante de la compresión, es el que se copiará en las distintas carpetas Out de cada tienda y, se borrarán los datos de las tablas temporales. Esto del borrado puede hacerse de muchas formas, pero nosotros lo hacemos de la siguente manera. Lanzamos el SQL pertinente y, mediante un bucle while not Query.Eof vamos generando el XML y, 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 )
Esto por lo que hace al envío de información.
Respecto a la recepción, es bastante más sencillo. Se tendría que recorrer los diferentes subdirectorios In de los directorios de las tiendas. Leer todos los ficheros, descomprimir, abrir los XML (con un TClientDataSet) y actualizar la tabla pertinente (también teniendo en cuenta el Insert, Delete o Update de la manera anteriormente mencionada). Nosotros, por cuestiones de seguridad (y de no compatibilidad al 100% de las tablas de FB y As400) tenemos tablas intermedias.

Programa Tiendas:
Cada X minutos (configurable, of course), generará los ficheros XML pertinentes (al estilo de lo que realiza el proceso de la Central, no creo que sea necesario repetirlo ), se conectará por FTP al ordenador de la Central y, en su directorio In pondrá el ZLB generado y, de su directorio Out se descargará las colas que tenga pendientes, las que serán descomprimidas y actualizará las tablas pertienentes de cada XML

Estos procesos de envío/recepción pueden ser servicios de Windows para no tener una pantallita allí abierta continuamente.

Recomiendo los commits después de cada proceso de una tabla y el cierre de la conexión a la BD despues de terminar (hemos tenido algún que otro conflictillo).

Bueno, creo que no me dejo nada.

PD: se aceptan sugerencias
Responder Con Cita
  #12  
Antiguo 28-11-2003
Avatar de abel
abel abel is offline
Miembro
 
Registrado: sep 2003
Posts: 59
Poder: 21
abel Va por buen camino
Hola:

Muchas gracias a tod@s, ya tengo varias ideas para hacer pruebas antes de decidirme por una en concreto.

Muy amplias y claras las explicaciones que habéis relatado, me serán de gran ayuda.

Muchas gracias y saludos.
Responder Con Cita
  #13  
Antiguo 28-11-2003
Avatar de Voutarks
Voutarks Voutarks is offline
Miembro
 
Registrado: jul 2003
Ubicación: Islas Canarias
Posts: 118
Poder: 21
Voutarks Va por buen camino
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.
__________________
Emilio J. Curbelo
Responder Con Cita
  #14  
Antiguo 28-11-2003
__cadetill __cadetill is offline
Miembro
 
Registrado: may 2003
Posts: 3.387
Poder: 24
__cadetill Va por buen camino
Cita:
Voutarks comentó:
El método me parece muy bueno. Podrías hasta llegar a hacer un programa sobre replicacion de Ib/firebird.
La replicación entre las distitas cajas de una tienda, la hacemos directa de BD a BD ya que es por red

Cita:
Voutarks comentó:
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.
Es que yo me refería en un sólo sentido, en el envío. Imagínate que estás enviando los articulos que hay en la tabla temporal ArtiTMP. Si durante el envío entra un artículo nuevo para enviar, éste se perdería (no se si me he explicado mejor)

Cita:
Voutarks comentó:
Creo que en este caso que pongo sí que tendrían que estar conectadas permanentemente y en tiempo real con la central.
Bueno, siempre se podría hacer una cosa intermedia. Las tablas "críticas" tenerlas por conexión directa y, las otras, por comunicación. Eso sí, para esas tablas "críticas" hacer consultas que retornasen un mínimo de registros. De hecho, nosotros tenemos alguna tabla así, pero asumimos el riesgo (la pérdida es menor que el veneficio que representaría montar algo mixto). No obstante, por lo que he visto en una agencia de viaje (en la que trabaja mi cuñá ) lo hacen vía web (con php y mySQL por ejemplo).
No se que programa es el Amadeus ese, pero si es un programa cómo lo conocemos nosotros (exe en el cliente atacando a una BD en un servidor remoto), la verdad es que sí sería interesante saber cómo funciona
Responder Con Cita
  #15  
Antiguo 28-11-2003
Avatar de guillotmarc
guillotmarc guillotmarc is offline
Miembro
 
Registrado: may 2003
Ubicación: Huelva
Posts: 2.638
Poder: 23
guillotmarc Va por buen camino
Hola.

En una aplicación también he montado un sistema de replicación como el que comenta Cadetill. Es muy rápido y funciona bien. Basicamente siguo (al igual que el Fibre) esta metodología http://www.ibphoenix.com/main.nfs?a=...ibp_howto10%27

Aunque en lugar de utilizar un programa que lee de una base de datos y actualiza en la otra, utilizo el método comentado por Cadetill de guardar los datos en archivos .xml (generados por clientdatasets), empaquetarlos en un comprimido, y enviarlos por FTP. En el destino solo hay que volverlos a leer, cargándolos en clientdatasets, y actualizar la base de datos destino.

Tienes que tener en cuenta unas pocas cosas. Por ejemplo que a veces los paquetes tienen tendencia a liarse. Por eso es mejor que los numeres, y antes de procesar uno, verifica que no tienes ningún paquete anterior pendiente de procesar. (Es decir, si vas a procesar el paquete 114, verifica que el ultimo procesado haya sido el 113, en caso contrario hay paquetes que no han llegado al servidor FTP, por lo que es mejor detener la replicación y esperar a ver si lleguan en la proxima sincronización, o avisar al Administrador).

A veces se generan conflictos. Por ejemplo en las tiendas A y B se vende el mismo producto al mismo tiempo. Supongamos que había 20 en Stock, en cada base de datos, en el momento de hacer la venta, pondremos el Stock a 19. Cuando se realize la sincronización, la modificación en el registro de A se pasará a B, y viceversa, con lo que igualmente quedarán las dos con Stock a 19. Aunque lo correcto es que estuviese a 18. Tienes que montar algo para evitar estos problemas (yo por ejemplo, no replico el campo Stock, sino que lo calculo cada vez que se replica un registro de esa tabla, sumando compras y ventas)

NOTA : Una tecnología que también puedes utilizar, en lugar de utilizar replicación, es haciendo una aplicación de 3 capas con un servidor de aplicación. Es decir, utilizar Datasnap (módulos de datos remotos).

Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
Responder Con Cita
  #16  
Antiguo 28-11-2003
Avatar de Voutarks
Voutarks Voutarks is offline
Miembro
 
Registrado: jul 2003
Ubicación: Islas Canarias
Posts: 118
Poder: 21
Voutarks Va por buen camino
Cierto, no habia entendido bien ese punto, ahora está claro. Tienes razón en lo que comentas.

Lo que comentas del vía web es otra buena y moderna opción, pero la verdad es que yo personalmente no le doy a ese tema, y mira que me lo he propuesto.

Puesde que te de un toque algo más adelante. De nuevo gracias por tu tiempo.
__________________
Emilio J. Curbelo
Responder Con Cita
  #17  
Antiguo 28-11-2003
Avatar de Onti
Onti Onti is offline
Miembro
 
Registrado: jul 2003
Ubicación: La Paz - Bolivia
Posts: 500
Poder: 21
Onti Va por buen camino
Una consulta:

Estuve viendo sus repuestas, porque yo tambien tengo que montar algo similar.
Como hago para que el sistema pueda enviar por ftp los archivos comprmidos?

Salu2 y gracias
Responder Con Cita
  #18  
Antiguo 28-11-2003
Avatar de guillotmarc
guillotmarc guillotmarc is offline
Miembro
 
Registrado: may 2003
Ubicación: Huelva
Posts: 2.638
Poder: 23
guillotmarc Va por buen camino
Hola, tienes componentes como los Indy. (Vienen en el mismo Delphi a partir de Delphi 6, aunque los de Delphi 6 són muy antiguos y se recomienda actualizarlos).

http://www.nevrona.com/Indy/

Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
Responder Con Cita
  #19  
Antiguo 26-06-2004
FlacoNet FlacoNet is offline
Miembro
 
Registrado: jun 2003
Posts: 38
Poder: 0
FlacoNet Va por buen camino
Pero sobre tecnologias que...

hola a todos , estoy hace un tiempo averiguando sobre tecnologias y formas de conexion para hacer un sistema de las mismas caracteristicas que se presentaron en este hilo.
Despues de leerlos y hacer algunas pruebas se me generaron las siguientes incognitas.
Veo que hay dos enormes posibilidades..una es la de usar algun lengauje de script tipo php o asp (que la verdad no me interesa para este proyecto) o la otra es haciendo uso de ventanas visuales al metodo guindow.
Estoy volcado a buscar lo mejor en cuanto a velocidad. Cada tienda usaria un motor de base de datos local, despues se actualizaria con dialup al almacen central con otro motor de base de datos.
Pero lo que yo veo es que se dicutieron formas de trabajo y no que tipos de tecnologias utilizar ya sea IBX, DBX , proveedores, DATASNAP, ect...
Mi pregunta es la siguiente:
El uso de alguna de estas tecnologias hace mas rapida la conexion remota a la base de datos por internet? y que tal el uso de datasnap para aplicaciones de 3 capas??

Les agradezco la respuesta...
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 21:10:42.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi