Un error de concepto en la cláusula WHERE

4 comentarios

A veces, escribimos un SELECT, nos parece que está todo bien, pero sin embargo no es así. Lo miramos de arriba a abajo, de abajo a arriba y no encontramos el problema pero sin embargo … el SELECT no funciona.

Lo más probable es que ya te haya ocurrido algo así, y si ese no es el caso, no te apures … ya te ocurrirá.

Un caso de esos ví hace unos días y me pareció instructivo para mostrarlo aquí en el blog. Veamos:

Consulta 1. Un SELECT que sí funciona

SELECT
   PER_NOMBRE,
   PER_APELLD,
   CASE
      WHEN PER_ESTCIV = 1 THEN 'Soltero'
      WHEN PER_ESTCIV = 2 THEN 'Casado'
      WHEN PER_ESTCIV = 3 THEN 'Separado'
      WHEN PER_ESTCIV = 4 THEN 'Divorciado'
      WHEN PER_ESTCIV = 5 THEN 'Viudo'
   END
FROM
   PERSONAS

Este SELECT está todo ok, funcionará perfectamente, nos mostrará el nombre de una persona, su apellido, y su estado civil. El estado civil está codificado con un número que va del 1 al 5 pero lo que veremos será una palabra y eso está ok.

Consulta 2. Un SELECT que no funciona

SELECT
   PER_NOMBRE,
   PER_APELLD
FROM
   PERSONAS
WHERE
   CASE
      WHEN PER_ESTCIV = 1 THEN 'Soltero'
      WHEN PER_ESTCIV = 2 THEN 'Casado'
      WHEN PER_ESTCIV = 3 THEN 'Separado'
      WHEN PER_ESTCIV = 4 THEN 'Divorciado'
      WHEN PER_ESTCIV = 5 THEN 'Viudo'
   END

Este SELECT es muy parecido al anterior, pero sin embargo no funcionará. Lo que se hizo fue pasar el CASE en el WHERE. Eso no es un problema en sí porque podemos tener un CASE en el WHERE, sin embargo este SELECT no funciona.

¿Por qué?

Ese SELECT fue visto por gente con bastante experiencia en Firebird pero sin embargo no detectaron el problema. O tardaron en detectarlo. El autor de este blog detectó el problema al instante pero le extrañó mucho que gente experimentada con Firebird tardara tanto tiempo en encontrar el error (el SELECT problemático en realidad era otro, con otras columnas, otra tabla, muchas más columnas, pero la idea es la misma, y aquí se la muestra simplificada).

¿Dónde está el problema? ¿ya lo encontraste?

Si no es así, vuelve a mirar el SELECT y trata de encontrarlo antes de mirar la solución, porque si miras la solución no estarás usando tu cerebro.

¿Y?

¿Por qué el SELECT mostrado en la Consulta 2. no funciona?

Bien, la respuesta correcta es “porque no está completo”. Le está faltando algo. ¿Qué le está faltando?

Para saber lo que le está faltando debemos pensar en el WHERE. ¿Qué escribimos en el WHERE? Una condición para filtrar las filas que serán mostradas. Ok, todo bien hasta ahí. ¿Y cuáles son los valores posibles de una condición? que se cumple o no se cumple. En SQL eso podríamos traducir como: debe devolver verdadero o falso. Y también NULL es posible.

¿Y entonces?

Entonces, como puedes ver, al SELECT de la Consulta 2. le está faltando una comparación. El valor devuelto por el CASE debe ser comparado con algo, no puede quedarse así como está, porque está en el aire y eso está mal. Sea lo que sea que escribamos en el WHERE nos debe devolver verdadero o falso o NULL. Si devuelve cualquier otra cosa (o no devuelve algo) entonces está mal, no funcionará.

Y ese es el error de concepto. Se escribió un WHERE que no devuelve verdadero ni falso ni NULL.

Por lo tanto, un SELECT corregido y sí funcionando sería similar al siguiente:

SELECT
   PER_NOMBRE,
   PER_APELLD
FROM
   PERSONAS
WHERE
   CASE
      WHEN PER_ESTCIV = 1 THEN 'Soltero'
      WHEN PER_ESTCIV = 2 THEN 'Casado'
      WHEN PER_ESTCIV = 3 THEN 'Separado'
      WHEN PER_ESTCIV = 4 THEN 'Divorciado'
      WHEN PER_ESTCIV = 5 THEN 'Viudo'
   END
   = 'Casado'

Que nos devolverá los nombres y apellidos de las personas casadas. Ahora sí el SELECT está completo porque comparamos el valor devuelto por el CASE con algo, entonces ya está todo ok, y funcionará a la perfección.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Consultas con columnas condicionales

