Ir al contenido


Foto

ADOConnection - forma óptima de usarlo

ADOConnection

  • Por favor identifícate para responder
2 respuestas en este tema

#1 jlr733

jlr733

    Newbie

  • Miembros
  • Pip
  • 1 mensajes

Escrito 13 julio 2017 - 02:51

Hola
En primer lugar gracias a todos por los aportes que hacen a la comuinidad de desarrolladores.
 
Quiero hacerles una consulta por un problema que se me presenta, desarrollando una aplicación Windows con Delphi 10.1 Berlin
 
Mi consulta es la siguiente:
¿Alguien puede explicarme como es la forma de trabajo óptima para hacer una conexión a la base de datos SQL Server con ADOConnection?
 
Conozco dos maneras de hacerlo: ¿Cual es la apropiada?
 
En un DataModule coloco un componente TADOConnection, lo configuro  y luego desde los distintos formularios uso esa conexión para ejecutar consultas a la base de datos.
 
Forma 1
Cuando la aplicación se inicia, en el evento OnCreate del DataModule activo la conexión ADOConnection1.Connected := true;
 
Esta conexión permanece abierta hasta que la aplicación se termina. Justo antes de cerrar la aplicación hago ADOConnection.Connected := false;
 
Forma 2:
Cada vez que hago una consulta a la base de datos, activo la conexión
ADOConnection1.Connected := true;
La uso:
ADOQuery1.Conection :=
ADOQuery1.Active := false;
ADOQuery1.SQL.Text := 'Select * from tabla';
ADOQuery1.Active := true;
Luego de usarla, cierro la conexión.
ADOConnection1.Connected := false;
 
Mi aplicación usa muchas consultas sql, por eso siempre opté por la forma 1, pero tengo un problema ajeno a la aplicación. 
Se me presenta el problema que por motivos ajenos a la aplicación, se producen micro cortes en la conexión al servidor. Esto hace que algunos componentes y variables de la aplicación pierdan valores y esto bloquea la aplicación. Para solucionarlo debo reconectar el ADOConnection1 y ejecutar nuevamente las consultas involucradas.
 
Gracias por las ideas que puedan brindarme. Las valoraré muchísimo.
 

  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 13 julio 2017 - 05:00

Hola jlr733, veo que este es tu primer mensaje en el foro a pesar de que llevas un año. Permítime darte la bienvenida tardía, ¡Gracias por confiar en DA para evacuar tus dudas!

 

Respecto a tu duda, no es que exista una única y óptima forma de usarlo. Cada cosa tiene sus pros y contras. En ocasiones se deberá de hacerlo por la forma 1 y tener un diseño "Optimista", en ciertas situaciones se deberá optar por la número 2 y ¡hasta es válido mezclar ambas!

 

Hay quienes no les gustan los data modules, y disponen de los controles en forms, y otros que prefieren usar el datamodule.

Formas de establecer la conexión y diseñar las aplicaciones hay para todos los gustos. Todas son igualmente válidas. Como suele decir el compañero Egostar, y cito la canción... "depende". "Según como se mire todo depende..." Para todo habrás pros y contras... ninguna será superadora.

 

Si experimentas micros cortes en lo primero que pensaría es que hay algún problema en la red y no tanto en el software. Si se trata de conexiones C/S de varios equipos deberías revisar los cables, las placas de red. Para empezar...

 

Aún así y todo cuando la red está perfecta, siempre hay que tener medidas preventivas para restablecer la conexión. Asi que no está mal diseñar el software de forma que si se detecta que se ha perdido la conexión proceder a reintentarlo en x segundos. Y si tras N intentos no se ha podido alertar al usuario para que tome cartas en el asunto. Importantísimo que le añadas un log a tu aplicación para registrar esto y otras tareas de interés.

 

Se que quizá no te estoy dando una respuesta bien concreta y precisa. Pero es que en gustos de diseñar SW se rompen moldes.

 

Saludos,


  • 3

#3 Koalasoft

Koalasoft

    Advanced Member

  • Miembros
  • PipPipPip
  • 142 mensajes
  • LocationMéxico

Escrito 04 agosto 2017 - 11:52


 en gustos de diseñar SW se rompen moldes.

 

Efectivamente estimado !! ..  :ap:


  • 0




IP.Board spam blocked by CleanTalk.