Autocommit....
 

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

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 :)

Problemas con autocommit con Zeos
 

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

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 :)

Aclaración
 

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

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

Gracias!
 

No manejo dataset actualizables, todas mis actualizaciones son a travez del gestor de BD
en este caso MySQL por medio de Stored Procedures.
Voy a estudiar más el tema del autocommit en false entonces y ver bien el por qué falla
en determinados lugares.
Muchas gracias por tu tiempo y dedicación
Walter

¡Ah!, entonces es distinto, todo lo que ocurre dentro del 'stored procedure' ocurre en una transacción, pero la verdad es que desconozco cómo funciona mysql en ese aspecto, por lo que tengo leído/escuchado, con mysql hay distintas formas de usar la base de datos, y el método "estandar" no contempla procedimientos, triggers, etc.
Así que ahí no puedo ayudarte mucho, a ver si alguien "más puesto" te puede ayudar.

Si es muy cierto eso, es un tema adoptado hace no mucho tiempo en mysql, ya que las primeras versiones
no lo incluian, nose si vendrá por el motor el problema pero dudo, supongo que por zeos viene la mano.
Y bueh será cuestión de investigar más. Pero claro es más facil preguntar a otros que ya hayan pasado por
lo mismo que ponerse a investigar, vi unos foros en inglés de Zeos, pero redundan mucho y no dan solucion
clara al tema.
Nuevamente gracias!

Pues haz una búsqueda aquí, por los foros, porque es un tema que se ha tratado en diversas ocasiones

Meto mi cuchara.
MySQL sí acepta transacciones y las trata como tal, sí y solo si, las tablas implicadas son tipo InnoDB que son las únicas transaccionales que maneja este motor. Por default las tablas creadas son todas MyISAM, muchísimo más rápidas pero no aceptan transacciones. La forma como se manejan las transacciones en MySQL son totalmente distintas a Firebird. Veo que utilizas Zeos, los cuales yo también uso, son muy buenas y no dan problemas prácticamente de nada. Lo que sugiero es que manejes las transacciones directamente sobre MySQL, para ello solo requieres lanzar un query "START TRANSACTION" antes de lo que quieras hacer y un "COMMIT" O "CANCEL" dependiendo de lo que te salió.

Tengo un sistema actualmente trabajando que hace uso de transacciones para algunas cosas, si quieres lo pego pero depende de si es igual que lo que necesitas, en mi caso es para evitar folios duplicados.

Segun el foro de Zeos no hace falta el STARTTRANSACTION en las transacciones cuando es NO AUTOCOMMIT, basta con solo poner COMMIT/ROLLBACK
probé con una actualizacion simple y funciona. Ya probaré en varias actualizaciones y que falle una a ver si el ROLLBACK actua como deberia.
Es medio contradictorio esto, si no hay un start como podria haber un commit, pero es la forma de manejarlo, oracle no recuerdo mucho ya que
vi hace mucho tiempo y no llegué a realizar cosas serias sino a modo autodidacta nada mas, pero segun dicen tambien lo maneja así. Y de ahi
esta filosofía.

Todas mis tablas son de tipo InnoDB, no solo por manejar transacciones sino tambien el modelo relacional, ya que de tipo MyISAM no acepta
relaciones.
En fin seguiré probando mas tarde esto y posteo despues los resultados, pero si quieres pegar un fragmento de codigo bienvenido sea, aunque se
entiende perfectamente lo que dices.
Muchas gracias!

Edito: El error en el start es el siguiente: "Invalid operation in non AutoCommit mode"
Si en el StartTransaction me encuentro con esto ya no quería ni seguir. Saludos

Si claro, no me di cuenta de que no efectuas un StartTrasanction entonces, solo un Commit, es otra manera de actualización que efectuas, pero hablabamos de lo mismo
realmente.
Muchas gracias a todos!

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!

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:

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!

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!