Yo me aventuraría decir amigo que la versión 1.5.5 tiene un BUG ;) y que es por ello que salió la 1.5.6; la última de liberaciones de FB 1.5. ¿Alguien tiene instalado esa versión para comprobar mi presunción?

No quisiera aventurarme demasiado pero al menos en teoría los resultados correctos de tabla son para Firebid 1.5.3 y 2.1.1.

Saludos,

Bueno, he quitado el fb1.5.5 y he puesto el fb1.5.6

Código:

---

+----------+-------+-----------+
| FB 1.5.3 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |    1 |        2 |
+----------+-------+-----------+
| S/Cast() |    1 |      1,50 |
+----------+-------+-----------+
| FB 1.5.5 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |    2 |        2 |
+----------+-------+-----------+
| S/Cast() |  1.50 |      1,50 |
+----------+-------+-----------+
| FB 1.5.6 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |    2 |        2 |
+----------+-------+-----------+
| S/Cast() |  1.50 |      1,50 |
+----------+-------+-----------+
| FB 2.1.1 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |    1 |        2 |
+----------+-------+-----------+
| S/Cast() |    1 |      1,50 |
+----------+-------+-----------+

---

Bueno, mi hipótesis está derrotada :(

¡La verdad es que esto está confuso! Como dijo Al... se cambió y luego volvieron a lo de 1.5.3 en la 2.1.1. :confused: :eek:

Saludos,

Hola.

Partiendo de la consulta original:

Código SQL [-]
SELECT CAST((90/60) AS INTEGER) AS HORA FROM RDB$DATABASE

En Firebird 2.5 y utilizando constantes 90 y 60 como dije antes, el resultado es: 1

Aplicando las consultas realizadas por Delphius en Firebird 2.5 obtuve.
con SQL Mananger:
Y con iguales resultados usando un TIBQuery:


Tomando en cuenta que Firebird, como muchos lenguajes, devuelve un resultado del mismo tipo que el tipo de sus operandos :
1) Es correcto ya que division entera de 90/60 = 1
2) Correcto, igual que realizar IntToStr(Round(90/60)) = 2
3) Correcto, igual caso que 1)
3) Correcto evidentemente.

Entonces tomando en cuenta la consulta original y según mis pruebas, la tabla de Al González me queda:
Cuando pueda voy a provar las versiones con controversias ya que no las tengo en este momento.
Pero aparentemente hay diferencia en las versiones...

Un saludo.

Hola Ecfisa,

Déjame ver si entiendo. ¿Entonces tu prueba indica que la tabla de resultados es idéntica a la que obtuve yo con 1.5.3 y la de Casimiro con la 2.1.1?

Sin ánimos de ofender, ¿Podrías indicar que sub-versión menor de Firebird utilizas? ESO ES MUY IMPORTANTE. Ya lo he aclarado y pedido; y es más que evidente que ese .algo puede traernos sorpresas... sino miren las diferencias entre 1.5.3 y 1.5.5.

Si no sabes cual utilizas simplemente debes abrir el isql y lanzar una instrucción:

Código SQL [-]
show version;

Seamos más organizados por favor. Los demás estamos tratando de presentar los datos en forma de tabla para hacerlo más simple.

Saludos,

Bueno mi respuesta no va orientada a la duda de porque sucede los resultados, es más una respuesta a dar el formato horas y minutos... que tal obtener directamente en formato time? algo así como esto:

Código SQL [-]
select   (cast('00:00' as time) + (90*60))HORA FROM RDB$DATABASE

O de esta forma para que no muestre formatos de la configuración regional

Código SQL [-]
select   cast((cast('00:00' as time) + (90*60)) as varchar(13))HORA FROM RDB$DATABASE

No Marcelo, el método de redondeo que utilizan los motores de bases de datos para resolver números que están "a la mitad", no es el "del banquero" (al par más cercano), sino hacia el infinito, es decir, hacia el valor absoluto superior (1.5 queda como 2; 2.5 queda como 3; -1.5 queda como -2; -2.5 queda como -3). Esto según lo visto en el enlace que puse mensajes más arriba. Cabe decir que todavía no he tenido la suerte de mirar esa norma en ningún documento, a pesar de que tiene toda la pinta de ser una regla formal (sería mucha coincidencia que todos esos fabricantes de bases de datos hubiesen optado por el mismo tipo de redondeo sin un consenso previo).

