Hola amigos
Alguien sabe si es posible usar control de transacciones en FWH ?
Necesito controlar que una transacción en la que intervienen varias bases de datos DBF se ejecute en su totalidad y de haber errores no se haga ningun cambio en las bases de datos involucradas.
He visto que esto usando BEGIN TRANSACTION ROLLBACK END se puede usar en SQL y en FOX pero no se si lo mismo se puede aplicar a FWH
He usado TRY CATCH END pero no hace lo mismo, solamente detecta los errores pero no evita los cambios en las DBF's hasta que se produce el error.
En un sistema de facturacion tengo transacciones complejas que cuando algo falla me dejan los cambios por la mitad y me provocan discordancias en los resultados finales (cosa grave en los sistemas contables ). Alguien me puede orientar con este tema ?
Salu2
BEGIN TRANSACTION
-
ruben Dario
- Posts: 1070
- Joined: Thu Sep 27, 2007 3:47 pm
- Location: Colombia
Re: BEGIN TRANSACTION
Saludos
TRY CATCH END cuando la usas me dices te genera el error pero te graba en los DBF, deberia de funcionar, todo depende de como lo tengas implementado,
coloca un trozo de codigo
TRY CATCH END cuando la usas me dices te genera el error pero te graba en los DBF, deberia de funcionar, todo depende de como lo tengas implementado,
coloca un trozo de codigo
Re: BEGIN TRANSACTION
Hola Ruben
En este momento no tengo ejemplo real del codigo para mostrarte porque como no me andaba lo saque.
El tema seria asi:
use BASe 1
varios reemplazos ...
use BAse 2
varios reemplazos
son como 10 bases de datos que se actualizan
ahora bien:
Si uso el TRY CATCH el proceso se puede interrumpir, al no poder hacer un dbrlock() de un registro por ejemplo, pero todos los reemplazos anteriores al error se hacen!!!
no me sirve porque ya se produjo el reemplazo parcial en las DBF y la transaccion queda incompleta
El BEGIN TRANSACCION de SQL y FOX controla que se ejecute toda la transaccion y si en el medio se produce un error hace un ROLLBACK y deja todo sin tocar.
Por lo que lei lo que hace es hacer TODOS los rlock() de los registros implicados antes de hacer cambios, si eso no da error recien ahi hace los cambios efectivos, pero si da un error vuelve para atras sin hacer nada.
Ahi te garantizas que se haga todo o no se haga nada, me explico
abrazo
En este momento no tengo ejemplo real del codigo para mostrarte porque como no me andaba lo saque.
El tema seria asi:
use BASe 1
varios reemplazos ...
use BAse 2
varios reemplazos
son como 10 bases de datos que se actualizan
ahora bien:
Si uso el TRY CATCH el proceso se puede interrumpir, al no poder hacer un dbrlock() de un registro por ejemplo, pero todos los reemplazos anteriores al error se hacen!!!
no me sirve porque ya se produjo el reemplazo parcial en las DBF y la transaccion queda incompleta
El BEGIN TRANSACCION de SQL y FOX controla que se ejecute toda la transaccion y si en el medio se produce un error hace un ROLLBACK y deja todo sin tocar.
Por lo que lei lo que hace es hacer TODOS los rlock() de los registros implicados antes de hacer cambios, si eso no da error recien ahi hace los cambios efectivos, pero si da un error vuelve para atras sin hacer nada.
Ahi te garantizas que se haga todo o no se haga nada, me explico
abrazo
Re: BEGIN TRANSACTION
Hola,
Fivewin no es una bb.dd. sino una libreria, asi que no puede tener BEGIN TRANSACION.
Sería Harbour el que podría tenerlo en las .dbfs, pero no es el caso.
Lo que yo haría sería:
1º Abrir todas las .dbfs al principio
2º Comprobar que los indices .cdx y las .dbfs implicadas no estén corruptas. Esto es bien facil, por ejemplo, sobreescribiendo el ultimo registro y un registro intermedio de la .dbf
3º Preparar toda la información que se ha de grabar, bien en arrays, bien en archivos temporales
4º Grabar la informacion bajo un TRY CATCH
5º y en caso de activarse el CATCH, entonces ahí deshacer lo grabado (pseudo roll back)
6º Cerrar todas las .dbfs abiertas
Del punto 2º al 4º es basicamente un artesano BEGIN TRANSACTION - END TRANSACTION
Veo dificil que este sistema no funcione en el 99.99% de los casos
Salu2
PD 1. Seria facil deshacer los registros grabados grabando en los arrays o dbfs. temporales la .dbf (alias) destino y el registro.
PD 2. Si se movieran campos contador se podrian decrementar solo si otro usuario no los hubiera incrementado. Este problema tambien existe en las TRANSACTION a nivel bb.dd.
PD 3. Se podria desarrollar alguna clase que maneje el array o .dbf temporal y que tambien haga el punto 5º
Fivewin no es una bb.dd. sino una libreria, asi que no puede tener BEGIN TRANSACION.
Sería Harbour el que podría tenerlo en las .dbfs, pero no es el caso.
Lo que yo haría sería:
1º Abrir todas las .dbfs al principio
2º Comprobar que los indices .cdx y las .dbfs implicadas no estén corruptas. Esto es bien facil, por ejemplo, sobreescribiendo el ultimo registro y un registro intermedio de la .dbf
3º Preparar toda la información que se ha de grabar, bien en arrays, bien en archivos temporales
4º Grabar la informacion bajo un TRY CATCH
5º y en caso de activarse el CATCH, entonces ahí deshacer lo grabado (pseudo roll back)
6º Cerrar todas las .dbfs abiertas
Del punto 2º al 4º es basicamente un artesano BEGIN TRANSACTION - END TRANSACTION
Veo dificil que este sistema no funcione en el 99.99% de los casos
Salu2
PD 1. Seria facil deshacer los registros grabados grabando en los arrays o dbfs. temporales la .dbf (alias) destino y el registro.
PD 2. Si se movieran campos contador se podrian decrementar solo si otro usuario no los hubiera incrementado. Este problema tambien existe en las TRANSACTION a nivel bb.dd.
PD 3. Se podria desarrollar alguna clase que maneje el array o .dbf temporal y que tambien haga el punto 5º
Re: BEGIN TRANSACTION
hola hnpaquito, gracias por tu sugerencia
Probe y anda...pero tengo un grave problema, cuando se produce un error se me altera la numeracion de los registros contables en la red, me es imposible controlar la numeracion ques correlativa y me aparecen agujeros en los libros
de todas maneras te agradezco tu interes
abrazo
Probe y anda...pero tengo un grave problema, cuando se produce un error se me altera la numeracion de los registros contables en la red, me es imposible controlar la numeracion ques correlativa y me aparecen agujeros en los libros
de todas maneras te agradezco tu interes
abrazo
Re: BEGIN TRANSACTION
Hola,
Esa situacion se corresponde con mi PD 2.
Hay que decrementarlos siempre que otro usuario no los incrementara. Como indico ese problema, los "huecos" en las numeraciones, ocurrirá también con TRANSACTION de "serie"
En mi caso, en los libros más "delicados" uso una segunda numeracion, digamos por un lado "la del programa" y por otro lado la numeracion "oficial". A final de ejercicio o periodo se numera la oficial. De hecho lo tengo un poco más sofisticado, pero creo que la idea es clara. Y es casi un deber tenerlo asi en esos libros tan delicados porque los usuarios siempre quieren poder borrar y si borran fastidian la numeracion. Asi pues lo mejor es una segunda numeracion, al menos a mi me lo parece, siempre y cuando sea posible.
Atte.
Esa situacion se corresponde con mi PD 2.
PD 2. Si se movieran campos contador se podrian decrementar solo si otro usuario no los hubiera incrementado. Este problema tambien existe en las TRANSACTION a nivel bb.dd.
Hay que decrementarlos siempre que otro usuario no los incrementara. Como indico ese problema, los "huecos" en las numeraciones, ocurrirá también con TRANSACTION de "serie"
En mi caso, en los libros más "delicados" uso una segunda numeracion, digamos por un lado "la del programa" y por otro lado la numeracion "oficial". A final de ejercicio o periodo se numera la oficial. De hecho lo tengo un poco más sofisticado, pero creo que la idea es clara. Y es casi un deber tenerlo asi en esos libros tan delicados porque los usuarios siempre quieren poder borrar y si borran fastidian la numeracion. Asi pues lo mejor es una segunda numeracion, al menos a mi me lo parece, siempre y cuando sea posible.
Atte.