![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Cita:
Pero como voy a empezar una transacción en un botón de un formulario, cambiar 7 veces de formulario para hacer otras cosas y acabarla en otro botón de otro formulario... Me parece demasiado pretender meterlo todo en la misma transacción. A ver, que parece que no me explico nada bien: Form1 : graba "Solicitud" y borra posibles líneas anteriores de "Det_Ppto". Además de otras cosas. Form2: graba "Det_Ppto", añade datos a "Solicitud" y borra posibles líneas anteriores de "Det_Solicitud". Además de otras cosas. Form3: graba "Det_Solicitud". Además de otras cosas. Form4: usado por "Form1" para seleccionar el cliente. Form5: usado por "Form1" para seleccionar la empresa. Form6: usado por "Form2" y "Form3". Form7: usado por "Form2". El problema, creo yo, radica en que las tablas han tenido que ser ampliadas porque se necesitaba almacenar una serie de datos que inicialmente no habían sido considerados y creo que se hizo mal, por eso el proceso da tantas vueltas. |
|
#2
|
||||
|
||||
|
¡¡Ya lo tengo!!
He creado esta estructura de componentes: * 3 TQuery con la consulta a la tabla correspondiente. Con la propiedad "Cached Updates" a true. * 3 TDataSource para relacionar las consultas y mostrar los datos. * 3 TUpdateSQL para controlar la inserción, relacionados con las consultas a través de la propiedad "UpdateObject". He sustituido todas las inserciones en la base de datos por métodos apend en los correspondientes TQuery. Las modificaciones y borrados igual, primero un locate y después lo que corresponda. Al finalizar todo el proceso, junto con la última grabación lanzo un procedimiento que inserta todos los datos en una única transacción. Me soluciona todos los problemas: * He tardado en encontrar la solución (y he intentado varias que no han servido) pero el resultado es simple y elegante... o eso me parece. * Si no finaliza el proceso no graba nada. * Permite consultar los datos en cualquier momento del proceso. * La estructura de componentes está en un DataModule y es accesible para todos los formularios en cualquier momento. * No tengo que redefinir nada en la BD. * Me sirven los formularios tal y como están. Los cambios son mínimos. * Me ahorro un móntón de consultas y chequeos que ahora están en un único punto. |
|
#3
|
|||
|
|||
|
Si utilizas oracle 9i deberias utilizar transacciones (Startransaction, commit, rollback) y ademas hay otro tema que deberias tener en cuenta. Existen savepoints (puntos de restauración) los cuales puedes definir varios (bastantes) de manera que al deshacer una transaccion podrías darle un rollback a un punto o dos o tres o....... anteriores con lo cual tu programa podía ir cerrando etapas y no mantener una transaccion abierta tanto tiempo como dices (recursos, bloqueos . . . . .). De todas formas puede ser que el fallo no venga de la transaccion, (tendrías el mismo problema con tablas temporales) sino del planteamiento de la pantalla de entrada de datos y del momento en que bloqueas tablas / recursos del sistema.
|
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| trabajar con tablas temporales | reevil | MySQL | 1 | 15-05-2006 15:57:09 |
| Tablas Temporales MySQL y Vb6 | Payola2011 | Varios | 2 | 08-02-2006 20:52:04 |
| Tablas Temporales y Grids | Payola2011 | MySQL | 0 | 08-02-2006 20:28:15 |
| Query con tablas temporales | cartmanrules | Firebird e Interbase | 4 | 27-05-2004 10:23:47 |
| Tablas Temporales en Interbase 7 | bismarito | Firebird e Interbase | 5 | 02-10-2003 11:12:11 |
|