Desconectar TadoConnection por defecto

[Ñ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 Noteví]

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.

[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

[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.