Discussion :

[HOUDEBINE]

Contexte:
Une table temporaire (qui évolue) et dont l'existence de certaines colonnes est soumise à condition.

Lorsque ces colonnes (conditionnées) existent, elles doivent faire l'objet de contrôles.

Avant d'effectuer le contrôle je m'assure que la colonne existe en utilisant un "if exists " suivi des conditions qui cré la colonne en question. Puis selon que la condition est vrai ou fausse j'adapte mon traitement :si la colone existe, je peux réaliser mon contrôle et je cible le nom de cette colonne. Si c'est non, je ne fait rien puique je sais que la colonne n'existe pas.

Or dans l'hypothèse où la condition n'est pas remplie et donc où normalement le traitement valant pour le cas "oui" ne devrait pas être lu, sql me renvoie le message d'erreur suivant: la colonne x n'existe pas.
Le code est donc lu qqsoit la réponse à la condition posée. Un proche me dit que c'est lors de la compilation qu'sql ne reconnaît pas l'objet inconnu même si à l'exécution le contexte était correct.

L'ennui c'est que je vois pas comment contourné cette contrariété. J'ai essayé de "passer" par un flag. mais rien à faire.

[Xo]

Quel SGBD SVP ?

En vrac, mes impressions sur ton souci :
- Une table, même "temporaire", dont la structure est modifiée régulièrement en fonction des données à traiter ne me paraît pas génial, il y a un problème de conception à revoir. Pourquoi pas plusieurs tables, chacune dédiée à un traitement ? Ou une table contenant toutes les colonnes, certaines étant renseignées ou pas en fonction de la nature du traitement ?
- Si tu ne peux revenir sur ce mécanisme, je te conseillerais, pour écrire des requêtes paramétrables, de passer par un langage procédural (propre au SGBD ou pas) qui aurait pour tâche de contruire la requête.