Desconectar TadoConnection por defecto

[josepicd]

Os cuento, tengo un datamodule con un adoConnection y una ConnectionString de pruebas asignada.

El caso es que cuando cargo la aplicacion asigno una nueva ConnectionString y hago un Connected del adoConnection.

Vale, pues a veces antes de compilar algunas veces me olvido de hacer un connected = false dentro del designer y cuando llego a casa del cliente, nada mas ejecutar la aplicacion da un error de que no encuentra la base de datos, porque la propiedad connected = true ha quedado grabada con la connectionstring de pruebas.

No pasa nada porque luego conecto con la buena, pero que muy feo que nada mas arrancar ya de un mensaje de error, hay alguna forma automatica de hacer que el connected siempre este a false al compilar o antes de arrancar la aplicacion, lo he puesto en el datamodulecreate pero los valores los carga antes.

gracias a todos

[Neftali [Germán.Estévez]]

En ejecución deberías poder capturar ese error sin problemas, si redefines el método Create del formulario.

Código Delphi [-]
private
  constructor Create(AOwner: TComponent); override;
  ...

No lo he probado, pero debería funcionar.

[Ñuño Martínez]

Empezado por Neftali

En ejecución deberías poder capturar ese error sin problemas, si redefines el método Create del formulario.

Código Delphi [-]
private
  constructor Create(AOwner: TComponent); override;
  ...

No lo he probado, pero debería funcionar.

No estoy tan seguro. Ten en cuenta que lo primero que hay que hacer en el constructor es llamar al constructor heredado para reservar la memoria. Esto hace (si no recuerdo mal, y en este caso) que también se creen los componentes y se establezcan los valores de sus propiedades.

Lo que sí podría intentarse es capturar la excepción. Algo así como:

Código Delphi [-]
CONSTRUCTOR TForm.Create (AOwner: TComponent);
BEGIN
  TRY
     INHERITED Create (AOwner)
  EXCEPT
    ON Error: Exception DO
    BEGIN
       { ¿ignorarlo? }
    END
  END
END;

Lo ideal aquí sería usar una clase de excepción del ADO Connection para discriminar.

[Neftali [Germán.Estévez]]

Empezado por Ñuño Martínez

No estoy tan seguro.
Ten en cuenta que lo primero que hay que hacer en el constructor es llamar al constructor heredado para reservar la memoria. Esto hace (si no recuerdo mal, y en este caso) que también se creen los componentes y se establezcan los valores de sus propiedades.

Es correcto, por eso creo que funciona.

Si redefines el Create de la Clase (TForm), En el "redefinido" podrás capturar la excepción que se levante desde el de la clase TForm. Realmente Se hace el Create y luego el Loaded (que carga los valores desde el DFM). Si el inherited en la clase redefinida (tal y como has puesto tú) está dentro del try..except, podrás capturar la excepción sin problemas.

Empezado por Ñuño Martínez

Lo que sí podría intentarse es capturar la excepción. Algo así como:

Eso es lo que quería decir con esta frase:

Empezado por Neftali

En ejecución deberías poder capturar ese error sin problemas, si redefines el método Create del formulario.

[Casimiro Notevi]

Hace tiempo, años, hablamos sobre esto y diversos componentes de conexión a BD que controlaban ese problema. A ver si lo encuentro...

[[AgustinOrtu]]

Pero no es lo mas logico que en tiempo de diseño la propiedad Connected este siempre a False, y luego se conecte en el momento mas apropiado (= un evento)?

En mi caso particular el connection string lo defino tambien en tiempo de ejecucion, en el evento OnBeforeConnect del Connection. Luego en el OnCreate del DataModule realizo el Conneciton.Open

[[nlsgarcia]]

AgustinOrtu,

Empezado por AgustinOrtu

...no es lo mas lógico que en tiempo de diseño la propiedad Connected este siempre a False, y luego se conecte en el momento mas apropiado...

Nelson.

[ecfisa]

Hola josepicd

Empezado por josepicd

..., lo he puesto en el datamodulecreate pero los valores los carga antes.

¿ Y por que carga los valores de un TADOConnection residente en un TDataModule antes de que este haya sido creado ?

¿ En que momento los carga ?, ¿ podrías explicar mas detalladamente ese punto ?

Saludos

[Neftali [Germán.Estévez]]

Empezado por AgustinOrtu

Pero no es lo mas logico que en tiempo de diseño la propiedad Connected este siempre a False, y luego se conecte en el momento mas apropiado (= un evento)?

