Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Conexión con bases de datos
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Conexión con bases de datos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 27-05-2005
DobleSiete DobleSiete is offline
Miembro
 
Registrado: ene 2005
Posts: 32
Poder: 0
DobleSiete Va por buen camino
deadlock en unas maquinas pero no en otras ???

Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5 (usando componentes IBX y ADO)... pero mi caso es algo distinto.

Ya he leído bastante al respecto como para saber que es un problema de transacciones... lo que no entiendo es porque en tres máquinas de la oficina tengo ese error, pero en la máquina de mi casa núnca aparece, de hecho, funciona perfectamente bien... y cuando hablo del mismo programa me refiero a que lo copio de un sitio y lo corro en otro.

Gracias a todos por adelantado.

PD: Algo realmente curioso es que en la máquina donde el programa funciona bien (ejecutado desde el disco duro) obtengo el mensaje de deadlock cuando lo ejecuto desde una memoria flash USB (un zMate Pen de 256 MB). ¿Alguien podría darme un explicación de este fenómeno?
__________________
"Nadie es perfecto" (Don Nadie)
Responder Con Cita
  #2  
Antiguo 27-05-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 21
jachguate Va por buen camino
Cool

Hola DobleSiete.

Cita:
Empezado por DobleSiete
Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5 (usando componentes IBX y ADO)... pero mi caso es algo distinto.
A que te referis con que es algo distinto... ¿distinto de que?

Cita:
Empezado por DobleSiete
Ya he leído bastante al respecto como para saber que es un problema de transacciones... lo que no entiendo es porque en tres máquinas de la oficina tengo ese error, pero en la máquina de mi casa núnca aparece
¿Seguro de haber leido suficiente?

Claro que en la máquina de tu casa, si no hay actualizaciones concurrentes, pues el problema nunca se dará. (ver lo que he subrayado en el mensaje de error de la primera cita).

Si logras simular las actualizaciones concurrentes, seguro que el problema se dará nuevamente. Las técnicas para evitar este problema son, principalmente, hacer las transaccoines tan cortas como sea posible (por ejemplo, usando el caché de actualizaciones y volteando todo a la BD en unos cuantos milisegundos) y hacer que las actualizaciones se realicen en el mismo orden sobre los registros en todos los clientes, con lo que algunos quedarán esperando que finalicen las transacciones de otros, pero se minimiza la posibilidad de deadlocks.

No es normal que una sola aplicación cliente produzca deadlocks solita... siempre que uses una sola transacción dentro de la aplicación. Si hay varias transacciones abiertas, si que la aplicación sola puede hacerse el candadito..


Cita:
Empezado por DobleSiete
Algo realmente curioso es que en la máquina donde el programa funciona bien (ejecutado desde el disco duro) obtengo el mensaje de deadlock cuando lo ejecuto desde una memoria flash USB (un zMate Pen de 256 MB). ¿Alguien podría darme un explicación de este fenómeno?
Sinceramente, no creo que tenga que ver con el origen del ejecutable... seguramente ha coincidido con que en esas ejecuciones ha habido concurrencia de actualizaciones.

Hasta luego.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #3  
Antiguo 30-05-2005
DobleSiete DobleSiete is offline
Miembro
 
Registrado: ene 2005
Posts: 32
Poder: 0
DobleSiete Va por buen camino
La unica diferencia que hay entre el funcionamiento del programa en la oficina y mi casa, es en la ubicación de los archivos DBF. En la oficina están en un servidor Novel NetWare, el acceso se realiza en la unidad M:, pero en mi casa debo simular esa unidad en mi maquina usando SUBST M: C:\DBF, apartando eso no hay diferencia...

Por que si fuese por que alguien más está tocando los DBF ¿por antes no tuve problemas? las consultas son simples SELECT a tablas relacionales, que se llenan en tiempo de ejecución con el contenido de los archivos dbase. Se supone que antes debería haber sucedido, pero no, no es el caso.

Creo que la causa del problema que se presento fueron dos ADOTable que leían la misma tabla, pero el asunto es que esto dos componentes eran llamados por dos eventos OnClick separados, así que no hay confusión que valga.