Ahora, respecto a los resultados que todos nosotros hemos presentado en los mensajes más recientes, queda claro que el molde de tipo "Cast As Integer" trabaja de la misma manera en todas las versiones de Firebird, manera que, por cierto, es la esperada: números a la mitad "suben" (redondeo hacia el infinito). En esto no hay sorpresas.

La ÚNICA diferencia en todo esto es, según se ve, la forma en que cada versión de Firebird maneja las divisiones entre números de tipo entero. Unas versiones truncan la parte fraccionaria y otras no. Por ello es que la sentencia que por ahora valdría la pena probar es solamente la de una simple división entre enteros:

Código SQL [-]
Select 3 / 2 From RDB$DataBase

Ya vimos que una sentencia como esa, trunca la parte fraccionaria del resultado (1.5 -> 1), excepto en un rango de versiones que va, tentativamente, de la 1.5.5 a la 2.0.

Lo que convendría dejar claro es que, aun con esa diferencia de comportamiento entre un rango de versiones y el resto, ninguna versión de Firebird falla en redondear consistentemente un 1 como 1 y un 1.5 como 2 al aplicarle un Cast As Integer. ¿Estamos de acuerdo? :)

Despejado el problema, queda por un lado recomendarle a Joe_Balda, quien usa una de las versiones del "rango rebelde" (Firebird 2.0):

a) actualizarse a una versión superior.

b) hacer un truncamiento de la parte fraccionaria del resultado de la división, ya sea con una UDF, usando Substring, etc.

Por otra parte, la investigación de por qué unas versiones de Firebird truncan las divisiones de enteros y otras no. Y lo que son las cosas, mientras escribía estas líneas tuve la suerte de encontrar este documento:

http://www.firebirdsql.org/manual/qs...ebird-sql.html

La fuente del documento parece lo suficientemente oficial como para dar por sentado que:

Las versiones 1.5.5, 1.5.6 y 2.0 tienen un defecto (bug) con la división entre enteros.

Un abrazo acorde al estándar.

Al González. :)

No me ofende en absoluto, la versión es: 2.5.0

La verdad, no veo que todos los que participamos en el tema usaramos esa convención para exponer los resultados.

De todos formas creo que son datos organizados y entendibles para cualquier lector. Si te parece que algo no quedó en claro por favor decime y gustosamente trataré de explicarlo de la mejor manera que pueda.

Un saludo.

Gracias Al por la aclaración.

Ecfisa gracias por aclarar la versión que utilizas. Respecto a lo de presentar los datos, tienes razón... no todos. Es algo que yo propuse y luego Casi consideró seguir.
A mi modo de ver la ventaja de presentarlo en forma de tabla de 2 entradas permite comparar rápidamente las diferencias entre uno y otro.

Saludos,

He hecho otra prueba, inspirado por el comentario de Al. Y esto fue lo que obtuve:

Saludos,

Lo siento Delphius, realmente no ví la propuesta, y cualquier otro resultado que presente lo voy a hacer en ese formato.
Pero debo hacer las pruebas en otro equipo por que en este, estoy por finalizar una aplicación basada en esta versíón y no
quisiera líos ahora... :)

Un saludo.

¿Suficiente para que ya nos olvidemos del famoso Cast? :)

Queda comprobado que funciona como debe ser en todos los casos y en todas las versiones. No le veo mayor caso seguir haciendo pruebas con Cast, pues el problema reside en la mera división y sólo en un puñado de versiones (las tres que subrayé antes y alguna que otra en ese rango).

Saludos.

Yo tampoco me animo a hacer pruebas con otras versiones. Cuanto mucho me animaría a probar con las versiones 1.5.x por cuestiones de compatibilidad con IBX de D6, pero viendo esas diferencias en los cálculos en la 1.5.5 ya me ando pensando que mejor desisto.

Amigo lo añadí para que vean como referencia y comparación. Me consta de que el CAST anda super bien en todas las versiones. En lo sucesivo no le iré por el CAST, ¡no se me enoje maestro!

Saludos,

:D :D

No te preocupes, no lo haré. :p

divisiones en firebird
 

Select 52.9 /100 From RDB$DataBase
Resultado: 0.5

Select 52.9 /100.0000 From RDB$DataBase
Resultado: 0.529

El divisor decide el tipo y los decimales

Primer caso:





Segundo caso: