Error en Coalesce de un Parámetro tipo Int64
 

Hola a tod@s !

Tengo un campo en una tabla del tipo Decimal(12,0), es decir, puede almacenar valores del tipo Int64.

Por otro lado, tengo un TIBDataSet enlazado con dicha tabla mediante ese campo clave del tipo Int64.

Cómo puedo hacer para preguntar en el IBDataSet si el parámetro clave es null o no ?

He intentado poner :

Código SQL [-]
Select Campo1 from Tabla1
where :Clave is Null

pero en este caso el error que me dá es 'Data Type Unknown' ya que al parecer no comprende de que tipo es el campo Clave.

Lo que se me ocurrió entonces es enlazarlo de esta manera :

Código SQL [-]
Select Campo1 from Tabla1
where Coalesce(:Clave, 0) = 0

y funcionaba perfectamente hasta que en el campo Clave aparezca un valor Int64 de 12 posiciones (p.ej. 123456789012).

El error que me aparece ahora es (en tiempo de ejecución) : 'arithmetic exception, numeric overflow or string truncation'.

Tengo ya perfectamente comprobado que se deben a los valores grandes de 'Clave', ya que con cualquier otro valor funciona correctamente, hasta que introduzco un Int64 y entonces al parecer el Coalesce(:Clave, 0) me lanza el error indicado.

Gracias por vuestra ayuda.

Hola...

Si estás usando Firebird/Interbase, ¿por qué no usar el tipo de datos BIGINT para el campo Clave?


Saludos...

¿Será un problema del componente?.
No sé, la verdad, pero me apunto para seguir este tema.

Hola gluglu.

Probá consultándolo de este modo:

Código SQL [-]
SELECT CAMPO1 FROM PRUEBA
WHERE CAST(:CLAVE AS BIGINT) IS NULL

Hice algunas pruebas con un TIBDataSet y no me arrojó error.

Saludos.

Hola Ecfisa !

Justo estaba probando eso antes de que viera tu post !! ... y es cierto, de esa manera no da error ! :D

Hola...

Y bueno, me quedaré con la duda :D :D



Saludos...

Hola maeyanes !

Estoy utilizando Firebird 2.1, y no es que haya definido Clave como BigInt, sino tal y como indiqué lo tengo en la BBDD como Decimal(12,0), por lo tanto acepta valores 'BigInt'.

El problema era pasarlo como parámetro en otro IBDataSet. Ahí no puedo definir al parámetro como que sea de ningún tipo en concreto, por lo que me lanzaba el error. Y es por ello que me surgió el problema que expuse en este hilo.

La única solución que hemos sacado es hacer el Cast a BigInt ....

... o habría otra alternativa ? Yo he probado ya todas las que se me ocurrieron y no tengo forma de resolverlo si no es como aquí se ha indicado.

Hola...

Por eso te pregunto, ¿hay algo que te impida cambiar el tipo de campo a BIGINT? De esta forma te evitarías tener que hacer castings al momento de realizar tus consultas.



Saludos...

No he probado lo que me indicas ...

Según tu comentario, si 'defino' directamente el campo en Tabla1 como BigInt en vez de Decimal(12,0), no me va a dar el error al pasarlo como parámetro en el nuevo TIBDataSet ... ?? :o

