Error en Coalesce de un Parámetro tipo Int64

[Casimiro Notevi]

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

[[maeyanes]]

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 = arametro

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



Saludos...

[[gluglu]]

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.

[[gluglu]]

... 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 !

[[maeyanes]]

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

[[gluglu]]

Empezado por maeyanes

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

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.

[guillotmarc]

Hola.

Empezado por maeyanes

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.

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.

[[maeyanes]]

Empezado por guillotmarc

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 un momento dado no queremos filtrar por él.

Creo que en el último Firebird 2.5 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...

[guillotmarc]

Empezado por maeyanes

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 ?.