BDE y Firebird

[peccatum]

Hola, como siempre disculpas por si esto ya lo han preguntado, soy novato y me surgio un inconveniente...

Utilizo Delphi 5 y Firebird 1.5, accedo a ésta a travéz del DBE que viene con D5....

La cuestión es que la DB está en sql dialect 3 y al parecer el DBE no soporta algunos tipos de datos (me está pasando con el tipo BIGINT), cuando intento poner en 'activa' una Ttable desde delphi que apunta a la tabla en la DB me da un error de 'field type invalid', o algo por el estilo.

Quiziera que alguien me aconseje, que me conviene hacer, en cuanto a la conectividad, Qué utilizar tomando en cuenta las versiones que manejo...

Probe con los componentes IB que aparecen en la versión enterprise de D5 que utilizo, y parece andar bien, por que agrego una IBDatabase al form, indico el path, y puedo poner activas todas las tablas y consultas que uso, pero me surge la duda de cómo luego puedo generar un ejecutable para instalar en cualquier PC que no disponga de Delphi, sin necesidad de indicar el path en cada maquina y recompilar, ya que con DBE tengo entendido que se crea el alias en la maquina cliente y la aplicación ya sabe donde está la DB....

De antemano muchas gracias ...

[[Lepe]]

Lo mejor es olvidar el BDE y los TTables.

Yo uso los MDOLIB (open Source y gratuito) que estan basados en IB 6. El BDE supone una capa más, está obsoleto y te obliga a crear el alias.

Lo normal es guardar en un archivo .ini la ruta a la base de datos: "c:\programa\misdatos.fdb" o si usas un servidor: "192.168.0.1\programa\misdatos.fdb"

Ahora quedaría instalar el Cliente y/o Servidor Firebird (los MDOLIB pueden hacerlo por código delphi, así que te olvidas del instalador). En algunos casos, se puede utilizar el Firebird embebido (que solo requiere copiar 1 dll).

Desaconsejo que uses los IB ya que en el futuro no serán compatibles con Firebird.

Saludos

[rolandoj]

Hola,

Independiente de cualquier otra cosa, si estas empezando la aplicación, lo mejor que puedes hacer es diseñarla con portabilidad de Base de Datos; de esta forma no tienes que preocuparte al cambiar de motor de Base de Datos, ya que podrás hacerlo tan solo cambiando el Alias en el BDE Administrator, o en su equivalente, si en lugar de BDE usas otra tecnología; pero si la usas ten en cuenta que si vás a distribuír la aplicación a usuarios con los que no tienes contacto directo, tienes dos opciones:

1. Distribuyes la parametrización con archivos .Ini, lo que es lo más facil en términos de tú trabajo; pero una mala presentación a efectos de los usuarios finales, y más vulnerable a errores de ellos en los parámetros.

2. Tienes que construír tú propio BDE Administrator para la tecnología que uses, o tratar de conseguír uno en la red (si es que lo hay). Yo he migrado una aplicación a Delphi 2007 con dbExpress y me ha tocado escribir mi propio BDE (dbExpress) Administrator (está casi terminado). Es considerablemente más trabajo; pero dá integridad a los parámetros, facilita el cambio de los mismos y proyecta una imagen profesional para los usuarios finales.

Respecto a la que te digo de portabilidad, la regla básica parte de usar solo campos de caracter, numéricos de doble precisión, o BLOB. Así por ejemplo, si debes manejar un campo de fechas, almacenacelo como caracter de 8 posiciones en el formato aaaammdd. Hay otras consideraciones; pero al menos, considera estas.

El punto importante es que al trabajar así; si por una u otra razón, sea rendimiento de la aplicación, o licensias del motor de Base de Datos, o políticas internas de la empresa a la que le vendas el producto, u otros aspectos, la aplicación deba trabajar con un motor diferente al usado al elaborarla, no hay necesidad de re-escribir código. Por amplia experiencia te digo que si no tienes en cuenta esos aspectos y debes cambiar, dependiendo del motor y como hayas codificado, el trabajo puede ser muy largo.