En cualquier caso .... tengo un GRAN número de campos de un GRAN número de tablas, definidas con un Domain 'NV12' (definido a su vez como Decimal(12,0)), y cambiar todas estas definiciones a BigInt ... :( ...

De momento, para el caso particular en el que uso el parámetro para preguntar si es Null, me ha servido la contestación que me habeis dado en este hilo.

Gracias una vez más .. :cool:

Yo tengo alguna tabla con campo clave principal bigint, aunque no creo que ningún cliente haya llegado a usar los 12 dígitos, por lo demás, ningún problema.

Hola...

Así es, no te debería dar problemas.

Ahora ya solucionaste tu problema y me parece bien, pero siento que en determinado momento te faltó analizar mejor que tipo de información se pensaba almacenar en las tablas/campos.



Saludos...

Realmente lo analicé mucho cuando me puse a definir los campos de cada tabla.

Como dice también Casimiro, generalmente no se suelen utilizar los 12 dígitos que tengo definidos, pero precisamente por eso no me dí cuenta del problema en un nuevo listado que hice hace poco, porque generalmente no se utilizan los 12 dígitos, pero resulta que haciendo pruebas .... sí que suelo hacerlas con 12 dígitos para que si algún diera se diera el caso ....

Nunca pensé tampoco que habría diferencia entre declarar los campos como Decimal(12,0) o BigInt. De hecho, en el 99% por ciento de los casos no he tenido problemas ... hasta que salía el 1% dichoso !

Tengo que indicar que además tengo otro Domain definido con el tipo Decimal(14,2) para guardar unicamente 2 decimales, pero con cifras grandes, cuando trabajo con valores de monedas. Y aunque en Euros ... 12 cifras delante de la coma son muchos Euros, en otras divisas del mundo se pueden lelgar a manejar facilmente valores que sobrepasan los mil millones, es decir, fácilmente podríamos llegar a más de 10 cifras delante de la coma, por lo que ahí recapacité los valores que se iban a poder almacenar y en este caso no podría utilizar el BigInt.

Saludos !

Hola.

Al igual que maeyanes para ese tamaño numérico yo definiria un BIGINT.

Pero hay algo que ví en las pruebas y no esperaba: Aún declarando el campo como BIGINT el cast es necesario. Si no lo utilizo, obtengo el error: "Campo Clave no encontrado".

Esto sucede tanto con el manejador de BD como desde el TIBDataSet. Lo que lamento es tener como único argumento el resultado de las pruebas... Voy a buscar un poco si encuentro documentado el motivo.

Saludos.

Parece que estamos hoy en sintonía, ecfisa y yo !

De nuevo, acabo de hacer las mismas pruebas, sólo ya por curiosidad, y coincido con él, que el Cast es necesario a pesar de haber definido el campo como BigInt.

Código SQL [-]
Select Campo1 from Tabla1
where :Clave is Null

no me funciona, a pesar de haber declarado Clave como BigInt, y me dá de nuevo el error 'Data Type Unknown'

Y si utilizo la función Coalesce, de tal manera que

Código SQL [-]
Select Campo1 from Tabla1
where Coalesce(:Clave, 0) = 0

me vuelve a saltar el mismo error de Arithmetic exception, numeric overflow ...' :mad:

¿Y ese error es desde ibexpert, flamerobin, etc. o es poniéndole el sql a algún componente desde delphi?

Sin el uso del cast, me aparece error en ambos casos Casimiro. Ya sea lanzando la consulta directamente desde el mananger o desde el IBDataSet.


Saludos.

Bueno, he estado haciendo pruebas con el isql, que es del único que me fio :) y funciona perfectamente... o estoy ya medio dormido :D

Yo estoy utilizando Delphi 2007 y TIBDataSet.

No sé cómo hacer dicha operación con el IBExpert. Sí que puedo ver relaciones Maestro/Detalle y funcionan correctamente, pero no sé cómo poder relacionar un Query con la tabla correspondiente y así poder probar la sentencia SQL que indicaba anteriormente.

Si no hay forma de hacerlo como quieres, quizás pueda hacerse ejecutando desde tu programa el isql y que guarde el resultado en una tabla/fichero externo, luego desde tu programa lees ese fichero.
Desde luego que las pruebas que he hecho con ibdataset no funcionan, debe ser que internamente hacen uso de un int aunque se haya declarado el campo como bigint. A ver si a mediodía hago una prueba con TFIBDataSet, aunque si no lo usas tú, tampoco va a servir de nada.

Hola.

Para aportar mas datos, usando esta tabla:

Código SQL [-]
CREATE TABLE PRUEBA (
  CP_SMALLINT SMALLINT,
  CP_INTEGER INTEGER,
  CP_BIGINT BIGINT,
  CP_FLOAT FLOAT,
  CP_DOUBLEPRECISION DOUBLE PRECISION,
  CP_NUMERIC NUMERIC(15, 3),
  CP_DECIMAL DECIMAL(15, 3));

