Présentation du Fournisseur Microsoft OLE DB pour SQL Server

Le fournisseur Microsoft OLE DB pour SQL Server, SQLOLEDB, permet à ADO d’accéder à Microsoft SQL Server.

Paramètres de chaîne de connexion

Pour vous connecter à ce fournisseur, définissez l’argument Fournisseur sur la propriété ConnectionString sur :

SQLOLEDB

Cette valeur peut également être définie ou lue à l’aide de la propriété Provider.

Chaîne de connexion typique

Une chaîne de connexion classique pour ce fournisseur est la suivante :

"Provider=SQLOLEDB;Data Source=serverName;"
Initial Catalog=databaseName;
User ID=MyUserID;Password=MyPassword;"

La chaîne se compose des mots clés suivants :

Chaîne de connexion spécifique au fournisseur.

Le fournisseur prend en charge plusieurs paramètres de connexion spécifiques au fournisseur en plus de ceux définis par ADO. Comme avec les propriétés de connexion ADO, ces propriétés spécifiques au fournisseur peuvent être définies via la collection Propriétés d’une connexion ou peuvent être définies dans le cadre de ConnectionString.

Utilisation de l’objet Command

SQLOLEDB accepte un amalgame d’ODBC, ANSI et SQL Server-spécifique à Transact-SQL comme syntaxe valide. Par exemple, l'instruction SQL suivante utilise une séquence d'échappement ODBC SQL pour spécifier la fonction de chaîne LCASE :

SELECT customerid={fn LCASE(CustomerID)} FROM Customers

LCASE retourne une chaîne de caractères, en convertissant toutes les majuscules en leurs équivalents minuscules. La fonction de chaîne ANSI SQL LOWER effectue la même opération, si bien que l'instruction SQL suivante correspond à l'équivalent ANSI de l'instruction ODBC présentée ci-dessus :

SELECT customerid=LOWER(CustomerID) FROM Customers

SQLOLEDB traite correctement chaque forme de l’instruction quand elle est spécifiée en tant que texte pour une commande.

Procédures stockées

Quand vous exécutez une procédure stockée en utilisant une commande SQLOLEDB, utilisez la séquence d’appel de procédure d’échappement ODBC dans le texte de la commande. SQLOLEDB utilise alors le mécanisme d’appel de procédure distante de SQL Server pour optimiser le traitement des commandes. Par exemple, l’instruction ODBC SQL suivante est préférable à la forme Transact-SQL :

ODBC SQL

{call SalesByCategory('Produce', '1995')}

Transact-SQL

EXECUTE SalesByCategory 'Produce', '1995'

Fonctionnalités DE SQL Server

Avec SQL Server, ADO peut utiliser XML pour l’entrée de commande et récupérer les résultats au format de flux XML au lieu d’objets Recordset. Pour plus d’informations, consultez Utilisation de flux pour l’entrée de commande et la récupération des ensembles de résultats dans des flux.

Accès aux données sql_variant à l’aide de MDAC 2.7, MDAC 2.8 ou Windows DAC 6.0

Microsoft SQL Server a un type de données appelé sql_variant. Comme pour le DBTYPE_VARIANT d’OLE DB, le type de données sql_variant peut stocker des données de plusieurs types différents. Toutefois, il existe quelques différences clés entre DBTYPE_VARIANT et sql_variant. ADO gère également les données stockées en tant que valeur sql_variant différemment de la façon dont elles gèrent d’autres types de données. La liste suivante décrit les problèmes à prendre en compte lorsque vous accédez SQL Server données stockées dans des colonnes de type sql_variant.

• Dans MDAC 2.7, MDAC 2.8 et Windows Data Access Components (Windows DAC) 6.0, le fournisseur OLE DB pour SQL Server prend en charge le type sql_variant. Le fournisseur OLE DB pour ODBC ne le fait pas.

• Le type sql_variant ne correspond pas exactement au type de données DBTYPE_VARIANT . Le type sql_variant prend en charge quelques sous-types non pris en charge par DBTYPE_VARIANT, y compris les chaînes GUID, ANSI (non UNICODE) et BIGINT. L’utilisation de sous-types autres que ceux répertoriés précédemment fonctionne correctement.

