Josber, en el segundo te falta una coma:
Código SQL:
EXEC SQL
FETCH cursor_tabla
INTO :LPNUM /* <== AQUI!!! */
AES_DECRYPT(:LPPRO1,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO2,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO3,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO4,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO5,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO6,'FaCtUrAcIóN')
END-EXEC.
En cuanto a lo de NULL, haces todo bien. El problema es (según he leído), la longitud de los campos encriptados. Es decir, si usas VarChar, debes saber la longitud exacta e indicarsela a la hora de decriptar. Si algo no le cuadra, devuelve NULL:
Cita:
|
❞
The answer is that the columns are binary when they should be varbinary. This article explains it:
Because if AES_DECRYPT() detects invalid data or incorrect padding, it will return NULL.
With binary column types being fixed length, the length of the input value must be known to ensure correct padding. For unknown length values, use varbinary to avoid issues with incorrect padding resulting from differing value lengths.
|
Para indicar la longitud, graba todo con la misma longitud y haz SELECT indicando esa misma longitud. Cómo se declaraban los VarChar en COBOL creo que te lo comenté. Si no te acuerdas, te lo pongo otra vez.
Si no tienes datos muy largos, usa Char
