Re : Je n'arrive pas à croire qu'il s'agisse d'un bug

rkusenet a écrit : > IDS 9.21.UC4 sous Solaris 2.6 > > Regardez ce code : > > select pnr_locator > from ftravel_tr4@ifmx_flx:pnr_info > where pnr_locator not in > (select pnr from rpt_table where dep_date > TODAY-331) > and pnr_locator not in > (select pnr_locator from pnr_status where pnrstat = 'A') > ^^^^^^^^^^^ > > il s'agit d'une faute de frappe. Il n'existe aucun champ pnr_locator dans la table > pnr_status. Le nom correct de la colonne est pnr. Malheureusement, ce n'est pas un bug, c'est une fonctionnalité. De SQL, pas d'Informix. Qu'est-ce qui vous fait penser que le pnr_locator indiqué ne sera recherché que dans pnr_status ? Vous avez manifestement une colonne pnr_locator dans pnr_info, qui est la table du select de premier niveau. Les sous-requêtes corrélées ne peuvent fonctionner que parce que l'analyseur prend en compte la « portée » des colonnes. À l'intérieur du sous-select, toutes les tables listées sont disponibles pour faire correspondre une colonne ! C'est la raison pour laquelle je ALWAYS, je veux dire, je ALWAYS mets table.colonne pour EVERY nom de colonne. Si vous aviez écrit pnr_status.pnr_locator dans le select imbriqué, vous auriez découvert le problème immédiatement. Malheureusement, bien que votre requête accidentelle soit pratiquement inutile, il n'est pas possible pour l'analyseur de détecter et de signaler les SQL erronés — même si celui-ci était détecté et signalé, il existe tellement de façons de saboter involontairement une requête SQL qu'il n'est pas vraiment raisonnable d'exiger des contrôles de cohérence.