hice unas pruebas con TIBDataset, variando en la cláusula SELECT: CP_SMALLINT, CP_INTEGER, CP_BIGINT, CP_FLOAT, P_DOUBLEPRECISION, CP_NUMERIC y CP_DECIMAL.

Con el código:

Código Delphi [-]
  IBDataSet1.Close;
  IBDataSet1.SelectSQL.Clear;
  IBDataSet1.SelectSQL.Add('SELECT CP_SMALLINT FROM PRUEBA');
  IBDataSet1.SelectSQL.Add('WHERE :CLAVE IS NULL');
  IBDataSet1.Open;

En todos los casos obtuve el error: "Tipo de datos SQL desconocido (32766)", sin siquiera asignar valor al parámetro. Lo que me induce a pensar que esta forma de llamada es incorrecta.

Con el código:

Código Delphi [-]
  IBDataSet1.Close;
  IBDataSet1.SelectSQL.Clear;
  IBDataSet1.SelectSQL.Add('SELECT CP_SMALLINT FROM PRUEBA');
  IBDataSet1.SelectSQL.Add('WHERE Coalesce(:Clave, 0) = 0');
  ...
  IBDataSet1.Open;

Sin asignar valor al parámetro no arroja error en ningún caso. Asignando el valor que nos dió gluglu con cualquier tipo de entero, me dá el mismo error de overflow que a él.

Con el código:

Código Delphi [-]
  IBDataSet1.Close;
  IBDataSet1.SelectSQL.Clear;
  IBDataSet1.SelectSQL.Add('SELECT CP_SMALLINT FROM PRUEBA');
  IBDataSet1.SelectSQL.Add('WHERE CAST(:CLAVE AS SMALLINT) IS NULL');
  ...
  IBDataSet1.Open;

No obtuve error en ningún caso, asignando o no, valores al parámetro CLAVE.

Saludos.

A ver, me estoy liando, en todo esto que se está tratando, ¿qué es :clave ?, si es un parámetro, ¿cómo se está usando?

Eso entendí yo Antonio, al menos es el problema que comenta gluglu en el primer post.

Hola.

Esta consulta funciona perfectamente (las comparaciones con Null tienen este problema en los parámetros, el motor no sabe de que tipo es). ¿ Qué problema tienes con ella ?.

Saludos.

Hola guillotmarc.

A mi no me ofrece ningún problema, el tema viene de más atrás. Esa consulta que estás mencionando, es la que le sugerí a gluglu como solución al error que le provocaba esta:

Código SQL [-]
  Select Campo1 from Tabla1
  where :Clave is Null

y esta:

Código SQL [-]
  Select Campo1 from Tabla1
  where Coalesce(:Clave, 0) = 0

cuando el valor asignado al parámetro es el que menciona en el post que inició el hilo.

Lo que no estaba en claro era el por qué. Pero ahora se aclara con tu comentario:
Un saludo.

Perdón, estaba un poco liado con un asunto y me perdí un poco del hilo.

Casimiro, 'Clave' es cualquier campo que quiero pasar a otro DataSet como parámetro para una nueva búsqueda. Creo que Ecfisa me entendió correctamente.

Se trata de que quiero realizar una búsqueda con un dato que viene de otra tabla diferente (DataSet diferente). Vamos, como si fuera un Maestro-Detalle. Al detalle, le debo pasar el parámetro 'Clave' (que puede ser cualquier campo que decidamos ...) al DataSet Detalle.

Por eso creo que Ecfisa lo ha probado correctamente, creando para ello una tabla que contenga todos los diferentes de tipos de datos que en una consulta posterior pasaremos como parámetros a una nueva consulta de 'Detalle'.

El problema es que ese parámetro que vamos a pasar al 'Detalle' puede ser Null ! ... y aquí es donde aparecen todos los problemas que estamos comentando.

