SQL Server signale "nom de colonne non valide" , mais la colonne est présente et la requête fonctionne via management studio
Je suis dans une impasse. J'ai une requête qui est générée par un code C#. La requête fonctionne bien dans Microsoft SQL Server Management Studio lorsqu'elle est exécutée sur la même base de données.
Cependant, lorsque mon code essaie d'exécuter la même requête, j'obtiens la même erreur sur une colonne invalide et une exception est levée. Toutes les requêtes qui font référence à cette colonne échouent.
La colonne en question a été récemment ajoutée à la base de données. C'est une colonne de date appelée Incident_Begin_Time_ts .
Un exemple qui échoue est:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
D'autres requêtes comme Select MAX(Incident_Being_Time_ts); échouent également lorsqu'elles sont exécutées dans le code car elles pensent que la colonne est manquante.
Des idées?
7 réponses
Je soupçonne que vous avez deux tables avec le même nom. L'un est la propriété du schéma ' dbo '(dbo.PerfDiag), et l'autre est la propriété du schéma par défaut du compte utilisé pour se connecter à SQL Server (quelque chose comme userid.PerfDiag).
Lorsque vous avez une référence non qualifiée à un objet de schéma ( comme une table) - une référence non qualifiée par nom de schéma-la référence d'objet doit être résolue. La résolution de nom se produit en recherchant dans l'ordre suivant un objet du type approprié (table) avec le nom spécifié. Le nom se résout à la première correspondance:
- Sous le schéma par défaut de l'utilisateur.
- Sous le schéma "dbo".
La référence non qualifiée est liée à la première correspondance dans la séquence ci-dessus.
Comme pratique générale recommandée, il faut toujours qualifier les références aux objets de schéma, pour des raisons de performance:
Une référence non qualifiée peut invalider un plan d'exécution mis en cache pour la procédure ou la requête stockée, puisque le schéma auquel la référence a été liée peut changer en fonction des informations d'identification exécutant la procédure ou la requête stockée. Il en résulte une recompilation de la procédure de requête / stockée, un succès de performance. Les Recompilations provoquent la suppression des verrous de compilation, empêchant les autres d'accéder aux ressources nécessaires.
La résolution des noms ralentit l'exécution de la requête car deux sondes doivent être effectuées pour résoudre la version probable de l'objet (celle appartenant à 'dbo'). C'est l'habitude cas. La seule fois où une seule sonde résoudra le nom est si l'utilisateur actuel possède un objet du nom et du type spécifiés.
[modifié pour ajouter une note]
Autres possibilités sont (sans ordre particulier):
- vous n'êtes pas connecté à la base de données que vous pensez être.
- vous n'êtes pas connecté à L'instance SQL Server que vous pensez être.
Vérifiez vos chaînes de connexion et assurez-vous qu'elles spécifient explicitement le serveur SQL nom de l'instance et le nom de base de données.
Appuyez Simplement sur Ctrl + Maj + R et voir...
Dans SQL Server Management Studio, Ctrl + Maj + R actualise le cache local.
Si vous exécutez ceci dans une transaction et une instruction SQL avant que cela ne supprime / modifie la table, vous pouvez également obtenir ce message.
Si vous utilisez des variables portant le même nom que votre colonne, il se peut que vous ayez oublié le marqueur de variable'@'. Dans une instruction INSERT, il sera détecté en tant que colonne.
Juste eu exactement le même problème. J'ai renommé des colonnes aliasées dans une table temporaire qui est ensuite utilisée par une autre partie du même code. Pour une raison quelconque, cela n'a pas été capturé par SQL Server Management Studio et il s'est plaint de noms de colonnes non valides.
Ce que j'ai simplement fait est de créer une nouvelle requête, copier coller le code SQL de l'ancienne requête à cette nouvelle requête et l'exécuter à nouveau. Cela semblait rafraîchir l'environnement correctement.
J'ai finalement arrêté et redémarré Microsoft SQL Server Management Studio; et cela l'a corrigé pour moi. Mais à d'autres moments, il suffisait de commencer une nouvelle fenêtre de requête.
Dans mon cas, j'essayais d'obtenir la valeur d'un jeu de résultats erroné lors de l'interrogation de plusieurs instructions SQL.