Extraer parte entera de una division en sql firebird , falla
 

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?

¿Pero de qué tipo son esos campos?

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.

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.

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?

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.

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

Probar
 

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.

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. :)

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


:confused::confused::confused:

¿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,

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

Hola,

Lo veo "fuerte y claro" :eek:

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,

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,

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

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? :confused:

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,

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

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,

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,

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: