Déconnecté de bogue : ADO Recordset qui utilise la requête paramétrée est pas déconnecté par SQL Server

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

252482
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Symptômes
La technologie Microsoft ActiveX Data Objects (ADO) permet aux utilisateurs d'obtenir un jeu d'enregistrements à partir d'une source de données, «déconnecter» ce jeu d'enregistrements de sa source en définissant l'objet Recordset de l'objet de la propriété ActiveConnection sur Nothing, puis en fermant (facultativement) l'objet Connection correspondant. Microsoft recommande fortement d'utiliser cette fonctionnalité, car la préservation des ressources serveur limitées. Toutefois, lorsque Microsoft SQL Server est la source de données et le jeu d'enregistrements est basé sur une commande ADO paramétré, SQL Server ne déconnecte pas l'utilisateur.

Vous pouvez observer ce comportement lorsque vous utilisez un objet ADO Command comme source de votre jeu d'enregistrements, si vous utilisez :
  • un objet ADO Command qui repose sur une procédure stockée paramétrée ; par exemple, la procédure stockée de "byroyalty" dans la base de données exemple pubs,

    - ou -
  • objet ADO Command dont la propriété CommandText est une instruction SQL qui inclut des paramètres. Par exemple, «sélectionnez au_id dans titleauthor où titleauthor.royaltyper =?» (il s'agit de la requête est utilisée dans la procédure stockée de "byroyalty").
Ce problème se produit lorsque vous utilisez fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) ou fournisseur Microsoft OLE DB pour pilotes ODBC (MSDASQL) avec pilote de Server ODBC theSQL.

Ce problème ne se produit pas que si vous utilisez uniquement un objet Recordset et un appel un paramétrée procédure stockée avec un EXECUTE ou CALL instruction que l'argument source ; par exemple, "byroyalty EXEC 100" ou «{CALL byroyalty(100)}.»
Résolution
Pour résoudre ce problème, procurez-vous le dernier service pack Microsoft Data Access Components 2.6. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft :
300635Procédure d'information : Pour obtenir la dernière version MDAC 2.6 Service Pack
Dans la mesure où SQL Server libère la connexion de base de données après la fermeture de l'objet ADO Recordset d'origine, la solution consiste à effectuer une copie du jeu d'enregistrements à l'aide de la méthode de Recordset.Clone, fermez le jeu d'enregistrements d'origine et travailler avec la copie clonée.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés au début de cet article. Ce problème a été corrigé dans Microsoft Data Access Components 2.6 Service Pack 1.
Plus d'informations

Procédure pour reproduire le problème

  1. Démarrer le Générateur de profils SQL Server et à démarrer une trace. Les paramètres de trace par défaut enregistre l'activité de connexion.
  2. Exécutez le code Visual Basic suivant sur la base de données pubs de SQL Server :

    RemarqueVous devez changer le nom d'utilisateur = <username>et le mot de passe = < mot de passe fort > pour les valeurs correctes avant d'exécuter ce code. Assurez-vous que le nom d'utilisateur possède les autorisations appropriées effectuer cette opération sur la base de données.
      Dim cn As ADODB.Connection  Dim cmd As ADODB.Command  Dim prm As Parameter  Set cn = New ADODB.Connection  With cn    .Provider = "SQLOLEDB"    .ConnectionString = "Data Source=(local);Initial Catalog=pubs;User ID=<username>;Password=<strong password>;"    .Open  End With  Set cmd = New ADODB.Command  With cmd    Set .ActiveConnection = cn    .CommandType = adCmdStoredProc    .CommandText = "byroyalty"    Set prm = .CreateParameter("", adInteger, adParamInput, , 100)    .Parameters.Append prm  End With  Set rs = New ADODB.Recordset  With rs    .CursorLocation = adUseClient    .CursorType = adOpenStatic    .LockType = adLockBatchOptimistic    Set .Source = cmd    .Open  End With  Set rs.ActiveConnection = Nothing  cn.Close  Set cn = Nothing					
  3. Si vous le souhaitez, ajoutez une instruction Debug.Print cn.State, ou s'arrêter le code après la dernière ligne Entrez ? cn.State dans la fenêtre exécution. Cette action renvoie 0 (adStateClosed), indiquant que la connexion est fermée apparemment.
  4. Revenir à la fenêtre de trace du Générateur de profils SQL et n'oubliez pas que SQL Server n'a pas déconnecté.

Avertissement : Cet article a été traduit de manière automatique

Propriétés

ID d'article : 252482 - Dernière mise à jour : 02/23/2014 11:20:32 - Révision : 3.1

  • Microsoft Data Access Components 2.1
  • Microsoft Data Access Components 2.5 Service Pack 1
  • Microsoft Data Access Components 2.5
  • kbnosurvey kbarchive kbmt kbbug kbfix kbmdac260sp1fix kbmdacnosweep KB252482 KbMtfr
Commentaires