Foros Club Delphi - Algun sistema para encontrar el orígen del error?

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Varios (https://www.clubdelphi.com/foros/forumdisplay.php?f=11)

- - Algun sistema para encontrar el orígen del error? (https://www.clubdelphi.com/foros/showthread.php?t=66864)

mcs	16-03-2010 12:58:59

Algun sistema para encontrar el orígen del error?

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	16-03-2010 13:18:09

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... :mad:

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

Saludos,

Marc

Casimiro Noteví

16-03-2010 13:21:36

Cita:

Empezado por mcs (Mensaje 357081)

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

Maldecir al ordenador :D

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 :D

Casimiro Noteví

16-03-2010 13:25:38

Cita:

Empezado por mcs (Mensaje 357083)

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... :mad:
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

16-03-2010 14:48:20

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

Al González

16-03-2010 18:59:16

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

look	16-03-2010 19:05:22

Cita:

Empezado por Casimiro Notevi (Mensaje 357086)

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

16-03-2010 19:16:46

¿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 Noteví

16-03-2010 19:22:15

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 Noteví

16-03-2010 19:25:39

Cita:

Empezado por roman (Mensaje 357141)

¿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

16-03-2010 19:27:43

Cita:

Empezado por Casimiro Notevi (Mensaje 357146)

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? :rolleyes:

// Saludos

Casimiro Noteví

16-03-2010 19:29:13

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 Noteví

16-03-2010 19:31:21

Cita:

Empezado por roman (Mensaje 357148)

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

// 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	16-03-2010 19:33:59

Cita:

Empezado por Casimiro Notevi (Mensaje 357144)

gracias compañero.... saludos

AzidRain

16-03-2010 19:43:58

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

16-03-2010 19:54:28

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

// Saludos

Casimiro Noteví

16-03-2010 20:37:06

La FIBplus tiene:

Código:

+ DesignDBOptions

 |_ ddoIsDefaultDatabase 

 |_ ddoStoreConnected     

 |_ ddoNotSavePassword

todas boolean

Al González

16-03-2010 21:30:32

Cita:

Empezado por Casimiro Notevi (Mensaje 357150)

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

Sí, con las propiedades StoreConnected y StoreActive.

Cita:

Empezado por Casimiro Notevi (Mensaje 357150)

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	17-03-2010 20:21:47

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

Casimiro Noteví

17-03-2010 20:49:11

Cita:

Empezado por Lepe (Mensaje 357318)

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 :o

mamcx

18-03-2010 18:18:24

Lo que necesitan es un sistema de Build automatizados.

Que es? Es hacer un programa con TODOS los pasos necesarios para liberar una version de entrega al usuario/tester.

http://en.wikipedia.org/wiki/Build_automation.

Yo utilizo http://www.finalbuilder.com/.

Por ejemplo, esto es lo que hago para armar a www.bestsellerapp.com:

- Descargo de internet las librerias (versiones exactas) de python/dependencias si no estan ya descargadas en el equipo
- Descargo del repositorio de Subversion la ultimo version estable
- Limpio los .ini de configuraciones
- Compilo el proyecto
- Ejecuto los test de DUNit
- Recolecto todos los archivos que necesita el instalador
- Genera dinamicamente el archivo XML que usa el generador de instaladores multiplataforma http://bitrock.com/
- Valido que el XML sea correcto
- Invoco a bitrock y genero el instalador
- Conecto al servidor www.elmalabarista.com por SFTP, elimino el instalador viejo y subo el nuevo
- Envio un correo informando del nuevo instalador

Y eso, que voy en la *mitad* del proceso. Estoy armando la parte de conectarse4 al mac, compilar con Freepascal/lazarus la version en OSX, compilar con XCode la version de iPhone, generar el archivo de firma digital, subir al servidor de apple y publicar.

Resutado?

A cualquier dia, en cualquie momento, tengo 100% de certeza que puedo entregar una version estable del proyecto, con mas de 100 pruebas automatizadas, de forma repetible y sin meter archivos que no son o que me falten, sin versiones de depuracion, configuraciones erroneas y todo eso.

Lepe	18-03-2010 18:50:14

Cita:

Empezado por Casimiro Notevi (Mensaje 357321)

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 :o

Ni yo tampoco ;D

Es que las puse cuando instalé delphi y ya ni me acuerdo.

Cnpacks -> options -> paleta wizards settings -> Name property corrector -> boton settings -> Add ... y ahora sí, estableces la regla para el TIBDatabase, etc...

Casimiro Noteví

18-03-2010 19:54:52

Cita:

Empezado por Lepe (Mensaje 357460)

Ni yo tampoco ;D
Es que las puse cuando instalé delphi y ya ni me acuerdo.
Cnpacks -> options -> paleta wizards settings -> Name property corrector -> boton settings -> Add ... y ahora sí, estableces la regla para el TIBDatabase, etc...

Es que cnpacks tiene tantas cosas que cada día descubres algo nuevo :)

La franja horaria es GMT +2. Ahora son las 08:35:03.