Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
J'ai constaté un comportement qui me semble troublant en voulant récupérer des données, dont certaines à NULL:
Si le curseur rencontre un champ NULL alors que le précèdent enregistrement ne l'était pas, le champ courant contient encore la valeur du champ précédent :
Exemple sur une table test :
john (null)
paul smith
marilyn (null)
Résultat : (entre parenthèse la valeur de l'indicateur)
john (0) (-1)
paul (0) smith (0)
marilyn (0) smith (-1)
Je me doute qu'il faut utiliser la valeur de l'indicateur mais ce comportement me parait troublant, je suis sur une migration informix ->pg et le champ reste bien à NULL comme le montre l'éxécution avec ce dernier :
john (0) (-1)
paul (0) smith (0)
marilyn (0) (-1)
Cela se produit aussi bien en bpchar qu'en varchar
Source du programme :
CREATE TABLE test
(
a character varying(9),
b character varying(9)
)main() {
EXEC SQL BEGIN DECLARE SECTION;
char a[10];
char b[10];
int a_ind;
int b_ind;
EXEC SQL END DECLARE SECTION;
...
EXEC SQL DECLARE foo CURSOR FOR SELECT a, b FROM test;
EXEC SQL OPEN foo;
EXEC SQL FETCH FROM foo INTO :a :a_ind, :b :b_ind;
while (sqlca.sqlcode == 0) {
printf("%s(%d) %s(%d)\n", a, a_ind, b, b_ind);
EXEC SQL FETCH FROM foo INTO :a :a_ind, :b :b_ind;
}
EXEC SQL CLOSE foo;
EXEC SQL DISCONNECT ALL;
return EXIT_SUCCESS;
}VERSION = PostgreSQL 8.4.1
Hors ligne
Il ne faut pas se fier à la valeur de la variable si l'indicateur indique que la valeur est NULL. Quelle autre valeur pourrais avoir la variable ? une chaîne vide ? mais en SQL une chaîne vide n'est pas une chaîne NULL. Le développeur d'ecpg, Michael Meske, a dû se dire qu'il n'était pas nécessaire de modifier la variable si l'indicateur précisait bien que la valeur était NULL.
Guillaume.
Hors ligne
Dommage pour la compatibilité avec le code informix existant...
Je persiste néanmoins à penser que le comportement est piégeux.
Merci de la réponse
Hors ligne
J'avoue que je ne comprends pas. Que renvoie le code avec Informix ? une chaîne vide ?
Guillaume.
Hors ligne
Oui, informix renvoie une chaine vide.
En outre le mode de compatibilité informix (ecpg -C INFORMIX) ne change rien au problème.
Hors ligne
Tester une chaîne vide ne fournit aucune information car l'état NULL n'est pas équivalent à une chaîne vide. Donc, de toute façon, vous étiez déjà obligé de passer par l'indicateur pour détecter si c'était ou pas un NULL.
Guillaume.
Hors ligne
Sous informix aucune idée, mais sous Oracle, une chaine vide ou null, c'est pareil. Pas que ça soit bien, mais il faut le savoir, ça fait partie des bizarreries oracle.
Marc.
Hors ligne
Ce qui me perturbe c'est que la variable reçoive une mauvaise valeur par effet de bord (sur l'exemple la troisième ligne reçoit la valeur de la deuxième).
Du coup l'utilisation des indicateurs est plus que nécessaire effectivement.
Hors ligne
La valeur de la variable n'est pas initialisée, puisque vous n'êtes pas censé regarder ce qui se trouve dedans. Donc oui, il se peut que vous retrouviez le contenu d'une autre variable dans la zone mémoire dans laquelle vous regardez, mais c'est autant le fait de la librairie qui n'initialise pas une zone mémoire que vous ne devez pas regarder, que le fait que la zone mémoire a été réutilisée entre 2 appels à la même fonction, et c'est comme cela que fonctionnent tous les programmes en C.
Marc.
Hors ligne
Tout à fait, comme vous le dites il s'agit ici d'une API, dans un contexte un peu plus balisé qu'un simple programme C.
Alors bien sur qu'il faut utiliser les indicateurs pour tester la valeur NULL d'une variable (la doc indique que la valeur est ignorée, cela va donc dans ce sens), mais moi je dis que ca ne mangerait pas de pain d'initialiser a chaine vide (stratégie classique : ceinture et bretelles 
).
Hors ligne
Pages : 1