• Le sous-type NUMERICsql_variant ne correspond pas au DBTYPE_DECIMAL en taille.

• Plusieurs contraintes de type de données entraînent des types qui ne correspondent pas. Par exemple, le coérage d’un sql_variant avec un sous-type de GUID vers un DBTYPE_VARIANT entraîne un sous-type de safearray(octets). La conversion de ce type en sql_variant entraîne un nouveau sous-type de tableau(octets).

• Les champs recordset qui contiennent sql_variant données peuvent être distants (marshalés) ou conservés uniquement si le sql_variant contient des sous-types spécifiques. Les tentatives de données distantes ou persistantes avec les sous-types non pris en charge suivants entraînent une erreur d’exécution (conversion non prise en charge) à partir du fournisseur de persistance Microsoft (MSPersist) : VT_VARIANT, VT_RECORD, VT_ILLEGAL, VT_UNKNOWN, VT_BSTR et VT_DISPATCH.

• Le fournisseur OLE DB pour SQL Server dans MDAC 2.7, MDAC 2.8 et Windows DAC 6.0 possède une propriété dynamique appelée Allow Native Variants, qui, comme le nom l’implique, permet aux développeurs d’accéder au sql_variant dans sa forme native par opposition à un DBTYPE_VARIANT. Si cette propriété est définie et qu’un jeu d’enregistrements est ouvert avec le moteur de curseur client (adUseClient), l’appel Recordset.Open échoue. Si cette propriété est définie et qu’un jeu d’enregistrements est ouvert avec des curseurs de serveur (adUseServer), l’appel Recordset.Open réussit, mais l’accès aux colonnes de type sql_variant génère une erreur.

• Dans les applications clientes qui utilisent MDAC 2.5, sql_variant données peuvent être utilisées avec des requêtes sur Microsoft SQL Server. Toutefois, les valeurs des données sql_variant sont traitées comme des chaînes. Ces applications clientes doivent être mises à niveau vers MDAC 2.7, MDAC 2.8 ou Windows DAC 6.0.

Comportement de recordset

SQLOLEDB ne peut pas utiliser de curseurs SQL Server pour prendre en charge les résultats comprenant plusieurs ensembles de lignes générés par de nombreuses commandes. Lorsqu'un consommateur demande un recordset qui requiert la prise en charge de curseurs SQL Server, une erreur se produit si le texte de commande génère plusieurs ensembles de lignes comme résultat.

Les jeux d’enregistrements SQLOLEDB pouvant faire défiler sont pris en charge par SQL Server curseurs. SQL Server impose des limitations aux curseurs qui sont sensibles aux modifications effectuées par d'autres utilisateurs de la base de données. Plus précisément, les lignes de certains curseurs ne peuvent pas être ordonnées et la tentative de création d’un jeu d’enregistrements à l’aide d’une commande contenant une clause SQL ORDER BY peut échouer.

Propriétés dynamiques

Le fournisseur Microsoft OLE DB pour SQL Server insère plusieurs propriétés dynamiques dans la collection Properties des objets Connection, Recordset et Command non ouverts.

Les tableaux suivants sont des index croisés des noms ADO et OLE DB de chaque propriété dynamique. La Référence du programmeur OLE DB fait référence à un nom de propriété ADO par le terme « Description ». Vous trouverez de plus amples informations sur ces propriétés dans la référence du programmeur OLE DB. Recherchez le nom de la propriété OLE DB dans l’index ou consultez l’Annexe C : Propriétés OLE DB.

Propriétés dynamiques de connexion

Les propriétés suivantes sont ajoutées à la collection Properties de l’objet Connection.

Propriétés dynamiques du recordset

Les propriétés suivantes sont ajoutées à la collection Properties de l’objet Recordset.

Propriétés dynamiques de la commande

Les propriétés suivantes sont ajoutées à la collection Properties de l’objet Command.

Pour plus d’informations sur l’implémentation spécifique et les informations fonctionnelles sur le fournisseur Microsoft SQL Server OLE DB, consultez le fournisseur SQL Server.

Voir aussi

ConnectionString, propriété (ADO)Provider, propriété (ADO)Recordset, objet (ADO)