Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Firebird e Interbase (https://www.clubdelphi.com/foros/forumdisplay.php?f=19)
-   -   Tendría que decir adiós? (https://www.clubdelphi.com/foros/showthread.php?t=87669)

GustavoCruz 09-02-2015 22:31:54

Tendría que decir adiós?
 
Hola amigos, me he topado con un inconveniente un tanto triste...
Tengo una base de datos en Firebird 2.5.3; es un problema de Conexión, Desconexión y Reconexión. Sólo llego a la segunda parte.
Buscando hallé este hilo, y creí solucionados mis problemas pero resulta fibplus se reusa a conectarse con firebird o quizas firebird se reusa permitir la conexión, he buscado por internet y nada.

Gracias por vuestro tiempo


GustavoCruz

GustavoCruz 09-02-2015 22:32:24

Por dónde andará mi amigo Jonny???

Casimiro Notevi 09-02-2015 23:30:24

Para descartar problemas de red, conecta desde el equipo local donde está la base de datos.
Cuéntanos el resultado.

Casimiro Notevi 09-02-2015 23:31:36

Por cierto, no olvides poner títulos descriptivos a tus preguntas, ¿qué es eso de "tendría que decir adiós"? :confused:

GustavoCruz 10-02-2015 00:15:41

Hola Casimiro, es que ando un poco triste y no sabía ni cómo titular el hilo... :(
ya intente lo que me conmentaste y me sigue apareciendo el mismo error... no permite la conexion si llevo una consulta en ejecución...

Me explico

Resulta que me llevo el aplicativo para otro equipo y hago desconectarlo, pruebo la Reconexión y todo bien, pero cuando estoy realizando una consulta, y desconecto el equipo, al momento de hacer la reconexión, me muestra una exception que indica que existe una consulta preparada... y es ahí donde muero.

este es el código que tengo para la reconexión
Código Delphi [-]
procedure TfDatos.RecDB;
var
  Handle: Integer;
  Buffer: array [0..7] of Cardinal;
begin
  Handle := IcmpCreateFile;
  Coneccion.CloseDataSets;
  Coneccion.Close;
  if Handle = -1 then
    Exit; // Error interno
  if not LongBool(IcmpSendEcho(Handle, inet_addr('192.168.1.108'), nil, 0,
  nil, @Buffer, SizeOf(Buffer), 1000)) then
    begin
      CloseHandle(Handle);
      Coneccion.Connected:= False;
      MsgBox(Titulo, 'Imposible realizar la conexión con la BD', mtError,
      ['Aceptar'], 0);
    end
  else
    begin
      Coneccion.Connected:= False;
      Coneccion.Connected:= True;
      Coneccion.Open();
      MsgBox(Titulo, 'Conexión realizada correctamente', mtInformation,
      ['Aceptar'], 0);
    end;
end;

He llegado incluso a pensar en pasarme a otro motor de base de datos. Con tal de superar este problema.


Gracia por vuestro tiempo

GustavoCruz

duilioisola 10-02-2015 09:58:05

¿Porqué le hechas la culpa al motor de base de datos cuando el problema está seguramente en el código?

Si te están diciendo que "hay una consulta preparada", deberías cerrar las consultas antes de proceder.
  • De todos modos, sería bueno que pusieras el mensaje de error exacto (sin resumir, sin traducir, completo) para que alguien pueda ayudarte.
  • Además sería conveniente que indicaras en qué línea del código que muestras está lanzando la excepción.
  • En tu código veo que utilizas una variable "Handle". El formulario también tiene una propiedad "TForm.Handle", por lo que podría ser que el compilador esté haciendo cosas raras al optimizar y eso genere errores.
  • Creo que hacer "Conección.Connected := True" es lo mismo que "Coneccion.Open", con lo que estarías abriendo algo abierto...
  • Deberías ver si hay código dentro de algún método que se ejecute al conectar la "Coneccion". Quizás este esté dando el error.
Y finalmente, para que no me lloren mas los ojos: Conexión, con X, por favor!
rae.es + conexión

Casimiro Notevi 10-02-2015 10:04:22

Cita:

Empezado por duilioisola (Mensaje 488603)
¿Por qué le echas la culpa al motor de base de datos cuando el problema está seguramente en el código?

Exacto.

Además, no entiendo eso de desconectar y conectar, ¿para qué lo haces?

GustavoCruz 11-02-2015 21:10:37

1 Archivos Adjunto(s)
Hola, disculpen por la tardanza...

Esta es una imagen de lo que sucede.

La cuestión de la conexión y desconexión, es porque tengo esos problemas en el lugar donde actualmente estoy implementando, y no está demás poder tener una solución a tal eventualidad; si llegare a ser contratado en otra institución.

Nota: efectivamente así se escribe CONEXIÓN, pero no veo por qué el nombre de un componente pueda causar dolor en los ojos...

Gracias

GustavoCruz

Casimiro Notevi 11-02-2015 23:22:35

Gustavo, ¿has hecho la prueba que te comenté?
Trabajas sin la red local o wifi o lo que tengan ahí. Te vas al ordenador donde está la base de datos, desconectas el cable de red, si quieres, y trabajas en local. Trabajas, usas el programa. No se te puede desconectar porque no está conectado.
Así que si falla entonces no es problema de la red. Es un error de programación.
Pero lo primero es descartar que realmente sea un problema de red.

GustavoCruz 12-02-2015 17:59:37

Hola Casimiro eso ya lo probé, y me muestra "Conexión realizada correctamente"...
Como les comenté, en ocasiones me realiza la conexión y en otras no, eso depende de si en el momento de que esté desconectado intente realizar una consulta, si lo hago entonces ya no me puedo volver a conectar, pero si me percato en (suponiendo que sea el usuario final) el momento que estoy sin red entonces puedo hacer la reconexión... eso es un poco complicado porque los médico y las enfermeras no van a estar pendiente que esté o no esté el equipo conectado a la red.

Gracias por tu tiempo

GustavoCruz

GustavoCruz 15-02-2015 17:35:28

Bueno...

Gracias a todos por sus sugerencias, pero tristemente le tendré que decir adiós a Firebird... por lo menos a la versión 2.x


GustavoCruz

Casimiro Notevi 15-02-2015 19:18:29

Cita:

Empezado por GustavoCruz (Mensaje 488830)
Bueno... Gracias a todos por sus sugerencias, pero tristemente le tendré que decir adiós a Firebird... por lo menos a la versión 2.x

¿Qué tiene que ver la base de datos con tu problema?
Si no ves bien, ¿cambias de zapatos?

GustavoCruz 15-02-2015 20:38:30

Yo también me siento decepcionado, sobre todo porque con firebird aprendía a hacer UDF, hice una que me convierte los números a letras utilizando el código que tiene el componente de ATexto creado por Antoni Aloy López, una que me calcula la edad utilizando el truco de mamu
De firebird estoy muy contento porque apredí mucho...
Pero este problema que me resulta de las desconexiones fortuitas es grave, y no me puedo dar el lujo de decirle a un Médico de una Unidad de Cuidados Intensivos que cierre y vuelva a abrir el programa porque éste se desconectó de la base de datos.

Es sólo ese detalle que me obliga a buscar otro motor de base de datos.
Me gustaría que entendieran mi posición. Porque no es fácil tener que migrar una base de datos de mas de 5 años...:(

Pero si aún me pueden ayudar con esto le agradezco

GustavoCruz

Casimiro Notevi 15-02-2015 21:11:58

Vamos a ver, la cosa es fácil, se ha explicado antes:

Primero se hacen comprobaciones para saber si la red local funciona bien. Si tiene problemas entonces hay que arreglar la red local.
Con red local me refiero a equipos, tarjetas, cables, router, etc.

Si la red local funciona perfectamente, entonces hay que verificar tu programa. No hay más. Punto. Se acabó. Fin.

Querer culpar a la base de datos es ilógico, incoherente, disparatado, inconsecuente, absurdo, irracional, ridículo, inverosímil.

GustavoCruz 15-02-2015 21:40:29

Gracias Casimiro

GustavoCruz 15-02-2015 21:51:44

Cita:

Empezado por Casimiro Notevi (Mensaje 488836)
Vamos a ver, la cosa es fácil, se ha explicado antes:

Primero se hacen comprobaciones para saber si la red local funciona bien. Si tiene problemas entonces hay que arreglar la red local.
Con red local me refiero a equipos, tarjetas, cables, router, etc.

Si la red local funciona perfectamente, entonces hay que verificar tu programa. No hay más. Punto. Se acabó. Fin.

Querer culpar a la base de datos es ilógico, incoherente, disparatado, inconsecuente, absurdo, irracional, ridículo, inverosímil.

A ver casimiro... el programa funciona bien.
Simplemente que cuando hay un fallo en la conexión con el servidor. EL MUNDO NO TIENE POR QUÉ ACABARSE. conque se haga esto es suficiente
Código Delphi [-]
Coneccion.Connected := False;
Coneccion.Connected := True
pero resulta que no es así.
Esa instrucción me debía cerrar cualquier consulta abierta y me debería permitir reconectarme la base de datos.
Crees que simplemente quiero culpar a Firebird?
Te invito a que hagas la prueba, y perdóname, pero no me vengas con teorías. Porque la teoria dice que esto es suficiente
Código Delphi [-]
Coneccion.Connected := False;
Coneccion.Connected := True

GustavoCruz

RONPABLO 16-02-2015 08:11:18

Cita:

Empezado por GustavoCruz (Mensaje 488838)
A ver casimiro... el programa funciona bien.
Simplemente que cuando hay un fallo en la conexión con el servidor. EL MUNDO NO TIENE POR QUÉ ACABARSE. conque se haga esto es suficiente
Código Delphi [-]Coneccion.Connected := False; Coneccion.Connected := True

pero resulta que no es así.
Esa instrucción me debía cerrar cualquier consulta abierta y me debería permitir reconectarme la base de datos.
Crees que simplemente quiero culpar a Firebird?
Te invito a que hagas la prueba, y perdóname, pero no me vengas con teorías. Porque la teoria dice que esto es suficiente Código Delphi [-]Coneccion.Connected := False; Coneccion.Connected := True


GustavoCruz

Lo que ocurre a mi me paso en algún momento y no lo pude solucionar con los IBX, osea, si estaba trabajando y por algún motivo la conexión a la red se perdía, me tocaba finalizar la aplicación a la fuerza, con el tiempo me di cuenta que ese problema es de la forma como se conecta a la base de datos como si fuera una aplicación local que estaba todo el tiempo conectada, para solucionarlo debería cambiar de forma de trabajar la capa de datos y no permanecer conectado todo el tiempo, solo establecer la conexión hacer un query almacenarlo en un clientDataSet y cerrar nuevamente la conexión o al hacer algún update, un insert o un delete tener todo los pasos listos y cuando toda la información este lista conectar, mandar la sentencia SQL y desconectar nuevamente, para trabajar puede usar los clientDataSet en vez de usar un DataSet o un IBDataSet

RONPABLO 16-02-2015 08:15:17

Cita:

Empezado por RONPABLO (Mensaje 488848)
Lo que ocurre a mi me paso en algún momento y no lo pude solucionar con los IBX, osea, si estaba trabajando y por algún motivo la conexión a la red se perdía, me tocaba finalizar la aplicación a la fuerza, con el tiempo me di cuenta que ese problema es de la forma como se conecta a la base de datos como si fuera una aplicación local que estaba todo el tiempo conectada, para solucionarlo debería cambiar de forma de trabajar la capa de datos y no permanecer conectado todo el tiempo, solo establecer la conexión hacer un query almacenarlo en un clientDataSet y cerrar nuevamente la conexión o al hacer algún update, un insert o un delete tener todo los pasos listos y cuando toda la información este lista conectar, mandar la sentencia SQL y desconectar nuevamente, para trabajar puede usar los clientDataSet en vez de usar un DataSet o un IBDataSet


También usar una conexión para consultas o para cambios y una diferente si usas los eventos de firebird

Casimiro Notevi 16-02-2015 09:55:43

Pues eso, que no tiene nada que ver con la base de datos.

GustavoCruz 23-02-2015 00:51:29

Hola amigos del foro, ya había dado por terminado este asunto de las pérdidas fortuitas de comunicación con la base de datos, sea cual sea la causa.

Descargué los componentes Unidac. Y para mi sorpresa funciona todo bien, nisiquiera tengo que indicarle al programa que se vuelva a conectar, pues los componentes lo hacen solos.

Sigo con Firebird :D:D

Gracias por vuestro tiempo


Gustavo Cruz


La franja horaria es GMT +2. Ahora son las 08:15:55.

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