Algun sistema para encontrar el orígen del error?

[mcs]

Buenos días,

Estoy finalizando un proyecto, y haciendo pruebas en un ordenador "virgen" (sin entorno de desarrollo Delphi).

Los distintos componentes del proyecto (una aplicación de escritorio, un servicio y una aplicación de "tray-icon") funcionan perfectamente (o casi) en la máquina de desarrollo. Pero en el ordenador de pruebas, ná de ná.

El caso es que me preguntaba si existe alguna forma de encontrar el orígen de estos errores. Por ejemplo, sé que si falta algún componente (BPL) o librería (DLL), la aplicación no arranca y dice qué le falta. Pero claro, cuando suelta la típica ventanita de "Esta aplicación ha provocado un error en Kernel32.dll y tal y cual", ya es más complicado...

Alguna idea/sugerencia? Que hacéis vosotros, cuando os encontrais en una situación similar?

Gracias,

Marc

[mcs]

Me auto-respondo...

Las bases de datos, las malditas bases de datos conectadas en tiempo de diseño... Y cuando se compilan en la versión definitiva se dejan conectadas, con rutas incorrectas y todo falla...

La solución? Poner a false el atributo Active de todos los TIBCConnection...

Saludos,

Marc

[Casimiro Notevi]

Empezado por mcs

[..]Alguna idea/sugerencia? Que hacéis vosotros, cuando os encontrais en una situación similar?
Gracias, Marc

Maldecir al ordenador


También puedes capturar los errores desde código y poner mensajes según va cargando cada form para encontrar al culpable. Luego seguir paso a paso el código para ver qué hace y si no encuentras pistas... instalar el delphi en ese ordenador

[Casimiro Notevi]

Empezado por mcs

Me auto-respondo...
Las bases de datos, las malditas bases de datos conectadas en tiempo de diseño... Y cuando se compilan en la versión definitiva se dejan conectadas, con rutas incorrectas y todo falla...
La solución? Poner a false el atributo Active de todos los TIBCConnection...
Saludos,
Marc

En mi trabajo tenemos una pizarra de esas que pegas notas con chinchetas y en ella una lista de cosas a comprobar antes de compilar. Una de las cosas que pone es "- Comprobar que las bases de datos están cerradas"

Al igual que los pilotos de avión deben hacer por obligación una serie de rutinas aburridas y pesadas antes de iniciar el vuelo... nosotros debemos verificar también una serie de pasos antes de compilar

[MAXIUM]

http://delphiallimite.blogspot.com/2...eurekalog.html

[[Al González]]

Como que ya hacen falta en la VCL propiedades StoreConnected / StoreActive para todos los componentes de acceso a datos.

[look]

Empezado por Casimiro Notevi

En mi trabajo tenemos una pizarra de esas que pegas notas con chinchetas y en ella una lista de cosas a comprobar antes de compilar. Una de las cosas que pone es "- Comprobar que las bases de datos están cerradas"

Al igual que los pilotos de avión deben hacer por obligación una serie de rutinas aburridas y pesadas antes de iniciar el vuelo... nosotros debemos verificar también una serie de pasos antes de compilar

Me ha llamado la atencion lo de los pasos antes de compilar, me llena de mucha curiosidad, yo soy muy novato en esto, compañero seria bueno si pones unos cuantos de esos pasos que comentas, lo agradeceria mucho
saludos.

[roman]

¿Me puede alguien explicar el origen de este problema? No entiendo qué relación hay entre dejar abierta la conexión al compilar y el que las rutas no sean las correctas.

// Saludos

[Casimiro Notevi]

Te lo puedo decir mañana, ahora no estoy en el trabajo, pero son cosas como:
- comprobar que el proyecto se compila con paquetes externos
- comprobar que las bases de datos están cerradas
- no olvidar la .dll del compresor zip
- generar plantillas de bases de datos nuevas (por si lleva cambios)
- anotar versión/revisión en acerca de...

y de memoria no recuerdo más

