Comment fonctionne exactement sp_msforeachdb dans les coulisses?

9

J'ai besoin de résoudre un problème que j'ai et j'ai besoin d'aide pour comprendre comment fonctionne sp_msforeachdb afin de surmonter mon problème.

Ce qui se passe est chaque fois que j'exécute sp_msforeachdb, j'obtiens une erreur Msg 102, Level 15, State 1, Incorrect syntax near '61'

Un exemple de mon code est le suivant:

EXEC SP_msforeachdb 'SELECT ''?'' AS Database
                     FROM ?.sys.objects
                     WHERE name like ''%aetna%''

Cependant, peu importe la requête que j'ai comme paramètre pour sp_msforeachdb. Chaque fois que je reçois la même erreur. J'ai une base de données qui commence par '61s1d', ce qui me fait penser qu'il y a un problème avec le nom de la base de données, mais honnêtement, je ne sais pas ce qui se passe dans les coulisses sur sp_msforeachdb.

À noter.

C'est la seule base de données qui commence par un nombre
Je peux essayer d'utiliser du code comme "Si la base de données est comme '% 61%' ne faites pas ......", mais toujours la même erreur.
Je ne peux pas tester la modification du nom de la base de données - trop de choses y sont connectées.
Si je crée une base de données de test qui commence par «51», j'obtiens également l'erreur pour cette base de données

Comment puis-je surmonter cela?

sql-server t-sql stored-procedures

— Jeff.Clark
source

16

Tout d'abord, n'utilisez pas sp_msforeachdb, il a plusieurs problèmes connus. Il vaut mieux utiliser la version d'Aaron Bertrand .

Cependant, il utilise un curseur, du SQL dynamique et un remplacement. Vous pouvez réellement regarder le code en utilisant sp_helptext.

EXEC sp_helptext sp_msforeachdb

Si vous utilisez ce code, il résoudra certains de vos problèmes.

EXEC SP_msforeachdb 'SELECT ''?'' AS Database
                 FROM [?].sys.objects
                 WHERE name like ''%aetna%''

Les crochets seront le problème spécifique que vous avez mentionné. Vous rencontrerez cependant des problèmes si vous avez une base de données contenant [ou].

— Kenneth Fisher
source

Intéressant, en utilisant des crochets autour du "?" dans le a travaillé. J'examinerai la version d'Aaron Bertrand. Avez-vous remarqué une dégradation significative des performances à cause du curseur?

— Jeff.Clark

2

Les curseurs ne sont un réel problème de performances que lorsque vous disposez de plusieurs lignes. À moins que vous ne vous rapprochiez du nombre maximal de bases de données autorisées, vous ne verrez pas de problème. Le problème est qu'il peut ignorer les bases de données. Lisez l'article d'Aaron et il va plus en détail.

— Kenneth Fisher

1

Je l'ai vu sauter complètement les bases de données à plusieurs reprises. Utilisez Aaron, c'est beaucoup plus fiable.

— Kris Gruttemeyer

11

Je ne suis pas en désaccord avec tout ce que @Kenneth a dit, je dois souligner que l'erreur que vous rencontrez n'a rien à voir avec sp_MSForEachDB. Cela est dû au nom de la base de données: elle commence par un nombre. Les règles pour nommer les objets (pas seulement les bases de données) sont détaillées dans la page MSDN pour les identificateurs de base de données . Si vous suivez les "Règles pour les identifiants réguliers", vous n'avez pas besoin de mettre ces noms entre crochets ou entre guillemets. Mais les noms qui ne relèvent pas de ces règles ne doivent être inclus (toujours).

— Solomon Rutzky
source

1

Merci aussi pour cette info - je n'étais pas au courant de cette restriction. Malheureusement, cette base de données a été

— créée

@ Jeff.Clark Je ne proposais pas que vous renommiez la base de données comme vous l'avez mentionné dans la question que vous ne pouvez pas la changer. Je voulais juste que vous (et d'autres) connaissiez le problème réel car il reviendra à chaque fois que vous devrez spécifier ce nom de base de données n'importe où. Et la lecture de cet ensemble complet de règles peut vous aider à éviter les autres choses qui nécessiteront qu'un nom - Base de données, Table, Colonne, Index, Contrainte, etc. - soit toujours placé entre crochets ou entre guillemets.

— Solomon Rutzky