Delphi parece ser que, como dice guillotmarc, no se aclara con el tipo de datos que se está pasando como parámetro al 'Detalle' en caso de que sea 'Null' dicho parámetro (que en este hilo hemos llamado 'Clave'). Lanza un error de Tipo de Datos desconocido.

Es por ello, como estamos comentando, que es necesario hacer un Cast de la manera adecuada. Inicialmente, yo no probé con el Cast, sino con la función Coalesce, para que el valor, en caso de que el parámetro fuera Null, devolviera 0. Pero vuelve a dar otro error, que es por lo que abrí el hilo, en caso de que el valor del parámetro a pasar, fuera un BigInt o en mi caso particular un dato de 12 cifras declarado como Decimal(12,0).

De aquí toda la problemática del hilo ! ;)

Supongo que con "when" ocurrirá igual que con "coalesce"

Código Delphi [-]
case when (expr1 is null) then expr2 else expr1 end

El problema no es When o Coalesce, el problema es cuando hablamos de Parámetros ....

En tu consulta no has utilizado los campos como parámetros que se pasan de una consulta a otra. :o

Perdón, no había leído el anterior mensaje explicándolo :o

Hola...

No se ustedes, pero se me hace raro una consulta que diga:

Código SQL [-]
select campo1 from tabla1
where NULL is NULL

que es lo que en realidad está haciendo [b]gluglu[/u]. Lo que siempre se hace es algo como:

Código SQL [-]
select campo1 from tabla1
where campo1 = :parametro

Yo creo que deberías verificar de nuevo lo que estás tratando de realizar y modificarlo de acuerdo a.



Saludos...

No creo oportuno poner la consulta completa, ya que se trata de un SP que crea una tabla temporal y después hay que sacar datos de otras varias tablas.

La pregunta inicial podría haber sido de otra manera (es decir, el título del hilo). Pero yo pensaba que el problema venía de la función Coalesce, y por eso el título que puse al hilo.

El tema, creo yo, es tan simple como poder verificar si un parámetro que se pasa a otro DataSet es null o no, partiendo de la base, claro está, de que dicho valor puede ser null.

... añado ...

Creo que anteriormente ya lo puse. No sólo se trata de comprobar si el parámetro es Null o no, sino que dependiendo de si es Null o no, existe un 'and' después.

Esta es la consulta (muy cortita) :

Código SQL [-]
Select COMMENTS
from BOOKINGS_BLOB
where Cast(:BOOKINGNO as BigInt) is not Null
and BOOKINGNO = :BOOKINGNO
and TYPENO = 4
 
union
 
Select COMMENTS
from LOCK_OBJECTS_BLOB
where Cast(:BOOKINGNO as BigInt) is Null
and INTERNALNO = :INTERNALNO

Después de crear mediante un SP una tabla temporal, utilizo este Select en un informe de FastReport para dependiendo de si el valor de BOOKINGNO del DataSet Maestro es Null o no, busco el Comentario (COMMENTS) que es del tipo Blob en una u otra tabla adicional, ya que el registro de la tabla temporal puede ser una Reserva de una Habitación o un Bloqueo de una Habitación, pero en el listado se muestra el Número de Habitación en cualquier caso, y dependiendo de ello, el comentario que aparece en el informe de Fast Report será el comentario de la Reserva o el comentario asociado al Bloqueo.

En la tabla temporal tengo dos campos (además de otros muchos), que me sirven de referencia 'Maestro-Detalle', tanto BOOKINGNO como INTERNALNO.

La Banda Detalle del Fast Report quiero que sea única, como ya dije, dependiendo de si es una reserva o un bloqueo de un número de habitación concreto, quiero que aparezca el comentario bien de la reserva, bien del bloqueo.

Espero que este comentario adicional sirve de aclaración para lo que pretendía conseguir.

Gracias de nuevo a todos ! ;)

Hola...

Si el valor que estás pasando al DataSet viene de otro DataSet, entonces puedes verificarlo mediante un if...then:

Código Delphi [-]
if DataSet1.FieldByName('campox').IsNull then
  // Hacer lo que sea que se tenga que hacer cuando el valor es nulo...

