Comunidad Gambas-es

Hola amigos,

Necesito saber como evitar que mi software se cuelgue ante un desconexión
del la base de datos.

Lo que pasa es que en medio de cierta consulta puede ocurrir una desconexión
entonces no recibo ningún mensaje de error solo se congela el programa.

Para conectar uso este código:

conn = New Connection
conn.Host = DBhostname
conn.Name = DBnom
conn.Type = "mysql"
conn.Port = "3306"
conn.User = UserDB
conn.Password = passDB
Try conn.Open

Gracias.

Hola

La propiedad Timeout de la clase connection está por defecto en 20 segundos. Es decir, si no obtienes respuesta en esos 20sec la conexión se cierra (o debería). En cualquier caso, siempre antes de ejecutar cualquier consulta o transacción debes comprobar si la conexión está viva, en caso contrario reabrirla.

El valor de Timeout lo puedes establecer más corto, según necesidades. Pero puede que, como me imagino que estás conectando a un servidor remoto, lo que se pierde es la conexión TCP/IP y por tanto la conexión al servidor MySQL. En ese caso no tengo idea si mi sugerencia te puede servir.


http://gambaswiki.org/wiki/comp/gb.db/_connection/timeout


Saludos

Bien la conexión es vía internet. de todos modos voy a probar
la propiedad timeout.

Gracias por la ninfomaníaco.

La mala noticia es que para el núcleo del problema no hay solución. Si la conexión ha sido cortada por la parte servidor, gambas se cuelga.

Hay dos posibles culpables: El propio servidor de internet o la compañía proveedora de servicios que tengas.
El problema son los time-out de inactividad, porque nadie te va cortar la sesión a media consulta.

Cuando cambiamos en la empresa de Vodafone a Movistar nos encontramos con ese problema y en este caso el culpable era la compañía. Conectado con sus técnicos me ampliaron los time-out al máximo que su sistema les permitía que eran dos horas y por ese lado se solucionó.

Si tu servidor de base de datos tiene un time-out severo de inactividad (por defecto creo recordar que según que en Mysql son 180 segundos), tu programa se colgará. gambas no tiene más forma de saber si la conexión sigue abierta que preguntar (Connection.opened) a la propia conexión... y ahí se pierde y se cuelga.
Si controlas el servidor Mysql amplía esos time-out y no habrá problemas. Si no controlas el Servidor pregunta a los administradores si se pueden ampliar.

Si no, tu única solución pasa por adaptar tu programa con alguna de éstas soluciones:

1-Abre, consulta y cierra después en todas tus consultas. Eso enlentece mucho el proceso y es mucho código a añadir.

2-Crea una función que compruebe si la conexión está abierta connection.opened y si no lo está que la abra y paralelamente establece un timer, con un ciclo inferior al del servidor, que te cierre la conexión desde la parte cliente antes de que te la corten.

Yo llegué a establecer un sistema con dos conexiones gemelas, salvo en el nombre y las usaba alternativamene abriéndolas y cerrandolas de modo asíncrono... pero no llegué a implementarlo por lo que no sé si funcionaría en producción.

No sé sí te lío o te ayudo.

Saludos

Se que existe actualizaciones e inserciones a tiempo real.

Partiendo de este conocimiento por que no creas o manejas el concepto de actualizaciones e inserciones por lote. Y trabajas con una primera carga de datos en una cache local. De esta manera tan solo cuando vas a cargar la base de datos con novedades al ser por lote, la base de datos de sincronizará adecuadamente, por otra parte así evitas estos problemas que se subsanan con tiempos de lotaje sobre la base de datos.

Es solo una opinión, pero se admite ataques.

Nota: Y soy consciente que aquí solo se maneja la lectura en la pregunta, por lo tanto creo que el concepto de una carga de datos Internet-Cache local es mucho más factible. Se supone que el usuario lo hace al principio y no conecta hasta que de verdad lo necesite. Esto estaría bien solo para casos de poco movimiento de datos y de corto tiempo de uso de la cache local, si hay mucha concurrencia los datos de la cache local serian muy obsoletos. Aunque esto es válido si deseamos saber los datos pero antes de sus confirmación al usuario el programa confirma con un refresco la veracidad de los mismos.

Me vais a crucificar.

gambafeliz escribió:  

Se que existe actualizaciones e inserciones a tiempo real.

Partiendo de este conocimiento por que no creas o manejas el concepto de actualizaciones e inserciones por lote. Y trabajas con una primera carga de datos en una cache local. De esta manera tan solo cuando vas a cargar la base de datos con novedades al ser por lote, la base de datos de sincronizará adecuadamente, por otra parte así evitas estos problemas que se subsanan con tiempos de lotaje sobre la base de datos.

Es solo una opinión, pero se admite ataques.

Nota: Y soy consciente que aquí solo se maneja la lectura en la pregunta, por lo tanto creo que el concepto de una carga de datos Internet-Cache local es mucho más factible. Se supone que el usuario lo hace al principio y no conecta hasta que de verdad lo necesite. Esto estaría bien solo para casos de poco movimiento de datos y de corto tiempo de uso de la cache local, si hay mucha concurrencia los datos de la cache local serian muy obsoletos. Aunque esto es válido si deseamos saber los datos pero antes de sus confirmación al usuario el programa confirma con un refresco la veracidad de los mismos.

Me vais a crucificar.

