CREATE PROCEDURE NVL(a CHAR(32), b CHAR(32) DEFAULT NULL,
c CHAR(32) DEFAULT NULL,
d CHAR(32) DEFAULT NULL,
e CHAR(32) DEFAULT NULL,
f CHAR(32) DEFAULT NULL,
g CHAR(32) DEFAULT NULL)
RETURNING CHAR(32);
IF a IS NOT NULL THEN RETURN a;
ELIF b IS NOT NULL THEN RETURN b;
ELIF c IS NOT NULL THEN RETURN c;
ELIF d IS NOT NULL THEN RETURN d;
ELIF e IS NOT NULL THEN RETURN e;
ELIF f IS NOT NULL THEN RETURN f;
ELSE RETURN g;
END IF;
END PROCEDURE;
Ou - moins généralement:
-- @(#)$Id: nvl_int.spl,v 1.1 1996/08/26 18:33:11 johnl Exp $
--
-- nvl_integer: return v1 if it is not null else return v2
CREATE PROCEDURE nvl_integer(v1 INTEGER, v2 INTEGER DEFAULT 0)
RETURNING INTEGER;
DEFINE rv INTEGER;
IF v1 IS NOT NULL THEN
LET rv = v1;
ELSE
LET rv = v2;
END IF
RETURN rv;
END PROCEDURE;
La version CHAR peut être utilisé pour presque n'importe quel type (sauf les chaînes de plus de 32, comme écrit) parce que SE est très bon pour convertir entre les types. SE ne prend pas en charge le casting explicite, non plus - il est sûr de supposer que SE n'a pas beaucoup de SQL après SQL-89.
Je ne sais rien sur le sujet mais .. utiliser une base de données différente? :) – stefanB
Huhu, bien sûr, je vais convaincre tout mon supérieur que nous devons utiliser un autre DB parce que je ne suis pas capable de faire un cas? : p –
Non, car la base de données est a) incroyablement obsolète pour ne pas supporter nvl, case ou decode (sans parler des fonctionnalités plus avancées, je suppose) et b) leur coûter (m | b) illions en développement supplémentaire ce qui ont été évités avec probablement toute DB moderne. – l0b0