Error en Coalesce de un Parámetro tipo Int64

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

[[maeyanes]]

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

[guillotmarc]

Empezado por maeyanes

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.

[[maeyanes]]

Hola...

Empezado por guillotmarc

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.

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

[guillotmarc]

Empezado por maeyanes

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.

Sí, el caso de gluglu es muy distinto.

Saludos.