dbX depende de BDE ?

[rolandoj]

Hola,

Tratando de desinstalar los componentes BDE (vease el hilo http://www.clubdelphi.com/foros/showthread.php?t=53057) he encontrado que el paquete dbX100 depende del paquete BDERTL100.BPL.

Dado que dbX es el prefijo de dbExpress, debo suponer que dbX100 forma parte de dbExpress. dbX100.bpl es el paquete "CodeGear SQL Explorer UI Package".

Surgen varias preguntas :

Significa esto que dbX depende de BDE ?. Como es posible si se supone que dbX reemplaza a BDE ?

Es acaso algún error y aunque lo listan en las dependencias realmente dbX100 no usa BDE ?

O es acaso que dbX100 no es realmente parte de dbX y lo del prefijo es casualidad ?

Por cierto, alguién conoce algún método para averiguar que unidades integran un paquete Delphi, del cual no tengamos fuentes ?

[Al González]

¡Hola Rolando!

Las dependencias entre paquetes no siempre son "a conciencia", suelen establecerse automáticamente, por una necesidad intrínseca del entorno de Delphi, cada vez que se compila un paquete que usa unidades que también son utilizadas por otro paquete que ya está instalado.

Si un paquete de componentes de datos usa la unidad DB.pas (algo que es muy común), un segundo paquete de componentes de datos que use la misma unidad encadenará una dependencia al primero (no puede cada uno tener su propia "DB").

En muchos casos es posible recompilar los paquetes para reorganizar o romper estas dependencias. Tengo dudas de por qué Borland no incluye muchos de los paquetes fuentes, pero en todo caso los archivos de código fuente de dichos componentes sí están disponibles y con ellos pueden crearse nuevamente los/otros paquetes para reinstalarlos, cuidando uno mismo las dependencias que se crean.

Espero haber ayudado en algo.

Al González.

[brakaman]

[quote=rolandoj;264716]Hola,

Tratando de desinstalar los componentes BDE (vease el hilo http://www.clubdelphi.com/foros/showthread.php?t=53057) he encontrado que el paquete dbX100 depende del paquete BDERTL100.BPL.

Dado que dbX es el prefijo de dbExpress, debo suponer que dbX100 forma parte de dbExpress. dbX100.bpl es el paquete "CodeGear SQL Explorer UI Package".

Hola amigo:

Perdona que me entrometa sin darte una solucion directa, pero creo que estas afrontando mal el problema, ya lei que debes desinstalar los BDE porque quieres instalar unos componentes con el mismo nombre, ¿no te parece una barbaridad?

sinceramente creo que lo normal seria renombrar el nombre de los nuevos componentes a instalar, si no eres tu el autor el que lo ha hecho ha pecado de inmodestia al pretender hacer unos componentes con un nombre que ya existe, ¿tan dificil es renombrarlos de la forma TxxTable, TxxDatasource etc.?

Yo creo que la solucion esta ahi y no en intentar quitar todo tipo de rastro del BDE en Delphi?

Solo es una opinion. :D

[rolandoj]

¡Hola Rolando!

Las dependencias entre paquetes no siempre son "a conciencia", suelen establecerse automáticamente, por una necesidad intrínseca del entorno de Delphi, cada vez que se compila un paquete que usa unidades que también son utilizadas por otro paquete que ya está instalado.

Si un paquete de componentes de datos usa la unidad DB.pas (algo que es muy común), un segundo paquete de componentes de datos que use la misma unidad encadenará una dependencia al primero (no puede cada uno tener su propia "DB").

En muchos casos es posible recompilar los paquetes para reorganizar o romper estas dependencias. Tengo dudas de por qué Borland no incluye muchos de los paquetes fuentes, pero en todo caso los archivos de código fuente de dichos componentes sí están disponibles y con ellos pueden crearse nuevamente los/otros paquetes para reinstalarlos, cuidando uno mismo las dependencias que se crean.

Espero haber ayudado en algo.

Al González.

Hola Al,

Muchas gracias por los comentarios.

Parte de las pruebas que estoy haciendo van en el camino que sugieres; sin embargo, hay algo que me llama la atención de tús comentarios.

Lo que planteas es que Borland no ha tenido cuidado de las relaciones entre paquetes, sino que ha confiado el asunto a un manejo automático. Si eso es así, implica cargas innecesarias de código al compilar los aplicativos ?. Eso explicaría el porque el tamaño de los ejecutables compilados con Delphi 2007 es considerablemente mayor que al compilar en versiones previas. Bueno, al menos en las que yo uso actualmente, aunque leí que quienes usan Delphi 7 también consiguen ejecutables más livianos que con el 2007.

Voy a estar atento a ese factor cuando termine mis pruebas.

Por otra parte, mencionas el caso de la unidad db. Esta unidad es la base común de las tecnologías de acceso a bases de datos , no parte del BDE. En ese orden de ideas debería estar en un paquete diferente, no en BDERtl100. Como sabes que forma parte de BDERtl100, o la mencionastes solo como un ejemplo general ?.

No he encontrado ningún BDERtl100.dpk, hay algún otro mecanismo para saber exactamente que unidades integran un paquete ?.

Ahora, en una revisión superficial, la única evidencia que encontré de que dbX usa a BDERtl100 es un texto en BDERtl100.xlm diciendo que dbExpress usa a SPParamDesc, definida en BDERtl100.

[rolandoj]

[quote=rolandoj;264716]Hola,

Tratando de desinstalar los componentes BDE (vease el hilo http://www.clubdelphi.com/foros/showthread.php?t=53057) he encontrado que el paquete dbX100 depende del paquete BDERTL100.BPL.

Dado que dbX es el prefijo de dbExpress, debo suponer que dbX100 forma parte de dbExpress. dbX100.bpl es el paquete "CodeGear SQL Explorer UI Package".

Hola amigo:

Perdona que me entrometa sin darte una solucion directa, pero creo que estas afrontando mal el problema, ya lei que debes desinstalar los BDE porque quieres instalar unos componentes con el mismo nombre, ¿no te parece una barbaridad?

sinceramente creo que lo normal seria renombrar el nombre de los nuevos componentes a instalar, si no eres tu el autor el que lo ha hecho ha pecado de inmodestia al pretender hacer unos componentes con un nombre que ya existe, ¿tan dificil es renombrarlos de la forma TxxTable, TxxDatasource etc.?

Yo creo que la solucion esta ahi y no en intentar quitar todo tipo de rastro del BDE en Delphi?

Solo es una opinion. :D

Hola,

Muchas gracias por aportar.

Sería más bien tema de otro hilo; pero, con el perdón del foro, quiero hacer una excepción y darte un breve resumen de mi opinión.

No, no estoy de acuerdo en que usar el mismo nombre sea una "barbaridad". De hecho es lo lógico en un diseño portable, transparente y creciente; renombrar, aparte de ser muy problemático en aplicaciones realmente grandes, como es el caso aquí, genera serios problemas de portabilidad hacia atras, obligando a tener versiones duplicadas de unidades de usuario, sobre todo, las compartidas con otras aplicaciones. En general, a menos que uses aplicaciones pequeñas, no tengas unidades compartidas, uses un solo producto o no tengas que preocuparte por la flexibilidad, renombrar es una muy mala opción

En teoría, si algo está muy bien diseñado, deberías tener una capa básica, dependiente del sistema operativo; una capa intermedia, dependiente de tecnologías de servicios tales como gráficas, acceso a Bases de Datos correos, etc; y una capa de usuario final. La independencia en las mismas, debería permitir cambiar las capas superiores sin alterar la capa de usuario, o a lo sumo con un cambio mínimo.

Debido a mi experiencia (más de 25 años dedicado exclusivamente a programar), yo soy fanático de la portabilidad y la capacidad de crecimiento. Digamos que es una lección que aprendí hace mucho tiempo; pero, en este caso, el código viene de una época en la que confiaba en Borland para la
capa intermedia, que es quién debería haberse encargado. Como en eso hicieron un pobre trabajo, hoy en día ya no confío en ellos y estoy desarrollando mi propia capa intermedia.

[rolandoj]

Hola a todos,

Agradezco toda la colaboración prestada.

Aparentemente ya resolví mi problema básico (vease el hilo http://www.clubdelphi.com/foros/showthread.php?t=53057) y en unos días daré detalles específicos porque creo que es una información particularmente útil para entender el funcionamiento primario de Delphi.

Les adelanto algo : Salvo que alguién aporte evidencia en contra, todo indica que hay dependencias entre los paquetes que no deberían ocurrir, confirmando en gran medida lo dicho por Al; pero, al menos en algunos casos, es problema de diseño y no de simple descuido de independizar paquetes al momento de compilar. Me explico, algunos paquetes no tienen separado su
acceso a Base de Datos de su código propio, de tal forma que se vuelven dependientes de un paquete que no deberían requerir.

[Al González]

¡Hola a todos!

Hola Al,

Muchas gracias por los comentarios...Lo que planteas es que Borland no ha tenido cuidado de las relaciones entre paquetes, sino que ha confiado el asunto a un manejo automático...
No, lo que planteo es que dos paquetes están obligados relacionarse entre sí cuando hacen uso de una misma unidad y van a ser empleados por un mismo proceso (en este caso el entorno de Delphi). Al compilar paquetes, el encadenamiento se lleva a cabo conforme los paquetes que ya están cargados en memoria, pero el compilador siempre te avisa antes de generar un .bpl que requiere enlazarse a otro debido a que implícitamente utilizan (a través de las usualmente vastas cadenas de Uses) alguna unidad en común. No podría asegurar que sea un error o descuido de Borland que dbExpress y otros paquetes de componentes vengan de fábrica con una dependencia implícita hacia el paquete de tiempo de ejecución BDERTL, ya que si bien eso ahora parece no tener gran utilidad, en el pasado se veía como algo normal. Quizá es algo que CodeGear debe revisar y actualizarlo a esta época.

...Si eso es así, implica cargas innecesarias de código al compilar los aplicativos ?...
La respuesta es un tajante no. Hay que dejar claro que cuando Delphi compila una aplicación no toma absolutamente nada de los paquetes para añadir al módulo ejecutable. Todo lo que necesita de código lo toma de las unidades compiladas individuales, es decir, de los archivos .dcu. Y sólo toma estrictamente lo que el propio código refiere de forma directa o indirecta. Puedes tener una biblioteca de miles de funciones independientes en una unidad .pas que luego, claro, es compilada como .dcu. Si tu programa utiliza una sola de esas funciones, sólo agregará al ejecutable lo que esa función hace y las dependencias dictadas por su código fuente, pero no las miles de líneas restantes. Al igual que tú he mirado la forma en que trabajan los productos de Borland desde Turbo Pascal y me consta que desde entonces han sido soberbios cuando de generar código máquina se trata. Borland ya generaba ejecutables optimizados cuando Microsoft apenas compraba su primer compilador real a unos canadienses porque eran incompetentes para crear uno propio.

...Por otra parte, mencionas el caso de la unidad db. Esta unidad es la base común de las tecnologías de acceso a bases de datos , no parte del BDE. En ese orden de ideas debería estar en un paquete diferente, no en BDERtl100. Como sabes que forma parte de BDERtl100, o la mencionastes solo como un ejemplo general ?..
Hay que distinguir entre pertenencia o “formar parte de” y contención. Cuando creamos un paquete añadimos a él, de manera explícita, una o más unidades propias de la biblioteca de componentes que el paquete representa; decimos entonces que tales unidades forman parte del paquete, y ellas aparecen en la sección “Contains”. Pero esas unidades, a través de sus cláusulas Uses, suelen hacer referencias a otras unidades, incluyendo las nativas de la VCL. Si alguna de estas unidades ya está en otro paquete (cuyo BPL está cargado en memoria en ese momento), nuestro paquete se estaría haciendo dependiente de ese otro (no sin el oportuno aviso/pregunta del compilador), agregando una entrada a la sección “Requires”. Pero si tal unidad todavía no está siendo usada por ningún paquete que esté cargado en memoria, entonces nuestro paquete será el primero que la “haga suya”, de manera implícita. Sí, los paquetes “atrapan” a todas las unidades referidas a través de sus Uses, que no hayan sido “atrapadas” ya por otro paquete. Esto último es lo que provoca que subsiguientes compilaciones de paquetes que usen directa o indirectamente la misma unidad se vuelvan dependientes del primero que “tomó” a la unidad en discordia.

Te recomiendo el tema “Understanding the structure of a package” de la ayuda de Delphi, donde, entre otras cosas, se menciona:

All units included directly in a package's contains clause, or included indirectly in any of those units, are bound into the package at compile time.

A unit cannot be contained (directly or indirectly) in more than one package used by the same application, including the IDE. This means that if you create a package that contains one of the units in vcl (VCL) or visualclx (CLX) you won't be able to install your package in the IDE. To use an already-packaged unit file in another package, put the first package in the second package's requires clause.


...No he encontrado ningún BDERtl100.dpk, hay algún otro mecanismo para saber exactamente que unidades integran un paquete ?...
Sé que esa información se guarda en los archivos binarios .dcp, pero no recuerdo si Delphi cuenta con algún accesorio que permita consultarlos. En todo caso quizá exista alguna utilidad en la Red.

...En general, a menos que uses aplicaciones pequeñas, no tengas unidades compartidas, uses un solo producto o no tengas que preocuparte por la flexibilidad, renombrar es una muy mala opción...
En esto creo que cada caso es único. Si bien es un buen argumento, no debemos perder de vista que la tecnología avanza perpetuamente, y es una labor normal y sana comenzar a separar o migrar (según convenga) los desarrollos más viejos conforme la línea tecnológica se “estira”. Según transcurren los años se vuelve más problemático tratar de mantener “en forma” todo un arsenal de código, que actualizar sólo las aplicaciones y bibliotecas de uso más vigente y redituable. Esto es una cuestión de enfoque donde se requiere evaluar muchos factores, caso por caso, pero sin perder objetividad. Si después de evaluar el tuyo a conciencia, aún crees que usar nombres de clases conflictivos es lo mejor, quizá el uso de clases interpuestas te resulte buena alternativa (aunque lo dudo porque intuyo mayores complejidades).

...Debido a mi experiencia (más de 25 años dedicado exclusivamente a programar), yo soy fanático de la portabilidad y la capacidad de crecimiento. Digamos que es una lección que aprendí hace mucho tiempo...

Bueno, ojalá ese fanatismo se cure pronto para que no frene tu crecimiento como desarrollador. Comparto contigo el punto de buscar portabilidad y pensar “más allá de”, suelo hacerlo también. Pero en ocasiones hay que darle permiso al pragmatismo de inmiscuirse en nuestras vidas. ;)

...el código viene de una época en la que confiaba en Borland para la capa intermedia, que es quién debería haberse encargado. Como en eso hicieron un pobre trabajo, hoy en día ya no confío en ellos y estoy desarrollando mi propia capa intermedia.
Cordialmente te invito a que abras otro hilo con ese interesante tema. Mira que estoy muy interesado en todo lo que tiene que ver con programación multicapa. Ahí podrás plantearnos con debido espacio y tiempo el por qué confiabas y ahora no en ese aspecto de Borland/CodeGear.

Un abrazo empaquetado.

Al González.

[rolandoj]

Hola Al,

Muchas gracias por los largos comentarios. Creo que el tema lo amerita.

Como te dije, comentaré ampliamente el asunto; pero, por ahora estoy muy ocupado con las pruebas de la aplicación. Espero que el próximo fin de semana podamos intercambiar información y experiencias de esto con calma.

Solo una pregunta, como para abrir nuevo tema, por si tienes tiempo antes:

Con respecto a las versiones anterioes a la 2007, que he manejado, comparto al 100% tú opinión que el código del compilador Delphi es excelente; pero el del 2007, aún optimizando al máximo los parámetros de compilación, es mucho mayor que el del mismo programa en la versión previa. Leí que lo arreglaban en el Update 3; pero no ha sido así. Que sabes al respecto ?

Muchos saludos

[Al González]

...Con respecto a las versiones anterioes a la 2007, que he manejado, comparto al 100% tú opinión que el código del compilador Delphi es excelente; pero el del 2007, aún optimizando al máximo los parámetros de compilación, es mucho mayor que el del mismo programa en la versión previa. Leí que lo arreglaban en el Update 3; pero no ha sido así. Que sabes al respecto ?...
De momento no estoy en condiciones de afirmar o negar que los ejecutables sean "mucho mayores" de tamaño. Y en caso de que realmente ocurra eso de manera consistente (y no por algún elemento ajeno al compilador, como podría ser una enorme imagen BMP en algún formulario), desconozco si existe un parche para ese hipotético problema.

Creo que por lo pronto Andreano podría respondernos a esta duda.

Edito:
Ahora que lo pienso, creo que sí podrían ser algo más grandes (habría que hacer pruebas para determinar la diferencia proporcional, y ver si esta es realmente mucha o poca) debido a la útil característica de las funciones "in-line" introducida en Delphi 2005. De momento es la única explicación teórica que tendría. Estaremos pendientes de ese detalle.

Saludos.

Al González.

[rolandoj]

Hola Al,

Como este caso te llamó la atención, y estas por probar Delphi 2007, te invito a que mires otro muy raro con que me he encontrado en las pruebas. Esta vez no se trata de hacer algo "no standard" sino de lo que creo es un error; pero ojala que no, porque para mi trabajo sería catastrófico.

Vale anotar que, aunque ni siquiera tendría que tener relación con el reemplazo de BDE, para este nuevo problema restauré los paquetes a su estado original.

El hilo es :

http://www.clubdelphi.com/foros/showthread.php?t=53141