[Casimiro Notevi]

Empezado por roman

¿Me puede alguien explicar el origen de este problema? No entiendo qué relación hay entre dejar abierta la conexión al compilar y el que las rutas no sean las correctas.

// Saludos

Si tienes un componente basedatos con una base de datos de prueba para programar y la propiedad databasename:=/mnt/datos/mibdpruebas.fdb (por ejemplo) y dejas la propiedad active=true, cuando te llevas el ejecutable a otro ordenador, si no existe esa base de datos en la misma ruta donde estaba en tu ordenador... ¡error!

Debes poner el active=false.

El truco cuando ya está en el cliente y mientras lo solucionas compilando de nuevo es crear esa misma ruta en el equipo del cliente y meter allí cualquier base de datos con el mismo nombre.

[roman]

Empezado por Casimiro Notevi

Si tienes un componente basedatos con una base de datos de prueba para programar y la propiedad databasename:=/mnt/datos/mibdpruebas.fdb y dejas la propiedad active=true, cuando te llevas el ejecutable a otro ordenador, si no existe esa base de datos en la misma ruta donde estaba en tu ordenador... ¡error!

Debes poner el active=false.

Y, ¿cuando ponga el Active := true en ejecución, se cambia solita la ruta?

// Saludos

[Casimiro Notevi]

Creo recordar que alguien hizo unos componentes que solucionaban este problema, ¿puede ser Al González?.
El caso es que FIBplus creo que lo implementó desde hace algún tiempo, pero que yo sepa sigue ese problema en las IBX

[Casimiro Notevi]

Empezado por roman

Y, ¿cuando ponga el Active := true en ejecución, se cambia solita la ruta?

// Saludos

Se supone que en la propiedad databasename habrás puesto una correcta al arrancar el programa (y antes lo pondrás a 'false'). Luego ya depende de cada uno, si lees la ruta en un .ini o como sea. Pero el caso es que los IBX tienen (o tenían, no sé ahora) ese fallo.

[look]

Empezado por Casimiro Notevi

Te lo puedo decir mañana, ahora no estoy en el trabajo, pero son cosas como:
- comprobar que el proyecto se compila con paquetes externos
- comprobar que las bases de datos están cerradas
- no olvidar la .dll del compresor zip
- generar plantillas de bases de datos nuevas (por si lleva cambios)
- anotar versión/revisión en acerca de...

y de memoria no recuerdo más

gracias compañero.... saludos

[[AzidRain]]

Las Zeos en su componente TZConnection tiene una propiedad booleana "Design Connection" que al ponerla a TRUE, hace el trabajo de no conectar la base de datos aunque accidentalmente la hayamos dejado activa en tiempo de diseño.

[roman]

También MyDac cuenta con algo similar; la opción KeepDesignConnected.

// Saludos

[Casimiro Notevi]

La FIBplus tiene:

+ DesignDBOptions
 |_ ddoIsDefaultDatabase 
 |_ ddoStoreConnected     
 |_ ddoNotSavePassword

todas boolean

[[Al González]]

Empezado por Casimiro Notevi

Creo recordar que alguien hizo unos componentes que solucionaban este problema, ¿puede ser Al González?

Sí, con las propiedades StoreConnected y StoreActive.

Empezado por Casimiro Notevi

que yo sepa sigue ese problema en las IBX

No del todo. El componente nativo TIBDatabase ofrece la propiedad AllowStreamedConnected, aunque su funcionamiento es diferente al que yo implementé.

Saludos.

Al González.

[[Lepe]]

hasta cnpacks tiene esa opción, pones una regla que la propiedad Active sea False para los TIBDatabase y te olvidas del tema.

[Casimiro Notevi]

Empezado por Lepe

hasta cnpacks tiene esa opción, pones una regla que la propiedad Active sea False para los TIBDatabase y te olvidas del tema.

Si está active=true, cuando se va a compilar lo pone a false ?

Lepe, ¿dónde están esas reglas?, es que no las encuentro