VISUAL FOXPRO 9 CON Firebird 2.5
1,363 views
Skip to first unread message
Adolfo Leon Quintero Hoyos
Jul 5, 2011, 9:03:31 PM7/5/11
to publice...@googlegroups.com
Buenas noches compañeros, necesito buen ejemplo de formulario con adiciona, modifica, elimina, consulta, imprime conectado a la base de datos Firebird
Gracias
Adolfo
Walter R. Ojeda Valiente
Jul 5, 2011, 9:09:34 PM7/5/11
to publice...@googlegroups.com
Puedes descargar SQL_DEMO, allí tienes los códigos fuentes y la explicación de una aplicación completa que usa Firebird.
http://www.mediafire.com/?dugbqkqt4tx6bdl
Saludos.
Walter.
Date: Tue, 5 Jul 2011 20:03:31 -0500
Subject: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: todoso...@gmail.com
To: publice...@googlegroups.com
http://www.mediafire.com/?dugbqkqt4tx6bdl
Saludos.
Walter.
Date: Tue, 5 Jul 2011 20:03:31 -0500
Subject: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: todoso...@gmail.com
To: publice...@googlegroups.com
Adolfo Leon Quintero Hoyos
Jul 5, 2011, 9:43:28 PM7/5/11
to publice...@googlegroups.com
Gracias Walter, me parece excelente voy a buscar mas para saber que tengo que tener en cuenta
Saludos
Adolfo
Antonio Samper
Jul 6, 2011, 1:34:25 PM7/6/11
to publice...@googlegroups.com
Walter he estado analizando y tratando de aprender de tu excelente trabajo, quiero desarrollar un aplic con un motor sql y queria preguntarte que vventajas o desventajas se tienen a la hora programar de esta manera, ya que en el caso de los proc almacenados unicamente se tienen para actualizar las tablas del servidor, los procedimientos ya mas complejos deberia tenerlos siempre en un prg y no en un proc almacenados?, siendo asi no estaria perdiendo las bondades que me ofrece el servidor ? o estando en un prg se ejecutan con la misma velocidad que estando almacenados en la bd?.
Saludos,
Tony
Carlos Miguel FARIAS
Jul 6, 2011, 5:15:50 PM7/6/11
to publice...@googlegroups.com
Ya que la pregunta pasa por el foro, tratare de dar mi opinion, mas alla de que la consulta esta dirijida a Walter.
Entiendo de que un esquema de bd con cliente servidor, lo mas honeroso para los sistemas es la transferencia de datos a traves de la red, y luego la carga de proceso para los servidores.
Entonces, cualquier proceso que permita reducir el trafico de red es mas importante de quien lleva a cabo la elaboración de datos.
Si al hacer una consulta, los datos pueden ser formateados y pasados a un tipo de datos que ocupe menos bytes, es preferible hacerlo en el servidor, caso contrario, es mejor formatear en el cliente, ya que si no logro en el proceso reducir el trafico de red, mejor distribuyo la carga de procesamiento en los clientes, para no afectar la carga en el servidor.
Si tengo que hacer calculos que directamente afectan a datos en la misma bd. Evidentemente, hacerlos en el servidor, evita que los datos circulen por la red.
Hay que tener en cuenta tambien, que no el lenguaje de los procedimientos almacenados puede no ser tan potente para calculos como el vfp (o lo mas común, no tan conocido por el programador), en esos casos, indefectiblemente los procesos de datos deberan hacerse en el cliente.
Otro problema que le observo a los SP (stored procedure o procedmientos almacenados) es que si quiero hacer una aplicación independiente del SGBD (o incluos poder trabajar con bd nativas) poner codigo en dichos SP, implicara al desarrollador, tener preparados los codigos para cada SGBD (que normalmente, no son compatibles).
Saludos: Miguel
Entiendo de que un esquema de bd con cliente servidor, lo mas honeroso para los sistemas es la transferencia de datos a traves de la red, y luego la carga de proceso para los servidores.
Entonces, cualquier proceso que permita reducir el trafico de red es mas importante de quien lleva a cabo la elaboración de datos.
Si al hacer una consulta, los datos pueden ser formateados y pasados a un tipo de datos que ocupe menos bytes, es preferible hacerlo en el servidor, caso contrario, es mejor formatear en el cliente, ya que si no logro en el proceso reducir el trafico de red, mejor distribuyo la carga de procesamiento en los clientes, para no afectar la carga en el servidor.
Si tengo que hacer calculos que directamente afectan a datos en la misma bd. Evidentemente, hacerlos en el servidor, evita que los datos circulen por la red.
Hay que tener en cuenta tambien, que no el lenguaje de los procedimientos almacenados puede no ser tan potente para calculos como el vfp (o lo mas común, no tan conocido por el programador), en esos casos, indefectiblemente los procesos de datos deberan hacerse en el cliente.
Otro problema que le observo a los SP (stored procedure o procedmientos almacenados) es que si quiero hacer una aplicación independiente del SGBD (o incluos poder trabajar con bd nativas) poner codigo en dichos SP, implicara al desarrollador, tener preparados los codigos para cada SGBD (que normalmente, no son compatibles).
Saludos: Miguel
Walter R. Ojeda Valiente
Jul 6, 2011, 9:46:51 PM7/6/11
to publice...@googlegroups.com
Hola Antonio
Si vas a usar Bases de Datos SQL entonces te conviene que TODOS LOS PROCEDIMIENTOS que leen o escriben en las tablas se encuentren dentro de ellas, o sea como procedimientos almacenados.
Dentro de tus .PRG, formularios y clases, NO DEBERÍAS TENER funciones o procedimientos que lean o escriban datos en las tablas.
Esa es la forma correcta de trabajar con Cliente/Servidor, debes seguir con la filosofía: "todo lo que puede hacerse dentro de la Base de Datos debe hacerse dentro de la Base de Datos"
Y también: "por la red debe viajar la menor cantidad posible de datos"
Saludos.
Walter.
Date: Wed, 6 Jul 2011 12:34:25 -0500
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Si vas a usar Bases de Datos SQL entonces te conviene que TODOS LOS PROCEDIMIENTOS que leen o escriben en las tablas se encuentren dentro de ellas, o sea como procedimientos almacenados.
Dentro de tus .PRG, formularios y clases, NO DEBERÍAS TENER funciones o procedimientos que lean o escriban datos en las tablas.
Esa es la forma correcta de trabajar con Cliente/Servidor, debes seguir con la filosofía: "todo lo que puede hacerse dentro de la Base de Datos debe hacerse dentro de la Base de Datos"
Y también: "por la red debe viajar la menor cantidad posible de datos"
Saludos.
Walter.
Date: Wed, 6 Jul 2011 12:34:25 -0500
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Antonio Samper
Jul 7, 2011, 12:04:13 PM7/7/11
to publice...@googlegroups.com
Gracias Walter y Carlos por sus excelentes respuestas, la duda me surgue por que en el ejemplo de SQLdemo veo que se transportan los datos de los productos al cliente para ser validados y no se realiza por un store proc, entonces yo me pregunto si fueran varias estaciones de trabajo haciendo esto osea transportando datos de los maestros de productos, clientes, etc.., desde el servidor a los clientes no conlleva a una sobrecarga?.
Como suelen trabajan los ERP de las grandes corporaciónes financieras o de los grades grupos empresariales en donde es probable que cada una de sus sucursales esten conectadas todas a un mismo servidor?
Gracias amigos.
y disculpen si mis apreciaciones puedan estar desefocadas.
saludos
Antonio.
Walter R. Ojeda Valiente
Jul 7, 2011, 12:29:30 PM7/7/11
to publice...@googlegroups.com
Hola Antonio
En SQL_DEMO se utiliza la técnica recomendada para Cliente/Servidor.
1. Los datos de todos los clientes (que están en el Servidor) se copian en una tabla local, UNA SOLA VEZ, al instalar la aplicación en esa computadora
2. La validación de los datos de los clientes se realiza en la tabla local, que es muchísimo más rápida
3. Antes de realizar esa validación se verifica que no haya clientes nuevos en el Servidor. Si los hay, solamente los datos de los clientes nuevos se copian en la tabla local.
La razón para hacerlo de esta manera es para que por la red circulen la menor cantidad de datos posibles. Y por lo tanto, que todas las validaciones se realicen muy rapidamente. Aunque tengas 2.000 estaciones de trabajo actualizando datos, igualmente todo funcionará velozmente porque el tráfico por la red es mínimo.
Saludos.
Walter.
Date: Thu, 7 Jul 2011 11:04:13 -0500
En SQL_DEMO se utiliza la técnica recomendada para Cliente/Servidor.
1. Los datos de todos los clientes (que están en el Servidor) se copian en una tabla local, UNA SOLA VEZ, al instalar la aplicación en esa computadora
2. La validación de los datos de los clientes se realiza en la tabla local, que es muchísimo más rápida
3. Antes de realizar esa validación se verifica que no haya clientes nuevos en el Servidor. Si los hay, solamente los datos de los clientes nuevos se copian en la tabla local.
La razón para hacerlo de esta manera es para que por la red circulen la menor cantidad de datos posibles. Y por lo tanto, que todas las validaciones se realicen muy rapidamente. Aunque tengas 2.000 estaciones de trabajo actualizando datos, igualmente todo funcionará velozmente porque el tráfico por la red es mínimo.
Saludos.
Walter.
Date: Thu, 7 Jul 2011 11:04:13 -0500
Antonio Samper
Jul 7, 2011, 1:12:23 PM7/7/11
to publice...@googlegroups.com
ah Ok, Walter ya entiendo osea estas tablas locales son utilizadas unicamente para validaciones,osea que en estas tablas locales unicamente los compas que voy a validar por ej: para validar un cliente unicamente almaceno en mi tabla local el nit por ejemplo si es unicamente para validar, porque si las utilizó tambien para mostrar información en los reportes, consultas etc. que metodo recomiendas para actualizar la información residente en las tablas locales, dado algún usuario puede modificar la direccion, la ciudad, o eliminar ese cliente en el servidor.
Saludos
Antonio.
Walter R. Ojeda Valiente
Jul 7, 2011, 1:32:43 PM7/7/11
to publice...@googlegroups.com
Hola Antonio
En tus tablas locales solamente deberías guardar los datos que se usan muy frecuentemente, como el código y el nombre. Los demás datos los traes desde el Servidor cuando son requeridos.
Por ejemplo, para mostrar la dirección, el teléfono, la localidad, el e-mail, etc., una vez que seleccionó a un cliente sí necesitarás acceder al Servidor.
Y desde luego, para mostrar en un informe todos los datos completos de los clientes entonces sí accederías a la tabla que se encuentra en el Servidor.
Hay algo importante, los clientes y demás datos maestros NO DEBERÍAS ELIMINARLOS DEL SERVIDOR. Si estás totalmente seguro de que no los necesitarás más entonces les pones una marca de borrado en la tabla que se encuentra en el Servidor y ya está. Y las filas (registros) que tienen esa marca nunca las procesas.
Si no quieres que en las estaciones de trabajo se vean los datos de los clientes que tienen marca de borrado, entonces deberías tener un procedimiento almacenado en el Servidor que devuelva un cursor con los códigos de todos los clientes que tienen puesta esa marca. Luego en tu aplicación te encargas de borrar de la tabla local los códigos de los clientes que tienen puesta esa marca. Ese proceso podrías hacerlo cada vez que se ingresa a la aplicación.
Si se borró a un cliente en la sesión actual, sus código y nombre aún estarán en la tabla local, pero cuando quiera acceder con ese código al Servidor le muestras un mensaje de error.
Si se borró a un cliente en una sesión anterior, entonces no estarán sus códigos y nombres en la tabla local y por lo tanto no podrá elegir a ese cliente.
Saludos.
Walter.
Date: Thu, 7 Jul 2011 12:12:23 -0500
En tus tablas locales solamente deberías guardar los datos que se usan muy frecuentemente, como el código y el nombre. Los demás datos los traes desde el Servidor cuando son requeridos.
Por ejemplo, para mostrar la dirección, el teléfono, la localidad, el e-mail, etc., una vez que seleccionó a un cliente sí necesitarás acceder al Servidor.
Y desde luego, para mostrar en un informe todos los datos completos de los clientes entonces sí accederías a la tabla que se encuentra en el Servidor.
Hay algo importante, los clientes y demás datos maestros NO DEBERÍAS ELIMINARLOS DEL SERVIDOR. Si estás totalmente seguro de que no los necesitarás más entonces les pones una marca de borrado en la tabla que se encuentra en el Servidor y ya está. Y las filas (registros) que tienen esa marca nunca las procesas.
Si no quieres que en las estaciones de trabajo se vean los datos de los clientes que tienen marca de borrado, entonces deberías tener un procedimiento almacenado en el Servidor que devuelva un cursor con los códigos de todos los clientes que tienen puesta esa marca. Luego en tu aplicación te encargas de borrar de la tabla local los códigos de los clientes que tienen puesta esa marca. Ese proceso podrías hacerlo cada vez que se ingresa a la aplicación.
Si se borró a un cliente en la sesión actual, sus código y nombre aún estarán en la tabla local, pero cuando quiera acceder con ese código al Servidor le muestras un mensaje de error.
Si se borró a un cliente en una sesión anterior, entonces no estarán sus códigos y nombres en la tabla local y por lo tanto no podrá elegir a ese cliente.
Saludos.
Walter.
Date: Thu, 7 Jul 2011 12:12:23 -0500
Nilton CPM
Jul 7, 2011, 2:25:26 PM7/7/11
to publice...@googlegroups.com
Hola
Vai trafegar apenas com registros temporarios
ou grupo de registros temporarias, no caso de uma tela de
cadastro de clientes, você vai trazer apenas os dados desse cara para mostrar em
tela.
No caso de relatorios ai sim você vai trazer todo
um grupo de registros, criando um cursor em memoria.
A ideia é essa trafegar com o minimo possivel de
dados.
Um abraço...
+===============================+
# Nilton Cesar Puglia Menaré #
#-------------------------------#
# Celular BR: (53) 8100-6350 #
# Celular UY: 09873-6983 #
# MSN: nilto...@hotmail.com #
+===============================+
# Nilton Cesar Puglia Menaré #
#-------------------------------#
# Celular BR: (53) 8100-6350 #
# Celular UY: 09873-6983 #
# MSN: nilto...@hotmail.com #
+===============================+
Antonio Samper
Jul 7, 2011, 2:54:27 PM7/7/11
to publice...@googlegroups.com
Listo entendido Walter muchas gracias, anoche estuve conversando con un amigo acerca del tema el trabaja con un grupo empresarial han desarrollado un ERP con Oracle en cuanto al tema el me dice que esta situación es transparente para ellos, no se como lo hacen por que no pudimos seguir conversando de todas maneras quedamos en conversar este fin de semana asi que si me comenta algo diferente te lo estare comentando.
Nuevamente muchas gracias,
Antonio
rfsalasb
Jul 7, 2011, 6:04:09 PM7/7/11
to publicesvfoxpro
Walter, tomando el tema, porque tengo dudas a este respecto también... si cuando se ejecuta el sistema "baja" los datos del servidor a tablas locales, entonces somo se hace para mantener la congruencia de la información con otras sucursales o equipos que están simultaneamente realizando transacciones a la misma base de datos, y si hay que estar verificando en las tablas del servidor si hay nuevos datos para actualizarlos, ¿ no sería la misma carga de datos que estaría viajando por la red ? o por lo menos, habría que crear algún socket que se dispare cuando algo pase en la BD del servidor y estar actualizando las tablas del equipo conectado ?....
Pienso que sería mejor enviar la consulta o proceso a realizar pero para solo para el registro en cuestión, de esa forma no viajaría mayor información que la que corresponde a los datos a modificar/actualizar/procesar y el procesamiento sí se haría en el servidor.
No sería lo mismo estar verificando 2000 registros para tener los clientes actualizados que consultar solo por uno que es en el que estoy interesado en saber y procesar.
Digo esto porque no me queda muy claro el asunto de tener datos en el equipo si estamos con un servidor a donde concurren varias terminales, y donde los datos se ocupan conocer su estado actual en el momento, como sería saldos de una cuenta o stock en inventario de artículos.
Espero tus aportes, gracias.
Saludos.
------------------
rfsalasb
2011-07-07
-------------------------------------------------------------
Remitente:Walter R. Ojeda Valiente
Fecha:2011-07-07 10:29:55
Destinatario:publice...@googlegroups.com
CC:
Asunto:RE: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
Hola Antonio
En SQL_DEMO se utiliza la técnica recomendada para Cliente/Servidor.
1. Los datos de todos los clientes (que están en el Servidor) se copian en una tabla local, UNA SOLA VEZ, al instalar la aplicación en esa computadora
2. La validación de los datos de los clientes se realiza en la tabla local, que es muchísimo más rápida
3. Antes de realizar esa validación se verifica que no haya clientes nuevos en el Servidor. Si los hay, solamente los datos de los clientes nuevos se copian en la tabla local.
La razón para hacerlo de esta manera es para que por la red circulen la menor cantidad de datos posibles. Y por lo tanto, que todas las validaciones se realicen muy rapidamente. Aunque tengas 2.000 estaciones de trabajo actualizando datos, igualmente todo funcionará velozmente porque el tráfico por la red es mínimo.
Saludos.
Walter.
Pienso que sería mejor enviar la consulta o proceso a realizar pero para solo para el registro en cuestión, de esa forma no viajaría mayor información que la que corresponde a los datos a modificar/actualizar/procesar y el procesamiento sí se haría en el servidor.
No sería lo mismo estar verificando 2000 registros para tener los clientes actualizados que consultar solo por uno que es en el que estoy interesado en saber y procesar.
Digo esto porque no me queda muy claro el asunto de tener datos en el equipo si estamos con un servidor a donde concurren varias terminales, y donde los datos se ocupan conocer su estado actual en el momento, como sería saldos de una cuenta o stock en inventario de artículos.
Espero tus aportes, gracias.
Saludos.
------------------
rfsalasb
2011-07-07
-------------------------------------------------------------
Remitente:Walter R. Ojeda Valiente
Fecha:2011-07-07 10:29:55
Destinatario:publice...@googlegroups.com
CC:
Asunto:RE: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
Hola Antonio
En SQL_DEMO se utiliza la técnica recomendada para Cliente/Servidor.
1. Los datos de todos los clientes (que están en el Servidor) se copian en una tabla local, UNA SOLA VEZ, al instalar la aplicación en esa computadora
2. La validación de los datos de los clientes se realiza en la tabla local, que es muchísimo más rápida
3. Antes de realizar esa validación se verifica que no haya clientes nuevos en el Servidor. Si los hay, solamente los datos de los clientes nuevos se copian en la tabla local.
La razón para hacerlo de esta manera es para que por la red circulen la menor cantidad de datos posibles. Y por lo tanto, que todas las validaciones se realicen muy rapidamente. Aunque tengas 2.000 estaciones de trabajo actualizando datos, igualmente todo funcionará velozmente porque el tráfico por la red es mínimo.
Saludos.
Walter.
Date: Thu, 7 Jul 2011 11:04:13 -0500
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Gracias Walter y Carlos por sus excelentes respuestas, la duda me surgue por que en el ejemplo de SQLdemo veo que se transportan los datos de los productos al cliente para ser validados y no se realiza por un store proc, entonces yo me pregunto si fueran varias estaciones de trabajo haciendo esto osea transportando datos de los maestros de productos, clientes, etc.., desde el servidor a los clientes no conlleva a una sobrecarga?.
Como suelen trabajan los ERP de las grandes corporaciónes financieras o de los grades grupos empresariales en donde es probable que cada una de sus sucursales esten conectadas todas a un mismo servidor?
Gracias amigos. y disculpen si mis apreciaciones puedan estar desefocadas. saludos Antonio.
El 6 de julio de 2011 20:46, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:
Hola Antonio
Si vas a usar Bases de Datos SQL entonces te conviene que TODOS LOS PROCEDIMIENTOS que leen o escriben en las tablas se encuentren dentro de ellas, o sea como procedimientos almacenados.
Dentro de tus .PRG, formularios y clases, NO DEBERÍAS TENER funciones o procedimientos que lean o escriban datos en las tablas.
Esa es la forma correcta de trabajar con Cliente/Servidor, debes seguir con la filosofía: "todo lo que puede hacerse dentro de la Base de Datos debe hacerse dentro de la Base de Datos"
Y también: "por la red debe viajar la menor cantidad posible de datos"
Saludos.
Walter.
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Gracias Walter y Carlos por sus excelentes respuestas, la duda me surgue por que en el ejemplo de SQLdemo veo que se transportan los datos de los productos al cliente para ser validados y no se realiza por un store proc, entonces yo me pregunto si fueran varias estaciones de trabajo haciendo esto osea transportando datos de los maestros de productos, clientes, etc.., desde el servidor a los clientes no conlleva a una sobrecarga?.
Como suelen trabajan los ERP de las grandes corporaciónes financieras o de los grades grupos empresariales en donde es probable que cada una de sus sucursales esten conectadas todas a un mismo servidor?
Gracias amigos. y disculpen si mis apreciaciones puedan estar desefocadas. saludos Antonio.
El 6 de julio de 2011 20:46, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:
Hola Antonio
Si vas a usar Bases de Datos SQL entonces te conviene que TODOS LOS PROCEDIMIENTOS que leen o escriben en las tablas se encuentren dentro de ellas, o sea como procedimientos almacenados.
Dentro de tus .PRG, formularios y clases, NO DEBERÍAS TENER funciones o procedimientos que lean o escriban datos en las tablas.
Esa es la forma correcta de trabajar con Cliente/Servidor, debes seguir con la filosofía: "todo lo que puede hacerse dentro de la Base de Datos debe hacerse dentro de la Base de Datos"
Y también: "por la red debe viajar la menor cantidad posible de datos"
Saludos.
Walter.
Date: Wed, 6 Jul 2011 12:34:25 -0500
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Walter he estado analizando y tratando de aprender de tu excelente trabajo, quiero desarrollar un aplic con un motor sql y queria preguntarte que vventajas o desventajas se tienen a la hora programar de esta manera, ya que en el caso de los proc almacenados unicamente se tienen para actualizar las tablas del servidor, los procedimientos ya mas complejos deberia tenerlos siempre en un prg y no en un proc almacenados?, siendo asi no estaria perdiendo las bondades que me ofrece el servidor ? o estando en un prg se ejecutan con la misma velocidad que estando almacenados en la bd?.
Saludos,
Tony
El 5 de julio de 2011 20:43, Adolfo Leon Quintero Hoyos <todoso...@gmail.com> escribió:
Gracias Walter, me parece excelente voy a buscar mas para saber que tengo que tener en cuenta
Saludos
Adolfo
El 5 de julio de 2011 20:09, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:
Puedes descargar SQL_DEMO, allí tienes los códigos fuentes y la explicación de una aplicación completa que usa Firebird.
http://www.mediafire.com/?dugbqkqt4tx6bdl
Saludos.
Walter.
Subject: Re: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
From: sasys...@gmail.com
To: publice...@googlegroups.com
Walter he estado analizando y tratando de aprender de tu excelente trabajo, quiero desarrollar un aplic con un motor sql y queria preguntarte que vventajas o desventajas se tienen a la hora programar de esta manera, ya que en el caso de los proc almacenados unicamente se tienen para actualizar las tablas del servidor, los procedimientos ya mas complejos deberia tenerlos siempre en un prg y no en un proc almacenados?, siendo asi no estaria perdiendo las bondades que me ofrece el servidor ? o estando en un prg se ejecutan con la misma velocidad que estando almacenados en la bd?.
Saludos,
Tony
El 5 de julio de 2011 20:43, Adolfo Leon Quintero Hoyos <todoso...@gmail.com> escribió:
Gracias Walter, me parece excelente voy a buscar mas para saber que tengo que tener en cuenta
Saludos
Adolfo
El 5 de julio de 2011 20:09, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:
Puedes descargar SQL_DEMO, allí tienes los códigos fuentes y la explicación de una aplicación completa que usa Firebird.
http://www.mediafire.com/?dugbqkqt4tx6bdl
Saludos.
Walter.
Walter R. Ojeda Valiente
Jul 7, 2011, 9:55:39 PM7/7/11
to publice...@googlegroups.com
No, no se "bajan" los datos del Servidor a las tablas locales cuando se "ejecuta" el Sistema, sino SOLAMENTE UNA VEZ, cuando se lo instala. Cuando instalas tu Sistema en una computadora también llenas las tablas locales con los datos de las tablas del Servidor, pero no con todos los campos, sino solamente los que usas muy frecuentemente, tipicamente Código y Nombre.
Pero esto es solamente con las tablas MAESTRAS, las tablas de MOVIMIENTO están en el Servidor y solamente en el Servidor.
En el Servidor están siempre todos los datos actualizados, sin excepción. Es en las tablas locales donde pueden aún existir códigos que fueron eliminados del Servidor durante la sesión actual.
Por eso, cada vez que ejecutas tu Sistema lo primero que hace es ejecutar un Procedimiento Almacenado que le devuelve un cursor con todos los códigos eliminados. Si alguno de esos códigos está en la tabla local, lo elimina de allí. En cambio, si un cliente fue eliminado durante la sesión actual, sus datos ya no estarán en el Servidor, pero sí en la tabla local. Cuando lo busques en el Servidor no lo encontrarás allí y por lo tanto le mostrarás un mensaje de error al usuario.
Durante el trabajo normal la tabla local se actualiza solamente si hay datos nuevos en el Servidor. Por ejemplo:
- El último Código que tienes en la tabla CLIENTES local es el 2000
- El último Código que tienes en la tabla CLIENTES del Servidor es el 2003
- Entonces actualizas tu tabla local con los Códigos 2001, 2002 y 2003, y con sus respectivos Nombres
¿Cuándo realizas esta verificación? Cuando validas el código del cliente. Mientras no necesites validar el código de un cliente no tocas la tabla local, queda como estaba. Puede estar muchos días desactualizada si no se accede a ella, pero eso no importa, porque cuando se necesite que esté actualizada lo estará.
Recuerda que en las computadoras hay tablas locales solamente para las tablas MAESTRAS (Clientes, Proveedores, Productos, Países, etc.). Las tablas de MOVIMIENTO (Compras, Ventas, Cobranzas, Pagos, etc.) están en el Servidor y solamente en el Servidor.
Esta técnica es rapidísima y además muy amigable con el usuario. Puedes mostrarle en una grilla los Códigos y Nombres de todos sus clientes, aunque sean muchos miles, casi instantáneamente porque lo que él ve en la pantalla es el contenido de una tabla local. Después que seleccionó a uno de esos clientes, y solamente después de seleccionarlo, es que accedes al Servidor para recuperar los demás datos (dirección, teléfono, localidad, e-mail, etc.) de ese cliente.
Espero haberme explicado bien, cualquier duda, ya sabes que puedes consultarme.
Saludos.
Walter.
Pero esto es solamente con las tablas MAESTRAS, las tablas de MOVIMIENTO están en el Servidor y solamente en el Servidor.
En el Servidor están siempre todos los datos actualizados, sin excepción. Es en las tablas locales donde pueden aún existir códigos que fueron eliminados del Servidor durante la sesión actual.
Por eso, cada vez que ejecutas tu Sistema lo primero que hace es ejecutar un Procedimiento Almacenado que le devuelve un cursor con todos los códigos eliminados. Si alguno de esos códigos está en la tabla local, lo elimina de allí. En cambio, si un cliente fue eliminado durante la sesión actual, sus datos ya no estarán en el Servidor, pero sí en la tabla local. Cuando lo busques en el Servidor no lo encontrarás allí y por lo tanto le mostrarás un mensaje de error al usuario.
Durante el trabajo normal la tabla local se actualiza solamente si hay datos nuevos en el Servidor. Por ejemplo:
- El último Código que tienes en la tabla CLIENTES local es el 2000
- El último Código que tienes en la tabla CLIENTES del Servidor es el 2003
- Entonces actualizas tu tabla local con los Códigos 2001, 2002 y 2003, y con sus respectivos Nombres
¿Cuándo realizas esta verificación? Cuando validas el código del cliente. Mientras no necesites validar el código de un cliente no tocas la tabla local, queda como estaba. Puede estar muchos días desactualizada si no se accede a ella, pero eso no importa, porque cuando se necesite que esté actualizada lo estará.
Recuerda que en las computadoras hay tablas locales solamente para las tablas MAESTRAS (Clientes, Proveedores, Productos, Países, etc.). Las tablas de MOVIMIENTO (Compras, Ventas, Cobranzas, Pagos, etc.) están en el Servidor y solamente en el Servidor.
Esta técnica es rapidísima y además muy amigable con el usuario. Puedes mostrarle en una grilla los Códigos y Nombres de todos sus clientes, aunque sean muchos miles, casi instantáneamente porque lo que él ve en la pantalla es el contenido de una tabla local. Después que seleccionó a uno de esos clientes, y solamente después de seleccionarlo, es que accedes al Servidor para recuperar los demás datos (dirección, teléfono, localidad, e-mail, etc.) de ese cliente.
Espero haberme explicado bien, cualquier duda, ya sabes que puedes consultarme.
Saludos.
Walter.
> Date: Thu, 7 Jul 2011 16:04:09 -0600
> From: rfsa...@gmail.com
> To: publice...@googlegroups.com
> Subject: Re: RE: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
> From: rfsa...@gmail.com
> To: publice...@googlegroups.com
> Subject: Re: RE: [vfp] VISUAL FOXPRO 9 CON Firebird 2.5
Reply all
Reply to author
Forward
0 new messages