Extraer parte entera de una division en sql firebird , falla

[Joe_Balda]

Hola foro,

Tengo la siguiente consulta, necesito convertir el valor de un campo entero en el cual estoy almacenando minutos al formato horas y minutos.
Para esto hago lo siguiente :

Código SQL [-]
Select TIEMPO,
       cast((TIEMPO/60) as integer) as HORA ,
       Mod(T_ESTIMADO, 60) as MINUTOS
from RESERVA

si TIEMPO = 90 el resultado esperado en hora seria 1 y el de minutos seria 30

Ahora cuando efectuo el

Código SQL [-]
cast((TIEMPO/60) as integer) as HORA

Si tiempo = 90 el resultado me da 2 cuando deberia ser 1
90/60 = 1,5 y aparentemente me redondea a 2
a que se debe esto?

[Casimiro Notevi]

¿Pero de qué tipo son esos campos?

[Joe_Balda]

Código SQL [-]
cast((TIEMPO/60) as integer) as HORA

El campo 'TIEMPO' es INTEGER, en el caso que su valor sea 90 el Cast me da como resultado 2 cuando deberia ser 1.

[ecfisa]

Hola.

Aparentemente, el problema no te lo está ocasionando Firebird. Hice dos pruebas diferentes con el valor 90 y en ambos casos el resultado es 1.

Desde el IB Mananger

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

Resultado: 1.

Desde Delphi:

Código Delphi [-]
  IBQuery1.SQL.Clear;
  IBQuery1.SQL.Add('SELECT CAST((CIUDAD_ID/60) AS INTEGER) AS HORA FROM CIUDADES');
  IBQuery1.SQL.Add('WHERE CIUDAD_ID = 90');
  IBQuery1.Open;
  ShowMessage(IBQuery1.FieldByName('HORA').AsString);

Resultado: 1.

En los dos casos me aseguré que el operador 'TIEMPO' tuviera el valor 90. El campo CIUDAD_ID es de tipo INTEGER.
Realmente no sé por que te arroja ese resultado...

Un saludo.

[Joe_Balda]

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

Te comento, tiro esa consulta desde IBOConsole o IB Expert y en ambos casos el resultado es 2.

Desde delphi, version 5, con un TQUERY me arroja el mismo resultado.
Segun veo con otros casos aparentemente cuando la parte decimal es igual o mayor que 5 me lo redondea para arriba.

90/60=1,5 me da como entero 2.

Alguna idea de que pueda ser?

[ecfisa]

Hola.

Mirá, la única diferencia que puedo ver ahora que nombras la versión, es que las pruebas las realicé con Delphi 7 y Firebird 2.5., tal vez sea un tema de versiones.

Te convendría poner que versión de Firebird estas usando, quizá alguno que use Delphi 5 y tu versión de Firebird, conozca solución para este caso.
(o al menos pueda reproducir la condición de error )

Un saludo.

[Joe_Balda]

Delphi 5 y firebird 2.0.
Muchas gracias, seguimos invenstigando.

[cdac901]

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

Prueba con esta sentencia.
Nota: utilizo Firebird 2.5, desconozco si en versiones anteriores existe dicha funcion.

Saludos.

[[Al González]]

Haciendo unas sencillas pruebas con Firebird 1.5, veo que esta sentencia:

Código SQL [-]
Select 90 / 60 From RDB$DataBase

arroja un resultado de tipo entero de 1.

Eso me sugiere que Firebird determina el tipo del resultado con base al tipo de los operandos, y tratándose de una división entre enteros, trunca las decimales del resultado. Así que hice esta otra prueba:

Código SQL [-]
Select 90.0 / 60 From RDB$DataBase

Y el resultado fue, de tipo flotante, 1.5.

Claro que en un caso real los operandos no son constantes, por lo que habría que hacer este molde de tipo si quisiéramos obtener el mismo resultado:

Código SQL [-]
Select Cast (90 As Float) / 60 From RDB$DataBase

(sustituyendo 90 por el campo, parámetro o variable Integer que deseamos dividir entre 60).

Eso sería para que el resultado de la pura división fuese el correcto (flotante 1.5, no entero 1).

Logrando lo anterior, el siguiente paso sería aplicar otro molde de tipo al resultado de la división:

Código SQL [-]
Select Cast (Cast (90 As Float) / 60 As Integer) From RDB$DataBase

