Comment peut-I du programme, vérifier (parse) la validité d'une instruction TSQL?

Je suis en train de faire mes tests d'intégration plus idempotent. Une idée est d'exécuter la restauration après chaque test, l'autre idée était d'une certaine façon par programmation à l'analyse du texte, semblable à la case à cocher verte dans l'Analyseur de Requêtes ou de SSMS.

Comment puis-je obtenir SQL Server pour analyser ma commande sans l'exécuter à l'aide de ADO.NET?

Mise à JOUR:
C'est ce qui a finalement fonctionné comme souhaité:

using (DbCommand executeOnly = Factory.DbCommand())
{
    executeOnly.Connection = command.Connection;
    executeOnly.CommandType = CommandType.Text;
    executeOnly.CommandText = "SET NOEXEC ON;" + sqlCommand;
    executeOnly.Connection.Open();
    executeOnly.ExecuteNonQuery();
}
//set more properties of command.
command.Execute();

Pour des raisons inexplicables, "SET PARSEONLY ON" n'a travaillé que dans l'Analyseur de Requêtes. Je ne pouvais pas définir ce sur une ADO.NET connexion. Il est tout aussi bien parce que PARSEONLY semble à attraper les erreurs de syntaxe, ce qui n'est pas une erreur commune. SET NOEXEC ON va attraper un plus large variétés d'erreurs, par exemple une vue qui fait référence à un manque de table ou de colonne ou la disparition d'un paramètre dans une procédure stockée.

  • Question intéressante en effet
  • Je suis en supposant que c'est executeOnly.CommandText = "SET NOEXEC ON; " + sqlCommand; :3
InformationsquelleAutor MatthewMartin | 2010-06-21
  1. 37

    Je pense que la commande que vous cherchez est SET NOEXEC on. Si vous définissez pour votre connexion, les requêtes seront analysés, mais ne sera pas exécuté. Une autre option serait SET PARSEONLY ON, mais je suis franchement pas sûr de ce que la différence entre les deux est vraiment.

    InformationsquelleAutor Eric Petroelje
  2. 21

    +1 à Eric réponse. Mais j'ai trouvé SET FMTONLY ON également être utile comme SET NOEXEC ON ne semble pas jeter toutes les erreurs.

    par exemple

    SELECT * FROM ATableThatDoesNotExist

    En cours d'exécution qui avec SET NOEXEC ON dit qu'il a réussi, en dépit de la table n'existant pas dans la base de données. L'exécution avec SET FMTONLY ON au lieu de cela, va jeter le "nom d'objet non Valide" erreur.

    FMTONLY SET SUR retourne également des métadonnées sur le jeu de résultats qui seraient retournés, ce qui peut s'avérer très utile

    • J'obtiens une erreur lors de l'utilisation de SET NOEXEC ON et SELECT * FROM ATableThatDoesNotExist
    • Je n'ai pas d'erreur dans SQL2005 ou SQL2008
    • Même comme Martin, je n'ai pas d'erreur non plus :/
    • Toutes mes excuses je n'avais pas l'essentiel "ALLER" entre mes SET NOEXEC ON et la SELECT
    • Je n'ai pas utilisé un ALLER, j'ai juste couru le SET NOEXEC ON et a obtenu le Command(s) completed successfully. message, puis l'exécution de la requête, qui produit alors de l'erreur. Si vous exécutez le SET NOEXEC ON;SELECT... vous n'obtenez pas de message d'erreur. Par buter un GO entre la SRET et la SÉLECTIONNER donnera l'erreur
    • Aha. Pour moi, sur SQL Server 2008 RTM I jamais obtenez le message d'erreur. Cependant, quand je l'ai essayer sur SQL Server 2005, il ne se comporter comme vous le dites quand vous avez de l'instruction GO dans. Lorsque vous essayez de l'année 2005? Bizarre le comportement a changé
    • +1 pour FMTONLY SET SUR retourne également des métadonnées sur le jeu de résultats. C'est vraiment utile en dépannage sans l'exécution de la véritable instruction SQL, spécialement pour un dev assurance de la qualité des environnements 🙂

    InformationsquelleAutor AdaTheDev
  3. 8

    SQL Server 2012 peut analyser votre syntaxe, les procédures et les tables avec le système suivant des procédures et fonctions:

    Qu'ils sont censés remplacer "FMTONLY SET".

    J'ai testé et ils travaillent beaucoup mieux que "MIS à NOEXEC" et "SET PARSEONLY SUR"

    Exemples:

    Ne sera pas jeter une erreur:

    sp_describe_undeclared_parameters
    @tsql = N'SELECT object_id, name, type_desc FROM sys.indexes;'

    Correctement jeter une erreur ("SET NOEXEC" et "SET PARSEONLY" ne jetez pas une erreur dans ce cas):

    sp_describe_undeclared_parameters 
  @tsql = N'SELECT object_id, name, type_desc FROM sys.indexes;SELECT object_id, name, type_desc FROM sys.NOTaTABLE;'
    InformationsquelleAutor Jarle Bjørnbeth
  4. 7

    Utiliser la requête suivante

    SET PARSEONLY ON
--Your query here
SET PARSEONLY OFF
    InformationsquelleAutor Ralf de Kleine
  5. 6

    SET PARSEONLY : Examine la syntaxe de chaque instruction Transact-SQL et retourne un message d'erreur, sans la compilation ou à l'exécution de l'instruction.

    • C'est ce que SSM est en train de faire lorsque vous appuyez sur la case à cocher verte. Vous pouvez facilement voir arriver dans le générateur de profils SQL.
    InformationsquelleAutor Pranay Rana
  6. 6

    Vraiment cela dépend de la finalité des tests.

    Le moyen le plus fiable serait d'utiliser la restauration après chaque test si vos déclarations prêtent à qui (n'est-ce pas trop lourd à rendre viable).

    Je l'ai fait dans le passé et ont été heureux d'être informé de l'exécution des questions que je n'aurais pas pris de toute autre manière.

    • +1 - je suis d'accord. Vraiment exécution de l'instruction et de faire une restauration après va être le moyen le plus fiable pour tester.
    • +1: SET NOEXEC ON est seulement la vérification de la requête en cours de validité. Une requête peut être valable, mais pas de retour des résultats corrects.
    InformationsquelleAutor Martin Smith
  7. 4

    VSTSDBPro a un analyseur de requête vous pouvez accéder par programmation: http://blogs.msdn.com/b/gertd/archive/2008/08/21/getting-to-the-crown-jewels.aspx

    InformationsquelleAutor Robert L Davis