Suerte

[[Lepe]]

Hasta donde yo sé, no es conveniente usar double precision para importes monetarios en Firebird (y otras BBDD), ya que dichos valores no se guardan con el valor exacto y al rescatarlos tendrás imprecisiones.

Estos problemas sobre todo, llegan al realizar operaciones con los datos de facturas, base imponible + porcentaje iva - porcentaje de retencion = total factura.

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Saludos

[[felipe88]]

Usa DBExpress...

[rolandoj]

Empezado por Lepe

Hasta donde yo sé, no es conveniente usar double precision para importes monetarios en Firebird (y otras BBDD), ya que dichos valores no se guardan con el valor exacto y al rescatarlos tendrás imprecisiones.

Estos problemas sobre todo, llegan al realizar operaciones con los datos de facturas, base imponible + porcentaje iva - porcentaje de retencion = total factura.

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Saludos

Hola,

La observación es importante y amerita una explicación:

Como dije antes, la metodología de portabilidad incluye varios aspectos. Uno de ellos es el problema de la precisión de datos numéricos. En general, el código no debería quedar dependiente de la implementación que un motor de Base de Datos haga de los valores numéricos. El mayor o menor esfuerzo que se haga para lograr esto depende de las condiciones de diseño de la aplicación y la proyección en el tiempo de dicho diseño.
El consejo más básico es, por supuesto, reducir el uso de decimales a lo estrictamente necesario.

El caso más sencillo es cuando los valores máximos proyectados no exceden las capacidades de la doble precisión. La clave está en definir lo más homogeneamente los decimales requeridos y efectuar tempranamente redondeos asegurando que los bloques de datos individuales queden consistentes para que a su vez sean consistentes los acumulados calculado a partir de ahí. En otras palabras, confiar los redondeos a la lógica de la aplicación y no a las capacidades del motor.

Por ejemplo, entre los software que he desarrollado con esa metodología está una contabilidad completa, incluyendo cálculos automáticos de depreciación y ajustes por inflación, que actualmente trabaja con Interbase 6 y en 6 años no ha dado problemas de precisión.

El asunto se complica es cuando la aplicación requiere valores numéricos proyectados que exceden la capacidad de la doble precisión. Hay varias alternativas dependiendo de la complejidad; y de hecho, si es mucha. incluso podría ser necesario considerar sacrificar portabilidad.

Se puede escribir mucho más sobre esto; pero ya sería tema de otro hilo

[peccatum]

Empezado por Lepe

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Hola

Hice caso y cambié varios dominios a numerico con escala ...

Me queda la duda de cual es la mejor forma de pasar parámetros, ya que el "query.paramsByname('precio').asNumeric;" no existe... por ahora estoy usando ".asCurrency" pero no se si es lo más adecuado...

saludos

[akela]

Empezado por peccatum

Hola

Hice caso y cambié varios dominios a numerico con escala ...

Me queda la duda de cual es la mejor forma de pasar parámetros, ya que el "query.paramsByname('precio').asNumeric;" no existe... por ahora estoy usando ".asCurrency" pero no se si es lo más adecuado...

saludos

Si es lo correcto, porque delphi así te maneja el redondeo que se usa abitualmete para el $$ (€)

[[Lepe]]

Si has cambiado los campos en la base de datos, te faltaría hacerlo en Delphi.

doble clic a tu tabla/query y verás los campos, si seleccionas uno, en el Inspector de objetos te dirá arriba del todo "Importe TFloatField" bien, le das a supr quitando el campo y boton derecho add, ahora mira la declaración, te debería decir "Importe TBCDField" (esto dependerá de tus componentes de acceso, BDE, MDO, IBX, FIBPLUS, BCD es Binary Coded Decimal que es el representante de numeric o decimal de la base de datos.

Quizás al usar campos Float en delphi, se tengan imprecisiones al multiplicar/dividir entre campos, porque recordemos que el fallo es inherente al tipo Float o double precision.

Edito: Después puedes usar .AsCurrency, como muy bien apunta akela.

Saludos.