Primero respondo al hilo:
No es ese el problema. El problema es que abrir y cerra la BBDD en cada transacción es un precio enorme en tiempo de ejecución y si, como es habitual, abres la BBDD al principio del programa y la dejas abierta durante toda la ejecución, los servidores de MySql de Internet te cortan la conexión sin decirte ni mú. Cuando haces la siguiente consulta a las BBDD o a las propiedades de la Conexión, tu programa se cuelga, pues cree que la conexión sigue abierta y lanza consultas que son ignoradas por el servidor. Al no haber respuesta la única forma de finalizar sería la propiedad Time-Out que tiene la conexión, pero no funciona demasiado bien que digamos.

Ahora a lo que dices:
Me encantaría utilizar esa técnica. Mis programas manejan 3 base de datos coordinadas vía triggers con 146 tablas más una serie de vistas que cargan datos de las tres bases. Cuando al usuario se le muestran datos en un formulario o listado hay datos de todas las Bases de datos con su integridad referencial establecida y demás.
¿Te refieres a que duplique eso en sqlites? ¿O en memoria? Si tienes en cuenta que los usuarios suelen utilizar un mínimo de dos programas simultáneos que atacan a las 3 bases de datos, quedo a la espera de instrucciones para la creación y uso de esa "caché local".

shordi escribió:  

gambafeliz escribió:  

Se que existe actualizaciones e inserciones a tiempo real.

Partiendo de este conocimiento por que no creas o manejas el concepto de actualizaciones e inserciones por lote. Y trabajas con una primera carga de datos en una cache local. De esta manera tan solo cuando vas a cargar la base de datos con novedades al ser por lote, la base de datos de sincronizará adecuadamente, por otra parte así evitas estos problemas que se subsanan con tiempos de lotaje sobre la base de datos.

Es solo una opinión, pero se admite ataques.

Nota: Y soy consciente que aquí solo se maneja la lectura en la pregunta, por lo tanto creo que el concepto de una carga de datos Internet-Cache local es mucho más factible. Se supone que el usuario lo hace al principio y no conecta hasta que de verdad lo necesite. Esto estaría bien solo para casos de poco movimiento de datos y de corto tiempo de uso de la cache local, si hay mucha concurrencia los datos de la cache local serian muy obsoletos. Aunque esto es válido si deseamos saber los datos pero antes de sus confirmación al usuario el programa confirma con un refresco la veracidad de los mismos.

Me vais a crucificar.

Primero respondo al hilo:
No es ese el problema. El problema es que abrir y cerra la BBDD en cada transacción es un precio enorme en tiempo de ejecución y si, como es habitual, abres la BBDD al principio del programa y la dejas abierta durante toda la ejecución, los servidores de MySql de Internet te cortan la conexión sin decirte ni mú. Cuando haces la siguiente consulta a las BBDD o a las propiedades de la Conexión, tu programa se cuelga, pues cree que la conexión sigue abierta y lanza consultas que son ignoradas por el servidor. Al no haber respuesta la única forma de finalizar sería la propiedad Time-Out que tiene la conexión, pero no funciona demasiado bien que digamos.

Ahora a lo que dices:
Me encantaría utilizar esa técnica. Mis programas manejan 3 base de datos coordinadas vía triggers con 146 tablas más una serie de vistas que cargan datos de las tres bases. Cuando al usuario se le muestran datos en un formulario o listado hay datos de todas las Bases de datos con su integridad referencial establecida y demás.
¿Te refieres a que duplique eso en sqlites? ¿O en memoria? Si tienes en cuenta que los usuarios suelen utilizar un mínimo de dos programas simultáneos que atacan a las 3 bases de datos, quedo a la espera de instrucciones para la creación y uso de esa "caché local".

Hola, joven

No se como lo tienes montado pero una solución pasa por poner un Servidor espejo en cada sede para crear la replica y recuperar-enviar los lotes sincronizados de datos.

Solo así será posible asegurar la carga de datos que me describes.

Espero que sirva como aporte a vuestra solución.

Citar:

Espero que sirva como aporte a vuestra solución.

Ese ya no es nuestro problema. Lo fue en un pasado pero para eso montamos un servidor dedicado donde nosotros controlamos todos los time-out. Es un problema para quien maneje bases de datos en servidores "públicos" compartidos donde la capacidad de configuración es limitada.
Estamos esperando para la semana que viene un servidor que nos ha costado un pastón (Más de tres mil euros) que instalaremos en una de nuestras sedes.
Con el esperamos eliminar los servidores de las demás sedes. Ya veremos.

Saludos

Hola

Sigo con el caso. Es que hay algunas incógnitas que despejar para el problema que plantea este hilo.

1. No sabemos si esta programación es local.
2. Si es un servidor compartido en Internet. shordi ha dado mas que suficientes ideal, además son incluso veras mente comprobadas. No se puede pedir mas.
3. Lo que propongo en su manera simplificada, es que replique las tablas (temporales) en local para visualizarlas ya que es lo que necesitas. No hace ningún mal a nadie hacerlo, siempre que la cantidad a crear sea lógicamente factible. Y hasta ahí, ya que solo estamos hablando de lecturas.

Cada problema en una entidad de datos tiene su solución a medida y no hay un estándar para cada entidad, eso es seguro. Por su puesto podemos matar moscas a cañonazos pero eso solo lo haces a base de dinero.

¿no creen?

Ala ya esta

Citar:

pero eso solo lo haces a base de dinero.

Es bueno ser jefe...

Link