Autocommit....

[waly2k1]

Muchachos acá una duda con Zeos. Perdon por continuar el hilo, pero no me parecia abrir otro hilo para hablar mas de lo mismo digamos
Si no pongo en el objeto connection la propiedad autocommit en true aborta por todos lados, pero que pasa? no puedo controlar la
transaccion, una facturación por ej. inserta datos en una tabla luego tiene que seguir por las demas y si algun Stored procedure falla
el insert, me quedan registros huerfanos y la imposibilidad de cargar nuevamente dicha factura.

La pregunta es como definen o como lo manejan eso, el sistema no deberia fallar, ya que se valida la información que ingresa, pero
un cliente muy especial siempre me sale con 'cositas' nuevas y tiene una calidad impresionante para encontrar la tecla de destrucción
masiva y/o autodestrucción, con lo cual logra explotar las PK.

En fin, cualquier comentario al respecto bienvenido sea y si está la solución mejor aún hehe.
Un abrazo y muchas gracias!
Walter

[Casimiro Notevi]

He movido este mensaje a un nuevo hilo porque no tiene absolutamente nada que ver con el tema donde lo habías puesto
Y recuerda poner títulos descriptivos, gracias

[waly2k1]

Bien ahí Casimiro, sorry por no abrir otro hilo.
no tuve ninguna respuesta al tema, qué raro.
Solo a mi me pasa eso?. No creo, pero bueno.
Saludos

[Casimiro Notevi]

Hola, no entiendo bien la pregunta, pero lo que explicas no tiene mucho sentido, principalmente dos cosas:
- Lo de las PK y la tecla de destrucción masiva de los clientes
- Registros huérfanos

Por lo que imagino que la base de datos adolece de algunos fallos en su estructura, o sea, que no está bien hecha.

¿Puedes ampliar el tema?, gracias

[waly2k1]

Si si, al encontrarse error de las PK denota una falla en las estructuras de la BD, por ej no contemplaba la posibilidad
de abonar un comprobante de Venta con más de un mismo medio de pago repetido, por ej. con tres cheques, sí con 4 medios
de pagos distintos como máximo que es lo que la AFIP Argentina permite como maximo.
La PK era tipo_comprobante, nro_comprobante, id_medio, al repetirse el id_medio en la insercion aborta.

El tema es que inserta la cabecera del comprobante bien, de ahi continua a los items y bien, luego al insertar los medios
de pago aborta por el tema que te mencionaba recien, pero ya quedaron los registros anteriores en las otras tablas,
hago un rollback en caso de detectar algun error, pero no funciona.
Antes de iniciar cualquier inserción tengo un starttransaction, luego un commit al finalizar y/o rollback en caso de error
en el try, pero el objeto connection ya tiene la propiedad autocommit en true, si la pongo en false saltan errores por
cualquier otro motivo en otros formularios que funcionan bien ya que actualizan una sola tabla.

De ahi viene mi pregunta en como manejar el tema del autocommit, espero se entienda mejor ahora.
Como manejarlo en caso de actualizaciones masivas y que el rollback funcione como debería ser antes cualquier falla
en un stored procedure de inserción.

Saludos y desde ya muchas gracias

[Casimiro Notevi]

El autocommit siempre lo tengo deshabilitado, prefiero controlarlo yo mismo, normalmente hago commit en el afterpost del dataset.

[waly2k1]

Hola muchachos, despues de tantas pruebas y pruebas y el resultado fue el mismo llegué a la conclusión de que es MySQL que trabaja por
default con Autocommit y despues lo corroboré.

AzidRain: Comprobé enviando por medio de una query 'START TRANSACTION', pero no funciona, no da error, pero genero adrede un error
enviando un parametro demás al Stored Procedure y generando una excepcion de este modo, pero el rollback de la Conx no hace nada, probé
enviando además un rollback por query de la misma manera, pero tampoco.
Quedan tablas con registros y no llega a terminar la transaccion. Ahora voy a probar poner set autocommit=0 en el .ini de mySQL
a ver si con esto logro lo que busco, sino voy a tener que ir descartando MySQL en futuros proyectos, ya que es muy poco serio esto.
Saludos!

[waly2k1]

Y yo nuevamente...
Me van a tener que perdonar por pesado pero bueno, no podía dejar esto así
Antes de iniciar la transaccion hay que enviar una Query:

sSQL := 'SET AUTOCOMMIT = 0';
Data.ExecSQL( sSQL, false );

sSQL := 'START TRANSACTION';
Data.ExecSQL( sSQL, false );

Data.ExecSQL, lo unico que hace es ejecutar la consulta que envio por parametro, existen miles de formas de hacerlo,
pero queria mostrar como hacer el tema del autocommit, y de esta forma síii funcionó al fin. Intenté poner en el archivo
de configuración de MySQL, pero no lo toma, genera un error y no se inicia el servicio.

Espero a alguien más le sirva esto, ya que siempre es bueno poder restaurar las tablas a su estado normal ante una falla de
cualquier naturaleza y de esta forma no perder la atomicidad que es una propiedad de una base de datos para poder serlo
precisamente. Es muy raro que MySQL venga por Defecto con autocommit activado, está muy mal esto.

Saludos gente!

[jpgonzalez]

Buenas, he probado esto que comentan, dado que yo tenia el mismo problema con el autocommit.
Puse el autocommit en false, y al hacer el start transaction me tiraba el error.

Ahora lo puse en false, y saque el comando starttransaction, y me ocurre otra cosa...
En el programa me aparece como que el dato esta guardado, pero en la bbdd no se guarda.
Esto me sucede al insertar un subtipo de articulo en la tabla SubtipoArticulo de mi BBDD.

En el DBGrid aparece como que esta creado, pero al revisar la tabla con el MySQL Workbench la tabla esta vacia.
¿Por que puede estar ocurriendo esto?... es como si el commit lo hiciera en memoria, en lugar de hacerlo en la BBDD... desde ya muchas gracias, abrazo!