Por lo que comenta, el problema es que se le olvida desactivarlo a veces.
Es lógico que la conexión esté abierta en diseño, pues algunas operaciones con tablas/querys y grids, requieren que esté así, por ejemplo cuando ase añaden campos.

Si al generar el EXE no recueradas desactivarla, la conexión queda abierta.

[[AgustinOrtu]]

Empezado por Neftali

Por lo que comenta, el problema es que se le olvida desactivarlo a veces.
Es lógico que la conexión esté abierta en diseño, pues algunas operaciones con tablas/querys y grids, requieren que esté así, por ejemplo cuando ase añaden campos.

Si al generar el EXE no recueradas desactivarla, la conexión queda abierta.

Buenas German, pero aun asi y todo, si uno provee la ConnectionString en el BeforeConnect no deberia dispararse el evento y asignar una conexion correcta?

Sino la otra posibilidad que se me ocurre es tener otro archivo .dfm de DataModule en cuestion, y utilizar directivas de compilacion para indicar que cuando compile en release utilice el .dfm sin la conexion

Otra forma pero que requiere mas "trabajo" es usar git o algun control de versiones. Siendo mas o menos cuidadoso estos deslices los encontras facilmente al momento de realizar los commit

[ecfisa]

Hola.

La verdad, es que la situación sigue sin quedarme clara...

...lo he puesto en el datamodulecreate pero los valores los carga antes.

Como yo lo veo, cuando intente cargar los valores (mediante un un TADOLoqueSea) antes de estar creado el TDataModule, y por lo tanto el TADOConnection que allí está radicado, obtendríamos un lindo mensaje de "Missing connection or ConnectionString". No tiene sentido hablar de que esté o no conectado cuando aún no ha sido creado.

hay alguna forma automatica de hacer que el connected siempre este a false al compilar o antes de arrancar la aplicacion

Si, una simple comprobación de su propiedad Connected en la creación del TDataModule, nos dá la posibilidad de accionar:

Código Delphi [-]
procedure TDataModule1.DataModuleCreate(Sender: TObject);
begin
  if ADOConnection1.Connected then // ¿ Me quedó abierto ?
    ADOConnection1.Close;          // entonces lo cierro

  // Hago lo que corresponda y continúo...
end

Claro está, que si el TDataModule esta en auto-create forms, tendrá que tener mayor precedencia que el módulo que intenta referenciarlo. Y, si se crea en tiempo de ejecución, la llamada a la creación también deberá ser previa al uso del mismo.

Por favor corríjanme si estoy malentendiendo el problema.

Saludos

[[AgustinOrtu]]

Daniel creo que lo que pasa es algo del estilo, en tiempo de diseño tengo la connection string seteada a que apunte a mi sql server/archivo access/etc. Seguro la seteo con el asistente de "build conneciton string"

Entonces si dejas el connected a true, tenes en el .dfm algo asi

Código Delphi [-]
Connection = TADOConnection1
  ConnectionString = '\Pepe.mdb'
  Connected = True

Al cargar las propiedades persistentes, en la pc de el no hay problema. Pero en otra pc anda a saber donde esta "pepe.mdb"

Me parece que va por ese lado la cosa

[josepicd]

Correcto AgustinOrtu, exactamente ese es el problema

[Casimiro Notevi]

No encontré el hilo donde hablamos sobre esto, recuerdo que había una solución muy elegante para resolver el problema. Haré otra búsqueda a ver...

[josepicd]

He encontrado dos soluciones al problema, las expongo para ver que opinais.

1.- Puesto que utilizo una base de datos fisica (Access) compruebo que exista.

Código Delphi [-]
procedure TdmMatTaller.adoConnectionWillConnect(Connection: TADOConnection;
  var ConnectionString, UserID, Password: WideString;
  var ConnectOptions: TConnectOption; var EventStatus: TEventStatus);
var cs : WideString;
begin
  cs := Copy(ConnectionString, Pos( WideString('Data Source='), ConnectionString)+12, length(ConnectionString));
  cs := Copy( cs, 0, Pos(';', cs)-1);
  if not fileexists( cs) then abort;
end;

2. Esta segunda opcion es la que voy a implementar ya que me parece mas elegante y no depende de un fichero o ruta.

Código Delphi [-]
TdmMatTaller = class(TDataModule)
  private
    _lcreatingdatamodule : Boolean;
  public
    constructor Create(AOwner: TComponent); override;
  end;


constructor TdmMatTaller.Create(AOwner: TComponent);
begin
  _lcreatingdatamodule := true;
  inherited create( AOwner);
  _lcreatingdatamodule := false;
end;