A lo que voy es que hacer algo como :CLAVE is NULL como condición en una consulta no tiene mucho sentido (al menos de la forma como estás planteando tu ejemplo), esto claro, a mi forma de ver.


Saludos...

Tu lo has dicho, el valor que estoy pasando al DataSet. Ese es el punto crucial de todo este hilo. No voy a hacer una consulta en Código Delphi, sino en Código SQL dentro de otro DataSet ('Detalle') diferente.

El código que pones es código Delphi y lo tengo que ejecutar en mi aplicación. Pero mi problema surge al querer enlazar mediante 'Maestro-Detalle' dos DataSets diferentes, en este caso en tiempo de diseño.

Hola.

En realidad es muy común, pero solo ha comentado una parte del filtro que debe usar realmente.

Se utiliza muchísimo para consultas del tipo :

select *
from CLIENTES
where (:APELLIDOS is null or APELLIDOS = :APELLIDOS) and (:TELEFONO is null or TELEFONO = :TELEFONO)

Es decir, diseñamos una consulta a un tabla por varios posibles parámetros, pero podemos dejar el parámetro a Null si en ese momento el usuario no quiere filtrar por él (como cuando tienes una pantalla con varias opciones de búsqueda, y el usuario solo rellena una parte).

Creo haber leído que en el último Firebird 2.5 el motor de Firebird ya es capaz de reconocer el tipo de los parámetros en esta estructura, pero en las versiones anteriores es cuando hay que hacer un CAST con el tipo.

Saludos.

Pues la verdad nunca me he cruzado con algo como esto.

Y bueno, la forma en como gluglu puso su ejemplo inicial, hizo que yo expusiera mis argumentos anteriores.

Y aún así, acabo de hacer una prueba con una tabla de un sistema que estoy haciendo y dos consultas SQL:

Código SQL [-]
select * from tabla
where cast(:id as integer) is not null and id = :id and tipo = 0

select * tabla
where id = :id and tipomov = 0

A ambas consultas les pasé como valor del parámetro un valor x y NULL y el resultado en ambas fue exactamente el mismo, o sea, que según esto, el hacer :id is not null (o :id is null) no afectó en el resultado.


Saludos...

Lo siento, no entiendo adonde quieres llegar (me da mucha pereza desentrelazar todo lo que habéis comentado en el hilo), el comportamiento de esas dos consultas que indicas parece el lógico.

¿ Aún tienes alguna duda concreta sobre como opera con los parámetros Firebird, cuando no puede discernir su tipo (y es necesario especificarlo en un CAST) y para qué es útil poner construcciones :PARAM IS NULL dentro del filtro de una consulta ?.

Hola...

A lo que voy es que no veo muy lógico hacer algo como parametro is not null dentro de la consulta, pero bueno, cada quien tiene sus formas de hacer las cosas. ;)


Saludos...

En efecto, cada maestrillo tiene su librillo, en mis programas tengo centenares de consultas con filtros que contienen :PARAMETRO IS NULL.

Como te comentaba antes, es la forma estándar de escribir consultas parametrizadas (que no se construyen dinámicamente, no me gustan las consultas construidas dinámicamente, son una fuente de problemas que solo se pueden encontrar en tiempo de ejecución) en las que quieres que se evalúen distintos parámetros en función de los valores rellenados por el usuario.

¿ Se te ocurre otra forma de diseñar una consulta parametrizada para listar clientes, cuando el usuario puede especificar su nombre, su teléfono, o ambos a la vez ?.

Código SQL [-]
select *
from CLIENTES
where (:APELLIDOS is null or APELLIDOS = :APELLIDOS) and 
          (:TELEFONO is null or TELEFONO = :TELEFONO)

Saludos.

Hola...

Como comenté anteriormente, nunca se me ha (o había) presentado un caso como este en mis desarrollos y más por que mayormente genero las sentencias SQL de mis consultas de forma dinámica.

Así como presentas tu ejemplo ya tiene más sentido el uso que indicas, pero de la forma en que lo presentó gluglu (donde solo usa un parámetro) es donde no le vi mucho sentido.



Saludos...