PD. como sea tuve que tomar una versión anterior (que funciona bien) y comencé a modificarla y compilarla poco a poco... pero el error no ha vuelto a repetirse... es más, el módulo ya está terminado y funciona a la perfección, que hice o no hice es la cuestión.
__________________
"Nadie es perfecto" (Don Nadie)
Responder Con Cita
  #4  
Antiguo 30-05-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 21
jachguate Va por buen camino
Unhappy



ahora si que estoy confundido... en tu primer mensaje se leía:

Cita:
Empezado por DobleSiete
Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5
Y ahora...

Cita:
Empezado por DobleSiete
La unica diferencia que hay entre el funcionamiento del programa en la oficina y mi casa, es en la ubicación de los archivos DBF.
...
los archivos dbase
Mientras no sepamos de que estamos hablando exactamente... me parece imposible continuar con el tema...
__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #5  
Antiguo 31-05-2005
DobleSiete DobleSiete is offline
Miembro
 
Registrado: ene 2005
Posts: 32
Poder: 0
DobleSiete Va por buen camino
Disculpa la confusión...

No quise hechar todo el cuento por que no me parecía necesario, pero ya veo que sí :-)

Los datos se encuentran en formato dBASE III en un servidor Novell NetWare, compartidos a través de la unidad de red M:\, el programa en Delphi 7 y la base de datos InterBase 6.5 se encuentran en la estación de trabajo.

¿Por que este enredo...? ¿Por que no usar IB y punto? muy simple, estamos en un periodo de transición, estamos pasando de Clipper 5.01 y dBase III a Delphi 7 e InterBase 6.5. Los datos siguen en los DBF del servidor y seguirán así por un tiempo, la base de datos IB almacena los datos temporalmente pues al entrar al modulo lo primero que se hace es borrar las tablas respectivas y llenarlas con los archivos DBF correspondientes. Para esto utilizo componentes ADO (para los DBF) y IBX (para InterBase).

Ahora mi pregunta es ¿cual de los dos componentes genera el mensaje deadlock? no recuerdo haber tocado propiedades de ningun componentes de acceso a bases de datos (ni ADO ni IBX). El modulo funcionaba bien y de buenas a primeras apareció el error... un error que ya no veo (el modulo está terminado y funciona perfectamente, pero tuve que retrocer).

Inclusive en fases de pruebas anteriores se ejecutaba el programa hecho en Clipper y el programa en Delphi, ambos en diferentes estaciones accesando a los mismos archivos DBF en la unidad M:\ del servidor NetWare, y funcionaba perfectamente bien. Por eso estaba asumiendo que el error estaba en los IBTable o en el IBDatabase

Estoy preguntando todo esto por que sería fatal que en el futuro volviera a aparecer el mismo error y me viese obligado a reescribir codigo.
__________________
"Nadie es perfecto" (Don Nadie)
Responder Con Cita
  #6  
Antiguo 31-05-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 21
jachguate Va por buen camino
Hola.

A mi manera de ver, el deadlock puede ocurrir en cualquiera de las dos conexiones, pero dudo que la de DBase te devolviera una excepción... seguramente se quedaría toda la vida esperando a que el deadlock dejase de existir (cosa que sabemos es imposible). Probablemente ADO daría un timeout... pero no lo he probado.

En ib/fb, por el contrario, el deadlock se reportará tan rápido como sea detectado por el motor. Para el futuro, creo que lo importante es que comprendas en que consiste el deadlock, pues este no se produce por si mismo... hay algo en la forma de operar el programa o en el propio código que lo produce y el motor de la base de datos no puede mas que simplemente reportarlo.

Hasta luego.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #7  
Antiguo 01-06-2005
DobleSiete DobleSiete is offline
Miembro
 
Registrado: ene 2005
Posts: 32
Poder: 0
DobleSiete Va por buen camino
Bueno... no me queda mas que estar pendiente, al menos tengo dos programas que hacen (casi) lo mismo. Tendría que revisar linea por linea, o propiedad por propiedad... pero al menos con tu explicación se que no son los componentes ADO (pues leen archivos DBF que no son muy comunicativos con los errores :-) deben estar con los IBX.

El asunto es buscar tiempo y juntarlo con algo de curiosidad ...

muchas gracias por la explicación.
__________________
"Nadie es perfecto" (Don Nadie)
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


La franja horaria es GMT +2. Ahora son las 22:39:04.


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