Debate. Todo lo que deben tener presente al trabajar con motores de base de datos. para no naufragar

[Germán Fabricio Valdez]

Consideraciones al trabajar con motores de base de datos, cliente-servidor, en mi experiencia no es sencillo.  German Fabricio Valdez. 

todo lo que deben tener presente. para no naufragar  

*conectar al servidor remoto: local, internet, hosting

*cada vez que se conecta al servidor, se deben enviar distintas instrucciones nuevamente

*a veces la conexion se muestra activa, pero no lo esta. y hay que reconectar

*mantener la conexion activa, impidiendo que el servidor corte la conexion por inactividad. durante 15 minutos, y luego cerrar la conexion.

*apertura y cierre de conexion por grupo de instrucciones.

*envio para alta velocidad: eliminar , actualizar, insertar, de a 100 registros, al servidor y operar alli. en lugar de instruccion por instruccion

*si se mantiene la conexion desde que las abren en en el programa, lo cierran al finalizar el programa. empieza a ponerse lento el servidor y los demas usuarios

*compatibilidad con los distintos tipos de campos

*manejo de fechas nulas, en lugar de fechas en blanco (da error al grabar)

*manejo de transacciones: se graban todas las tablas relacionadas, y si hay error no se graba ninguna: ejemplo cliente, detalle

*manejo de campos llaves:  id, idcliente, codcliente, "fecha,prefijo,numero" de distintas tablas. adaptando a otras tablas de distintas bases de datos que no usan id

*crear columnas adicionales para calculos, que no se deben grabar en la tabla, ejemplo "saldo"

*regular el tiempo de espera para que una instruccion se complete

*regular el tiempo de espera de una conexion al servidor.

*poder conectarse a distintos servidores a la vez.

*administrar archivos o imagenes en servidores.

*administrar errores. 

*hay funciones no documentadas de vfp.

*adaptarse a las distintas bases de datos mas usadas: sql server, mysql, mariadb, firebird, postgresql, oracle. automaticamente

*leer tablas maestro desde el servidor remoto (para llenar combos), y grabarlo en pc local. y la proxima vez que se ingresa al formulario, no vuelve a cargar todo nuevamente.

*los hosting, no son todos iguales.  

* cambios debido a nuevos controladores odbc, oledb.  

[mapner]

Hola,

en efecto, manejar motores de BD no es algo simple, en cuanto diseño de meta-datos, implementación, conectividad, optimización, concurrencia, seguridad, etc... y requiere bastante tiempo de estudio... por suerte este foro, y en la web en general hay recursos más que suficientes para estudiar el tema... y estudiar en si, es hacer manejo de la complejidad...

Saludos!

[Carlos Miguel FARIAS]

Interesante lista de tópicos a tener en cuenta.

En cuanto a la conexión, no es lo mismo a una red local que una red que pasa por la web.

En la red local, si se corta la conexión y no es por un timer programado del SGBD, tienes que revisar la red. No puede cortarse porque si.

En todo caso, toda la operatoria contra bases de datos debe "envolverse" en un try..catch.

Para las conexiones, en una variable global llevas la profundidad de formularios que acceden a la BD (la cuenta se incrementa en el load, se decrementa en el unload), cuando la cuenta llega a cero, se cierra si o si la conexión.

En mi enfoque cada formulario debería al activarse, chequear la conexión (acceder a algo el SGBD que devuelva algo, por ejemplo un SP que devuelva la fecha del servidor), si la cuenta es cero, debe conectarse (no hay conexión activa), al descargarse el formulario (unload, no desactivate), la cuenta se baja en un uno, si es menor que uno, se dispara la desconexión.

Si al chequear la conexión, hay un error, la cuenta vuelve a cero, el formulario continua funcionando si puede hacerlo sin conexión.

Para seguridad del sistema, todos los formularios lo pongo un timer que ante 5 minutos sin actividad (puede ser más o menos, según convenga), se cierra (eso lo implemento en una clase base de la que heredo todos los formularios).

De esa manera, si los usuarios entran en modo "limbo", el sistema se cierra solo y se evita que "ajenos" metan dedo.

Dependiendo del SGBD, dejar conexiones abiertas permanentes puede ser oneroso en dinero y lentoso en desempeño. Hay SGBD que pagan licencias por usuarios-conexión, o tienen limitada la cantidad de conexiones concurrentes.

En cuanto a la integridad de las transacciones, tienes dos opciones (al menos las que uso). Transacciones del SGBD y registro del estado de la transacción.

La transacción contra el SGBD es interesante por lo simple. El laburo de mantener el "paquete" completo se delega en el SGBD, pero en una operación larga (una factura con mucho detalle) que el usuario manda al servidor y se le cuelga la operación en el último segundo y tiene que recargar, te putean modo arcoiris.

Con lógica de registro de estado (lo he usado con foxdos sobre dbf, solo dos tablas rotas en 15 años, con no más de 10 transacciones anuales a reconstruir completa con hasta 10 cuelgues de máquina por problemas de drivers del S.O. (ajeno a la aplicación), creo que es bastante prueba.

El sistema consiste en que se utiliza un campo de estado para decir en que punto está cada registro (creándose, creado, revisión, agregando, cerrado, etc.). Se crea la factura, se la marca como creando, cuando se completaron los datos de cabecera, se marca como creada, al empezar a agregar items, se marca como agregando (lo mismo los ítems), de esa manera, ante un corte de conexión, solo se pierde algún registro o algún cambio de estado, pero no todo.

Después del "cuelgue", cuando el usuario pide crear una factura (pensando que perdió la anterior), el sistema busca y recupera la factura creándose, creada o agregando del usuario) con todo el detalle asociado. La pérdida puede ser solo del último renglón.

Cuando se cierra la factura, ahí si se manda una transacción para que cambie los estados a cerrado tanto de cabecera como del detalle.

A mi me funcionó (en varios sistemas tanto en foxdos contra dbf como vfp contra mysql en la web). En aplicaciones PHP también usábamos un método parecido.

En web lo aplicamos porque además, el sistema necesitaba carga de datos discontinua. El caso era de órdenes de reposición de papelería y demás para oficinas del Municipio, el usuario empezaba a hacer la orden de pedido, y era interrumpido por alguna otra urgencia administrativa (trámite específico, pedido del jefe, hora del mate, ganas de WC).

Saludos: Miguel

--
Visita el Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/68873b81-7716-45c1-a3f8-ac34df1a55fcn%40googlegroups.com.

[HernanCano]

Muy bien, colegas, estos aportes.

Da para "buenas prácticas". Ojalá nos animemos a organizar un documento al respecto.