Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > MySQL
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 14-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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
Responder Con Cita
  #2  
Antiguo 14-06-2012
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
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
Responder Con Cita
  #3  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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
Responder Con Cita
  #4  
Antiguo 18-06-2012
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
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
Responder Con Cita
  #5  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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
Responder Con Cita
  #6  
Antiguo 18-06-2012
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
El autocommit siempre lo tengo deshabilitado, prefiero controlarlo yo mismo, normalmente hago commit en el afterpost del dataset.
Responder Con Cita
  #7  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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
Responder Con Cita
  #8  
Antiguo 18-06-2012
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
¡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.
Responder Con Cita
  #9  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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!
Responder Con Cita
  #10  
Antiguo 18-06-2012
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Pues haz una búsqueda aquí, por los foros, porque es un tema que se ha tratado en diversas ocasiones
Responder Con Cita
  #11  
Antiguo 18-06-2012
Avatar de AzidRain
[AzidRain] AzidRain is offline
Miembro Premium
 
Registrado: sep 2005
Ubicación: Córdoba, Veracruz, México
Posts: 2.914
Poder: 21
AzidRain Va camino a la fama
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.
__________________
AKA "El animalito" ||Cordobés a mucha honra||
Responder Con Cita
  #12  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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

Última edición por waly2k1 fecha: 18-06-2012 a las 23:43:01.
Responder Con Cita
  #13  
Antiguo 18-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
Cita:
Empezado por Casimiro Notevi Ver Mensaje
El autocommit siempre lo tengo deshabilitado, prefiero controlarlo yo mismo, normalmente hago commit en el afterpost del dataset.
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!
Responder Con Cita
  #14  
Antiguo 21-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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!
Responder Con Cita
  #15  
Antiguo 21-06-2012
waly2k1 waly2k1 is offline
Miembro
 
Registrado: dic 2006
Ubicación: El país de las maravillas(Argentina)
Posts: 251
Poder: 18
waly2k1 Va por buen camino
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:

Código:
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!
Responder Con Cita
  #16  
Antiguo 31-03-2013
jpgonzalez jpgonzalez is offline
Miembro
 
Registrado: feb 2010
Posts: 121
Poder: 15
jpgonzalez Va por buen camino
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!
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
En FIBPlus uso de autocommit El_Raso Conexión con bases de datos 3 01-09-2011 01:10:51


La franja horaria es GMT +2. Ahora son las 01:21:14.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi