Extraer parte entera de una division en sql firebird , falla

[[Delphius]]

Ummm... me has dado que pensar Al.

Lo que si es bueno recalcar es que no es lo mismo hacer:

Código SQL [-]
90/60

que hacer

Código SQL [-]
Cast(90/60 as integer)

En el primer caso el resultado dependenderá de como esté implementado el algoritmo para generar e interpretar el tipo. Esto es lo que hemos demostrado que varía de versión a versión.

En el segundo caso, independientemente de la versión del motor, DEBERÍA regresar el entero redondeado. Y como ha mencionado Al, por defecto se aplica el redondeo al par más cercano o también conocido como método del banquero.

Ahora bien, si se quiere hacer más líos podríamos comprobar si resulta ser lo mismo a esto:

Código SQL [-]
Cast(90.0/60.0 as integer)

Es decir: probar 4 posibilidades: Con/Sin cast y Con/Sin .0. De este modo podríamos armar una tabla de 2 entradas y comparar resultados. ¿Les parece?

EDITO:
Por favor, a fin de evitar mayor confusión que la generada, no digan 2.5 ¡Digan hasta el apellido! mencionen la sub-versión menor. Tomensé la molestia de decir ese numerito que mucho importa; aunque no lo crean. Es decir: 2.5.algo

Saludos,

[[Delphius]]

Aquí presento los resultados tabulados para que se aprecie bien las diferencias. Espero que con esto quede más claro la cosa:

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

Las consultas fueron:

Código SQL [-]
select cast(90/60 as integer) as Nro from rdb$database
select cast(90.0/60.0 as integer) as Nro from rdb$database
select 90/60 as Nro from rdb$database
select 90.0/60.0 as Nro from rdb$database

Respectivamente.
Puede apreciarse que el motor de FB 1.5.3 prioriza y determina el resultado dependiendo del tipo de los operandos. Y como intuía, aplica redondeo cuando se utiliza Cast.

Apreciaría que los demás siguieran la misma prueba, con éstas consultas. Y por si hay que añadir más factores a considerar entonces sumemos el SO: en mi caso Windows XP sp2

Saludos,

[Casimiro Notevi]

+----------+-------+-----------+
| 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 2.1.1 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |     1 |         2 |
+----------+-------+-----------+
| S/Cast() |     1 |      1,50 |
+----------+-------+-----------+
 

Añado mis resultados

[Casimiro Notevi]

No parece lógico tantas diferencias, diría que es un desbarajuste en el que nadie se pone de acuerdo, el último que llega lo pone a su gusto :s

[[Delphius]]

Empezado por Casimiro Notevi

No parece lógico tantas diferencias, diría que es un desbarajuste en el que nadie se pone de acuerdo, el último que llega lo pone a su gusto :s

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,

[Casimiro Notevi]

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

+----------+-------+-----------+
| 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 |
+----------+-------+-----------+

[[Delphius]]

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.

Saludos,

[[RONPABLO]]

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

[[Al González]]

Empezado por Delphius

Y como ha mencionado Al, por defecto se aplica el redondeo al par más cercano o también conocido como método del banquero.

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

Firebird concuerda con el estándar SQL truncando el resultado (cociente) de un cálculo entero/entero hacia el siguiente entero más bajo. Esto puede tener resultados [que quizá le parezcan] raros a menos que usted esté consciente de ello [de esta regla del estándar SQL].

Por ejemplo, este cálculo es correcto en SQL:

1 / 3 = 0

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.