2 comentarios

A veces en nuestras consultas necesitamos mostrar columnas cuyos contenidos provienen de otras tablas y además lo hacen en forma condicional.

Ejemplo:

En una tabla MOVIMCAB tenemos una columna llamada MVC_TIPMOV la cual nos indica el tipo de movimiento (‘ECM’ es una entrada por compras, ‘SVT’ es una salida por ventas, etc.) y donde también guardamos el Identificador del Proveedor (cuando se trata de una compra) o el Identificador del Cliente (cuando se trata de una venta).

Ahora, necesitamos una consulta que nos muestre el nombre del Proveedor o el nombre del Cliente, según corresponda. Para ello haremos uso de la construcción CASE … WHEN … END

SELECT
   MVC_FECHAX,
   MVC_NRODOC,
   MVC_TIPMOV,
   CASE
      WHEN MVC_TIPMOV = 'ECM' THEN (SELECT PRO_NOMBRE FROM PROVEEDORES WHERE PRO_IDENTI = MVC_IDEPRO)
      WHEN MVC_TIPMOV = 'SVT' THEN (SELECT CLI_NOMBRE FROM CLIENTES    WHERE CLI_IDENTI = MVC_IDECLI)
   END AS NOMBRE
FROM
   MOVIMCAB
WHERE
   MVC_TIPMOV IN ('ECM', 'SVT')

Y este es el resultado (parcial, por supuesto) que obtuvimos:

CONDICIONAL1

Captura 1. Si haces clic en la imagen la verás más grande

Como puedes ver, en la columna NOMBRE tenemos el nombre de un Proveedor (cuando se trata de una compra) o el nombre de un Cliente (cuando se trata de una venta). Y para saber de cual de ellos se trata podemos mirar el contenido de la columna MVC_TIPMOV.

ERROR: Multiple rows in singleton select

Si ves ese mensaje de error significa que el SELECT interno devolvió más de una fila pero debería haber devuelto solamente una fila (o ninguna, pero jamás más de una).

¿Cuál es el problema?

Que si el SELECT devuelve varias filas el Firebird no puede saber cual de esas filas es la correcta. Por ejemplo, si el SELECT devuelve el nombre de 500 clientes ¿cuál de esos 500 nombres es el que debe mostrar? imposible que el Firebird pueda saberlo y por lo tanto te muestra un mensaje de error.

Para evitar el error siempre tienes que asegurarte que la condición que pusiste en la cláusula WHERE limite el resultado a una sola fila.

En el ejemplo de arriba se usó el Identificador del Proveedor o del Cliente. Como esos identificadores son únicos y jamás pueden repetirse entonces estamos seguros de que jamás obtendremos el error “multiple rows in singleton select”. Sin embargo cuando no usas identificadores ni claves primarias ni claves únicas la posibilidad de encontrar ese error siempre existirá.

Artículo relacionado:

El índice del blog Firebird21

DECODE()

1 comentario

Descripción: Es una forma abreviada de escribir el “CASE simple” en el cual una expresión es comparada con varias otras expresiones hasta que una coincidencia es encontrada. El resultado es determinado por el valor que se encuentra después de la expresión coincidente. Si no se encuentra una coincidencia el valor por defecto es devuelto. Y si no hay valor por defecto, NULL es devuelto.

Tipo de resultado: Varía

Sintaxis:

DECODE(<expresión_a_examinar>,

<expresión>, resultado

[, <expresión>, resultado …]

[, <resultado_por_defecto>])

El CASE simple equivalente sería:

CASE <expresión_a_examinar>

WHEN <expresión> THEN resultado

[WHEN <expresión> THEN resultado …]

[ELSE resultado_por_defecto]

END

Aviso: Las coincidencias son hechas con el operador “=”, así que si la expresión_a_examinar es NULL, no habrá coincidencia con ninguna <expresión>, ni siquiera con aquellas que sean NULL

Ejemplo:

SELECT
   MVC_FECHAX,
   DECODE(MVC_TIPMOV,
      'ECM', 'Compra',
      'SVT', 'Venta',
      'COB', 'Cobranza',
      'PAG', 'Pago',
      'Desconocido'),
   DECODE(MVC_TIPDOC,
      'FCO', 'Factura contado',
      'FCR', 'Factura crédito',
      'Desconocido'),
   MVC_NRODOC,
   DECODE(MVC_MONEDA,
      0, 'Moneda local',
      1, 'Dólares',
      2, 'Euros',
      3, 'Libras esterlinas',
      4, 'Yenes')
FROM
   MOVIMCAB