procedure TdmMatTaller.adoConnectionBeforeConnect(Sender: TObject);
begin
  if _lcreatingdatamodule then abort;
end;

[Neftali [Germán.Estévez]]

Empezado por AgustinOrtu

...si uno provee la ConnectionString en el BeforeConnect no deberia dispararse el evento y asignar una conexion correcta?

Correcto.
Esta opción también debería funcionar y también me parece buena.

[[Al González]]

Empezado por Casimiro Notevi

[...] recuerdo que había una solución muy elegante para resolver el problema.

Hola amigos.

Creo que Casimiro se refiere a este "antiguo" hilo, escrito antes de que los componentes MagiaData fueran integrados a GH Freebrary.

Si alguien se interesa en echar un vistazo al código fuente del repositorio, puede ver lo sencillo que es implementar una propiedad llamada StoreConnected o StoreActive para los componentes de conexión a base de datos, agregando la directiva Stored a las propiedades Connected o Active. En la versión para Delphi 7, estos ejemplos aparecen en las unidades GHFSQLConnection.pas, GHFSQLQuery.pas y GHFClientDataSet.pas.

En específico, del componente TghSQLConnection extraigo la parte que resuelve el problema:

Código Delphi [-]
    { SQL Connection class }
    TghSQLConnection = Class (TSQLConnection)
      Protected
        { Fields }
        ...
        FStoreConnected :Boolean;
      Published
        { Properties }
        ...
        Property Connected Stored FStoreConnected;
        Property StoreConnected :Boolean Read FStoreConnected
          Write FStoreConnected Default False;
    End;

No es necesario escribir ningún método, solo derivar el componente con esas declaraciones, instalarlo en algún paquete y queda listo para usarse. La clase padre puede ser TADOConnection o cualquier otra a la que aplique.

Recojo algunos comentarios que en su momento surgieron cuando planteaba esta característica:

Empezado por roman

Lo que me parece genial es el la propiedad StoreActive. ¡Cuántos dolores de cabeza no da el dejar esta propiedad activa durante el diseño! Creo que ninguna componente derivada de DataSet debió dejar siquiera la opción de poder almacenar esto en el dfm.

Empezado por Marc

Vaya, solo por esta propiedad "StoreActive" ya valdría la pena hacer el cambio
Voy a echarle un vistazo [...]

Empezado por Al González

Cuando tienes StoreActive en False (el valor predeterminado), el valor de la propiedad Active no se guardará en el archivo .dfm, el archivo donde se almacena todo lo que estableces en tiempo de diseño —generalmente usando el inspector de objetos—. Esto quiere decir que si abres un conjunto de datos en tiempo de diseño para facilitar la labor de delinear un DBGrid, por ejemplo, enseguida puedes compilar el programa y al correrlo no abrirá automáticamente ese conjunto de datos; la tendencia hoy en día (y lo que señalan los cánones) es que el programa abra los conjuntos de datos por orden explícita, sólo en el momento en que se requieran, para ahorrar recursos y operar con una velocidad óptima.

Así mismo [sic], cuando vuelvas a abrir el proyecto en Delphi, los módulos de datos no demorarán en cargarse, ya que no tratarán de abrir los conjuntos de datos que hayas dejado con las propiedades Active en True y StoreActive en False. En pocas palabras, StoreActive concilia la tendencia de conjuntos de datos cerrados con la necesidad de abrirlos para diseñar.

Espero sirva mi aportación en este caso.

Un cordial saludo.

Al.

[ecfisa]

Hola Agustín

Empezado por AgustinOrtu

Daniel creo que lo que pasa es algo del estilo, en tiempo de diseño tengo la connection string seteada a que apunte a mi sql server/archivo access/etc. Seguro la seteo con el asistente de "build conneciton string"

Entonces si dejas el connected a true, tenes en el .dfm algo asi

Código Delphi [-]
Connection = TADOConnection1
  ConnectionString = '\Pepe.mdb'
  Connected = True

Al cargar las propiedades persistentes, en la pc de el no hay problema. Pero en otra pc anda a saber donde esta "pepe.mdb"

Me parece que va por ese lado la cosa

Si, lo que comentas es correcto y entiendo ese punto. Lo que no me queda claro como es que logra usar la conexión antes de estar creada.

De todos modos y aunque no soy un experto en ADO, se puede asignar otra cadena de conexión en el evento OnCreate del DataModule o en el evento BeforeConnect del propio componente como bién apuntaste con anterioridad.

Saludos

Pd: Alberto, luego voy a revisar con detenimiento tu mensaje que seguramente me resultará muy interesante e instructivo.