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.
SQL Server 2005 a introduit la prise en charge de plusieurs jeux de résultats actifs (MARS) dans les applications accédant au moteur de base de données. Dans les versions antérieures de SQL Server, les applications de base de données n’ont pas pu gérer plusieurs instructions actives sur une connexion. Lorsque vous utilisez des jeux de résultats par défaut SQL Server, l’application a dû traiter ou annuler tous les jeux de résultats d’un lot avant de pouvoir exécuter tout autre lot sur cette connexion. SQL Server 2005 a introduit un nouvel attribut de connexion qui permet aux applications d’avoir plusieurs demandes en attente par connexion, et notamment d’avoir plusieurs jeux de résultats actifs par défaut par connexion.
MARS simplifie la conception des applications avec les nouvelles fonctionnalités suivantes :
Les applications peuvent avoir plusieurs jeux de résultats par défaut ouverts et peuvent entrelacer la lecture à partir d’eux.
Les applications peuvent exécuter d’autres instructions (par exemple, INSERT, UPDATE, DELETE et appels de procédure stockée) tandis que les jeux de résultats par défaut sont ouverts.
Les applications utilisant MARS trouveront les instructions suivantes utiles :
Les jeux de résultats par défaut doivent être utilisés pour les jeux de résultats de courte durée ou courts générés par des instructions SQL uniques (SELECT, DML avec OUTPUT, RECEIVE, READ TEXT, etc.).
Les curseurs serveur doivent être utilisés pour des jeux de résultats plus longs ou volumineux générés par des instructions SQL uniques.
Lisez toujours à la fin des résultats pour les demandes procédurales, qu’elles retournent des résultats ou non, et pour les lots qui retournent plusieurs résultats.
Dans la mesure du possible, utilisez les appels d’API pour modifier les propriétés de connexion et gérer les transactions en préférence pour Transact-SQL instructions.
Dans MARS, l’emprunt d’identité délimité à la session est interdit pendant l’exécution de lots simultanés.
Remarque
Par défaut, la fonctionnalité MARS n’est pas activée. Pour utiliser MARS lors de la connexion à SQL Server avec SQL Server Native Client, vous devez l’activer spécifiquement dans une chaîne de connexion. Pour plus d’informations, consultez les sections du fournisseur OLE DB SQL Server Native Client et du pilote ODBC SQL Server Native Client, plus loin dans cette rubrique.
SQL Server Native Client ne limite pas le nombre d’instructions actives sur une connexion.
Les applications classiques qui n’ont pas besoin d’avoir plus d’un seul lot à états multiples ou d’une procédure stockée s’exécutant en même temps bénéficieront de MARS sans avoir à comprendre comment MARS est implémenté. Toutefois, les applications ayant des exigences plus complexes doivent tenir compte de ce problème.
MARS active l’exécution entrelacée de plusieurs requêtes au sein d’une seule connexion. Autrement dit, il permet à un lot d’exécuter, et dans son exécution, il permet à d’autres requêtes d’être exécutées. Notez toutefois que MARS est défini en termes d’entrelacement, pas en termes d’exécution parallèle.
L’infrastructure MARS permet à plusieurs lots d’exécuter de manière entrelacée, même si l’exécution ne peut être basculée qu’à des points bien définis. En outre, la plupart des instructions doivent s’exécuter atomiquement dans un lot. Les instructions qui retournent des lignes au client, parfois appelées points de rendement, sont autorisées à interlacer l’exécution avant l’achèvement tandis que les lignes sont envoyées au client, par exemple :
Sélectionner
CHERCHER
RECEVOIR
Toutes les autres instructions exécutées dans le cadre d’une procédure stockée ou d’un lot doivent s’exécuter jusqu’à la fin avant que l’exécution puisse être basculée vers d’autres requêtes MARS.
La manière exacte dans laquelle les lots entrelacés sont influencés par un certain nombre de facteurs, et il est difficile de prédire la séquence exacte dans laquelle les commandes de plusieurs lots contenant des points de rendement seront exécutées. Veillez à éviter les effets secondaires indésirables en raison de l’exécution entrelacée de ces lots complexes.
Évitez les problèmes en utilisant des appels d’API plutôt que des instructions Transact-SQL pour gérer l’état de connexion (SET, USE) et les transactions (BEGIN TRAN, COMMIT, ROLLBACK) en n’incluant pas ces instructions dans les lots à plusieurs instructions qui contiennent également des points de rendement et en sérialisant l’exécution de ces lots en consommant ou en annulant tous les résultats.
Remarque
Un lot ou une procédure stockée qui démarre une transaction manuelle ou implicite lorsque MARS est activé doit terminer la transaction avant la sortie du lot. Si ce n’est pas le cas, SQL Server restaure toutes les modifications apportées par la transaction lorsque le lot se termine. Une telle transaction est gérée par SQL Server comme transaction par lot. Il s’agit d’un nouveau type de transaction introduit dans SQL Server 2005 pour permettre l’utilisation de procédures stockées bien comportementées existantes lorsque MARS est activé. Pour plus d’informations sur les transactions par lots, consultez Instructions de transaction (Transact-SQL).
Pour obtenir un exemple d’utilisation de MARS à partir d’ADO, consultez Utilisation d’ADO avec SQL Server Native Client.
Fournisseur OLE DB SQL Server Native Client
Le fournisseur OLE DB SQL Server Native Client prend en charge MARS via l’ajout de la propriété d’initialisation de source de données SSPROP_INIT_MARSCONNECTION, qui est implémentée dans le jeu de propriétés DBPROPSET_SQLSERVERDBINIT. En outre, un nouveau mot clé de chaîne de connexion, MarsConntel qu’il a été ajouté. Elle accepte ou false prend true des valeurs ; false est la valeur par défaut.
La propriété de source de données DBPROP_MULTIPLECONNECTIONS par défaut VARIANT_TRUE. Cela signifie que le fournisseur génère plusieurs connexions afin de prendre en charge plusieurs objets de commande et d’ensemble de lignes simultanés. Lorsque MARS est activé, SQL Server Native Client peut prendre en charge plusieurs objets d’ensemble de commandes et d’ensembles de lignes sur une seule connexion. Par conséquent, MULTIPLE_CONNECTIONS est défini sur VARIANT_FALSE par défaut.
Pour plus d’informations sur les améliorations apportées à l’ensemble de propriétés DBPROPSET_SQLSERVERDBINIT, consultez Propriétés d’initialisation et d’autorisation.
Exemple de fournisseur OLE DB SQL Server Native Client
Dans cet exemple, un objet source de données est créé à l’aide du fournisseur OLE DB NATIF SQL Server et MARS est activé à l’aide de la propriété DBPROPSET_SQLSERVERDBINIT définie avant la création de l’objet de session.
#include <sqlncli.h>
IDBInitialize *pIDBInitialize = NULL;
IDBCreateSession *pIDBCreateSession = NULL;
IDBProperties *pIDBProperties = NULL;
// Create the data source object.
hr = CoCreateInstance(CLSID_SQLNCLI10, NULL,
CLSCTX_INPROC_SERVER,
IID_IDBInitialize,
(void**)&pIDBInitialize);
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void**)&pIDBProperties);
// Set the MARS property.
DBPROP rgPropMARS;
// The following is necessary since MARS is off by default.
rgPropMARS.dwPropertyID = SSPROP_INIT_MARSCONNECTION;
rgPropMARS.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMARS.dwStatus = DBPROPSTATUS_OK;
rgPropMARS.colid = DB_NULLID;
V_VT(&(rgPropMARS.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMARS.vValue)) = VARIANT_TRUE;
// Create the structure containing the properties.
DBPROPSET PropSet;
PropSet.rgProperties = &rgPropMARS;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
// Get an IDBProperties pointer and set the initialization properties.
pIDBProperties->SetProperties(1, &PropSet);
pIDBProperties->Release();
// Initialize the data source object.
hr = pIDBInitialize->Initialize();
//Create a session object from a data source object.
IOpenRowset * pIOpenRowset = NULL;
hr = IDBInitialize->QueryInterface(IID_IDBCreateSession, (void**)&pIDBCreateSession));
hr = pIDBCreateSession->CreateSession(
NULL, // pUnkOuter
IID_IOpenRowset, // riid
&pIOpenRowset )); // ppSession
// Create a rowset with a firehose mode cursor.
IRowset *pIRowset = NULL;
DBPROP rgRowsetProperties[2];
// To get a firehose mode cursor request a
// forward only read only rowset.
rgRowsetProperties[0].dwPropertyID = DBPROP_IRowsetLocate;
rgRowsetProperties[0].dwOptions = DBPROPOPTIONS_REQUIRED;
rgRowsetProperties[0].dwStatus = DBPROPSTATUS_OK;
rgRowsetProperties[0].colid = DB_NULLID;
VariantInit(&(rgRowsetProperties[0].vValue));
rgRowsetProperties[0].vValue.vt = VARIANT_BOOL;
rgRowsetProperties[0].vValue.boolVal = VARIANT_FALSE;
rgRowsetProperties[1].dwPropertyID = DBPROP_IRowsetChange;
rgRowsetProperties[1].dwOptions = DBPROPOPTIONS_REQUIRED;
rgRowsetProperties[1].dwStatus = DBPROPSTATUS_OK;
rgRowsetProperties[1].colid = DB_NULLID;
VariantInit(&(rgRowsetProperties[1].vValue));
rgRowsetProperties[1].vValue.vt = VARIANT_BOOL;
rgRowsetProperties[1].vValue.boolVal = VARIANT_FALSE;
DBPROPSET rgRowsetPropSet[1];
rgRowsetPropSet[0].rgProperties = rgRowsetProperties
rgRowsetPropSet[0].cProperties = 2
rgRowsetPropSet[0].guidPropertySet = DBPROPSET_ROWSET;
hr = pIOpenRowset->OpenRowset (NULL,
&TableID,
NULL,
IID_IRowset,
1,
rgRowsetPropSet
(IUnknown**)&pIRowset);
Pilote ODBC SQL Server Native Client
Le pilote ODBC SQL Server Native Client prend en charge MARS via des ajouts aux fonctions SQLSetConnectAttr et SQLGetConnectAttr . SQL_COPT_SS_MARS_ENABLED a été ajouté pour accepter SQL_MARS_ENABLED_YES ou SQL_MARS_ENABLED_NO, avec SQL_MARS_ENABLED_NO étant la valeur par défaut. En outre, un nouveau mot clé de chaîne de connexion, Mars_Connectiontel qu’il a été ajouté. Elle accepte les valeurs « oui » ou « non » ; « non » est la valeur par défaut.
Exemple de pilote ODBC SQL Server Native Client
Dans cet exemple, la fonction SQLSetConnectAttr est utilisée pour activer MARS avant d’appeler la fonction SQLDriverConnect pour connecter la base de données. Une fois la connexion établie, deux fonctions SQLExecDirect sont appelées pour créer deux jeux de résultats distincts sur la même connexion.
#include <sqlncli.h>
SQLSetConnectAttr(hdbc, SQL_COPT_SS_MARS_ENABLED, SQL_MARS_ENABLED_YES, SQL_IS_UINTEGER);
SQLDriverConnect(hdbc, hwnd,
"DRIVER=SQL Server Native Client 10.0;
SERVER=(local);trusted_connection=yes;", SQL_NTS, szOutConn,
MAX_CONN_OUT, &cbOutConn, SQL_DRIVER_COMPLETE);
SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt1);
SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt2);
// The 2nd execute would have failed with connection busy error if
// MARS were not enabled.
SQLExecDirect(hstmt1, L"SELECT * FROM Authors", SQL_NTS);
SQLExecDirect(hstmt2, L"SELECT * FROM Titles", SQL_NTS);
// Result set processing can interleave.
SQLFetch(hstmt1);
SQLFetch(hstmt2);
Voir aussi
Fonctionnalités de SQL Server Native Client
Utilisation des jeux de résultats par défaut SQL Server