Ver la Versión Completa : 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
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 Notevi
16-03-2010, 13:21:36
[..]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 Notevi
16-03-2010, 13:25:38
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/2008/04/cazando-errores-con-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. ;)
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
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 Notevi
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 Notevi
16-03-2010, 19:25:39
¿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
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 Notevi
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 Notevi
16-03-2010, 19:31:21
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.
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
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 Notevi
16-03-2010, 20:37:06
La FIBplus tiene:
+ DesignDBOptions
|_ ddoIsDefaultDatabase
|_ ddoStoreConnected
|_ ddoNotSavePassword
todas boolean
Al González
16-03-2010, 21:30:32
Creo recordar que alguien hizo unos componentes que solucionaban este problema, ¿puede ser Al González?
Sí, con las propiedades StoreConnected (http://www.sistemasgh.com/magiasqlconnection.php) y StoreActive (http://www.sistemasgh.com/magiaclientdataset.php).
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. :)
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
17-03-2010, 20:49:11
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.
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 Notevi
18-03-2010, 19:54:52
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 :)
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.