Cita:
Empezado por Al González
Saludos PepeLolo.
¿A qué te refieres con esto?
|
El mundo gira alrededor de un formulario con rejilla. Sobre el que se implementa las funcionalidades (Edición, Listados, consultas, Reportes, Filtros, acciones especificas, etc..). Al usuario se le muestra un conjunto de datos filtrados en función del perfil de este(guapo, feo, bonito, atún con ojos, directivo, etc..
). Mientras el usuario este en este formulario la transacción esta activa. Al cerrar el formulario se finaliza la transacción.
Cita:
Empezado por Al González
A mí ya me están pareciendo excesivos los 31 caracteres de Firebird. Estoy considerando renombrar una tabla "FacturacionActividadPartidaPago" por "FacturacionActividadPP" o "FacturacionAPP" y economizar en esfuerzo de lectura cuando veo por ahí el nombre de esa entidad. Y para nombres de procedimientos y disparadores que resulten necesariamente largos, abreviar. Después de todo cada objeto puede tener una descripción.  |
Efectivamente, nosotros hemos abreviado mucho desde que llegue a la empresa, pero la BBDD viene del 2003 y muchos objetos siguen activos. A modo de ejemplo:
Cita:
Materias primas -> AL_MAT_PRI = Almacén. Materias Primas.
Ordenes de producción -> PR_OP = Producción. Ordenes de producción
Albaranes -> FRA_ALB = Facturación. Albaranes. (Cabecera)
Líneas de detalle de albaranes -> FRA_ALB_DET = Facturación. Albaranes. Detalle.
Pedidos de compra -> CP_PED_COM -> Compras. Pedidos. De compra
Recepciones de compra -> CP_REC_COM -> Compras. Recepciones. Compras.
|
un trigger de una tabla. PD_NOT_INF_BI0.
Pero queda mierda suelta que como siempre no hay tiempo para solventarlo.
Cita:
Empezado por Al González
Quizá una mejor idea sería que la aplicación cierre la conexión tras un tiempo sin uso
|
Si es una buena opción que habrá que implantar.
Cita:
Empezado por Al González
Aunque no debería representar ningún problema dejarla abierta siempre que el cierre de las transacciones no dependa de a interfaz de usuario (una mala práctica por la que casi todos hemos pasado al incursionar en desarrollo cliente-servidor).
|
Eso depende del modo en que apliques la arquitectura cliente-servidor, me explico:
- En los procesos de disparo y olvido (actualizar un dato especifico), se define una transacción para la acción, independiente del resto.
- En formulario de edición largos (rellenar una factura), la transacción dura mientras el usuario no abandone el formulario con (Rollback o Commit).
- En las rejillas. Por cada acción de búsqueda que realiza el usuario se finaliza la transacción actual y se activa una nueva para con los resultados.
- Todas las transacciones por defecto son TaRollback.
La transacción en el formulario de rejilla se queda activa porque los capullines de los usuarios no cierran la aplicación, si añadimos a esto, que la aplicación presenta los formularios de rejillas en "Pestañas" a semejanza a como lo hace "Access" añadimos nuevas transacciones.
Lo normal es que un usuario tenga activas de 1 a 10 formularios (Ordenes de producción, Facturación, Presupuestos, identificación, tareas pendientes,
Almacén, Materiales, Compras, Recepciones, consultas, informes, Indicadores, etc...)
Cita:
|
Empezado por Ñuño Martínez
También podría ser (o no) que cierran la aplicación de una forma "inesperada". Quizá de forma que no envía el evento "onClose" a la ventana, si es ahí donde cierras la aplicación...
|
Esto no es posible por acción del usuario. Todos los formularios están creados mediante herencia visual ¡no me gusta escribir lo mismo más de una vez!. y tienen toda la funcionalidad básica que se necesita. (Diseño, controles y eventos).
gracias a todos