Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’API ODBC définit l’exécution préparée comme moyen de réduire la surcharge d’analyse et de compilation associée à l’exécution répétée d’une instruction Transact-SQL. L’application génère une chaîne de caractères contenant une instruction SQL, puis l’exécute en deux étapes. Il appelle la fonction SQLPrepare une fois pour que l’instruction soit analysée et compilée dans un plan d’exécution par le moteur de base de données. Il appelle ensuite SQLExecute pour chaque exécution du plan d’exécution préparé. Cela permet d’enregistrer la surcharge d’analyse et de compilation sur chaque exécution. L’exécution préparée est couramment utilisée par les applications pour exécuter à plusieurs reprises la même instruction SQL paramétrable.
Pour la plupart des bases de données, l’exécution préparée est plus rapide que l’exécution directe pour les instructions exécutées plus de trois ou quatre fois principalement parce que l’instruction n’est compilée qu’une seule fois, tandis que les instructions exécutées directement sont compilées chaque fois qu’elles sont exécutées. L’exécution préparée peut également fournir une réduction du trafic réseau, car le pilote peut envoyer un identificateur de plan d’exécution et les valeurs de paramètre, plutôt qu’une instruction SQL entière, à la source de données chaque fois que l’instruction est exécutée.
SQL Server réduit la différence de performances entre l’exécution directe et préparée grâce à des algorithmes améliorés pour détecter et réutiliser des plans d’exécution à partir de SQLExecDirect. Cela rend certains des avantages en matière de performances de l’exécution préparée disponibles pour les instructions exécutées directement. Pour plus d’informations, consultez Exécution directe.
SQL Server fournit également une prise en charge native de l’exécution préparée. Un plan d’exécution est basé sur SQLPrepare et plus tard exécuté lorsque SQLExecute est appelé. Étant donné que SQL Server n’est pas nécessaire pour générer des procédures stockées temporaires sur SQLPrepare, il n’existe aucune surcharge supplémentaire sur les tables système dans tempdb.
Pour des raisons de performances, la préparation de l’instruction est différée jusqu’à ce que SQLExecute soit appelée ou qu’une opération de métapropriété (par exemple, SQLDescribeCol ou SQLDescribeParam dans ODBC) soit effectuée. Il s’agit du comportement par défaut. Les erreurs dans l’instruction en cours de préparation ne sont pas connues tant que l’instruction n’est pas exécutée ou qu’une opération de métapropriété n’est pas effectuée. La définition de l’attribut d’instruction ODBC SQL Server Native Client SQL_SOPT_SS_DEFER_PREPARE sur SQL_DP_OFF peut désactiver ce comportement par défaut.
En cas de préparation différée, l’appel de SQLDescribeCol ou SQLDescribeParam avant d’appeler SQLExecute génère un aller-retour supplémentaire vers le serveur. Sur SQLDescribeCol, le pilote supprime la clause WHERE de la requête et l’envoie au serveur avec SET FMTONLY ON pour obtenir la description des colonnes dans le premier jeu de résultats retourné par la requête. Sur SQLDescribeParam, le pilote appelle le serveur pour obtenir une description des expressions ou des colonnes référencées par les marqueurs de paramètres de la requête. Cette méthode a également certaines restrictions, telles que l’impossibilité de résoudre les paramètres dans les sous-requêtes.
L’utilisation excessive de SQLPrepare avec le pilote ODBC SQL Server Native Client dégrade les performances, en particulier lorsqu’il est connecté à des versions antérieures de SQL Server. L’exécution préparée ne doit pas être utilisée pour les instructions exécutées une seule fois. L’exécution préparée est plus lente que l’exécution directe pour une seule exécution d’une instruction, car elle nécessite un aller-retour réseau supplémentaire du client vers le serveur. Sur les versions antérieures de SQL Server, elle génère également une procédure stockée temporaire.
Les instructions préparées ne peuvent pas être utilisées pour créer des objets temporaires sur SQL Server.
Certaines premières applications ODBC utilisent SQLPrepare à tout moment que SQLBindParameter a été utilisé. SQLBindParameter ne nécessite pas l’utilisation de SQLPrepare, elle peut être utilisée avec SQLExecDirect. Par exemple, utilisez SQLExecDirect avec SQLBindParameter pour récupérer le code de retour ou les paramètres de sortie d’une procédure stockée qui n’est exécutée qu’une seule fois. N’utilisez pas SQLPrepare avec SQLBindParameter , sauf si la même instruction sera exécutée plusieurs fois.