Con ello, el valor de 1.5 es redondeado hacia "arriba" (como aparentemente lo hacen por regla la mayoría, sino es que todos los motores de bases de datos), obteniéndose un valor entero de 2.

Pero si lo que se desea NO es redondear el resultado de la división, sino extraer su parte entera, es decir, "truncarlo", hay que hacer algo más. Firebird 1.5 no cuenta con la función Trunc que menciona cdac901 (al menos no de forma nativa), y a partir de este punto me van a disculpar porque el SQL no es mi fuerte. Lo que se me ocurre es algo como esto:

Código SQL [-]
Select Cast (Substring (Cast (90 As Float) / 60 From 1 For 1) As Integer) From RDB$DataBase

Hice una prueba y me arroja el esperado valor entero de 1.

Ahora, queda la duda de por qué a Joe_Balda, la simple división de los enteros 90 / 60, que "debería" dar siempre un resultado entero de 1 (según se infiere con las pruebas que hicimos los demás compañeros), a él, con Firebird 2.0 le arroja un resultado de 2.

Para confirmar lo que dije al comienzo, Joe_Balda y demás compañeros, ¿qué les aparece a ustedes con esta simple sentencia?

Código SQL [-]
Select 90 / 60 From RDB$DataBase

Un extraño saludo.

Al González.

[Casimiro Notevi]

Select 90 / 60 From RDB$DataBase

Prueba con FB 1.5 me ha devuelto: 1.5
Prueba con FB 2.1 me ha devuelto: 1

[[Delphius]]

Empezado por Casimiro Notevi

Select 90 / 60 From RDB$DataBase

Prueba con FB 1.5 me ha devuelto: 1.5
Prueba con FB 2.1 me ha devuelto: 1

¿Seguro amigo?
A mi en FB 1.5.3 dicha consulta regresa 1. Y para comprobar lo dicho por Al:

Código SQL [-]
select 90.0/60.0 from rdb$database

Regresa 1,50

Por otro lado quiero aclarar que SI existe una función de redondeo para Firebird, desde FB 1.0 a versiones 1.5.x se debe utilizar la UDF TRUNCATE y/o I64TRUNCATE. Desde Firebird 2.1 existe TRUNC() y como es bien sabido la gran mayoría de las funciones fueron incorporadas desde "fábrica" al motor y no hay que estar registrándolas.

Saludos,

[Casimiro Notevi]

Pues seguro, aquí va un pantallazo, espero que lo puedas ver:

[[Delphius]]

Hola,

Lo veo "fuerte y claro"

Acabo de ver que tu prueba corre en un FB 1.5.5 ¿habrá cambiado algo entre 1.5.3 y 1.5.5 como para que hayan variado los resultados? ¿O será que IBExpert me lo redondeó solito? Voy a probar con una "conexión cruda" y directa con isql para sacarnos dudas.

Saludos,

[[Delphius]]

Pues creo que ya podríamos confirmarlo: es un tema de versiones, desde Firebird 1.5.5 se ha cambiado el modo de regresar resultados numéricos.

Hice una prueba directa, empleando FB 1.5.3 y obtuve 1 empleando 90/60. Si indico 90.0/60.0 allí si regresa 1,5.

Como lo ha indicado Casi, en 1.5.5 esto ha cambiado y regresa en coma flotante.

Muy posiblemente la regla a aplicar ya no reside en los operandos sino en el tipo del resultado.

Por seguridad si desea obtener el número truncado debe emplearse la función para ello. Como he comentado, SI existe desde FB 1.0 y se llama Truncate() pero necesita declararla. Desde FB 2.1 ya viene incorporada al motor y su nombre ha sido cambiado por Trunc().

Saludos,

[Casimiro Notevi]

Misterio desvelado. Seguramente está en las notas que publican sobre los cambios realizados

[[Al González]]

Esperen un momento.

Código SQL [-]
Select 90 / 60 From RDB$DataBase

Firebird 1.5.3 (Delphius, Al), resultado: 1
Firebird 1.5.5 (Casimiro), resultado: 1.5
Firebird 2.0 (Joe_Balda), resultado: 1.5 (por confirmar)
Firebird 2.5 (ecfisa), resultado: 1 (por confirmar)

¿Realmente será un asunto de versiones? ¿Algo que dejó de estar en la versión 1.5.5 reapareció en la versión 2.5?

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