web-dev-qa-db-fra.com

Comment accéder à SQL Server à partir de VBA de manière non obsolète?

Il semble que tous les moyens d'accéder directement à une base de données SQL Server à partir d'un projet VBA soient obsolètes:

  • DAO avec ODBCDirect: la prise en charge a été abandonnée avec Access 2007.
  • DAO via JET: Vous n'êtes pas sérieux, non? Quoi qu'il en soit, il est considéré comme obsolète par Microsoft.
  • ADO avec le fournisseur SQLOLEDB: Déconseillé .
  • ADO avec le fournisseur OLEDB natif SQL Server: Ne sera pas pris en charge après SQL Server 2012 .
  • ADO avec le fournisseur de base de données Microsoft OLE pour ODBC: Non pris en charge : "SQL Server Native Client n'est pas pris en charge par le fournisseur de base de données Microsoft OLE pour ODBC (MSDASQL) . "

Qu'est-ce que j'ai raté? Quel est le moyen officiel, approuvé par Microsoft, d'accéder à une base de données SQL Server à partir de VBA (qui est après tout non obsolète et qui reste la langue de développement officielle incluse dans Office 2013)?

sql-servervbaexcel-vbams-accessexcel
11
Heinzi

Qu'est-ce que j'ai raté?

Vieux bon vieux ODBC. Dans les projets VBA pour des applications Office autres qu'Access, ODBC via ADO est le plus simple:

Sub AdoOdbcExample()
    Dim con As Object
    Set con = CreateObject("ADODB.Connection")
    con.Open _
            "Driver={SQL Server Native Client 11.0};" & _
            "Server=.\SQLEXPRESS;" & _
            "Database=myDb;" & _
            "Trusted_Connection=yes;"
    con.Execute "UPDATE Clients SET FirstName='Gord' WHERE ID=5;"
    con.Close
    Set con = Nothing
End Sub

Pour les projets VBA dans Access, nous avons également la possibilité d’utiliser des tables liées ODBC et des requêtes directes via ACE DAO comme nous l’avons toujours fait.

Sub DaoOdbcExample()
    Dim cdb As DAO.Database, qdf As DAO.QueryDef
    Set cdb = CurrentDb
    Set qdf = cdb.CreateQueryDef("")
    qdf.Connect = "ODBC;" & _
            "Driver={SQL Server Native Client 11.0};" & _
            "Server=.\SQLEXPRESS;" & _
            "Database=myDb;" & _
            "Trusted_Connection=yes;"
    qdf.sql = "UPDATE Clients SET FirstName='Gord' WHERE ID=5;"
    qdf.ReturnsRecords = False
    qdf.Execute dbFailOnError
    Set qdf = Nothing
    Set cdb = Nothing
End Sub

Remarques: 

  1. SQL Server Native Client 11.0 est la version fournie avec SQL Server 2014 (réf: here ).

  2. La liste citée des Technologies d'accès aux données obsolètes indique "DAO 3.6 est la version finale de cette technologie. Elle ne sera pas disponible sur le système d'exploitation Windows 64 bits.". Cela fait référence à Jet DAO ("Bibliothèque d'objets Microsoft DAO 3.6"). ACE DAO ("Bibliothèque d'objets de moteur de base de données Microsoft Access") est effectivement disponible pour les applications 64 bits si la version 64 bits du moteur de base de données Access est installée.

11
Gord Thompson

La méthode correcte et future consiste à utiliser le modèle d'objet ACE. Vous êtes 100% correct de dire que l'oleDB natif est supprimé du serveur SQL. Il est ÉGALEMENT très important de noter que la communauté de développeurs «générale» a commencé à supprimer ADO lorsque .net est sorti (le fournisseur ado.net est une bête TRÈS différente et qui ne repose pas sur oleDB, mais sqlprovider).

Donc, pour cette raison, des tendances importantes se dessinent dans notre industrie.

Nous nous éloignons d'oleDB. C’est en général une technologie Windows uniquement. Avec la montée en puissance des iPad, smartphones, Android, etc., vous n’avez plus de fournisseurs de ce type, ni d’OdDB. Vous devez donc revenir en arrière en utilisant les standards ODBC (Open Database Connectivity). Oracle, Microsoft et MySQL ont tous déclaré que c’était la voie et le choix futurs.

Alors que JET est considéré comme obsolète, ACE ne l’est pas.

SINCE Access 2007 (qui est maintenant entièrement 3 versions), vous n'avez pas et ne devriez pas avoir une référence à DAO. Ainsi, pour les 3 dernières versions d’Access, vous n’avez ni besoin ni envie de vous servir d’une référence à la bibliothèque d’objets DAO.

Vous devez maintenant utiliser le nouveau moteur de base de données ACE intégré. Cela signifie que vous n'avez PAS besoin d'une référence distincte à DAO.

Le moteur ACE présente plusieurs avantages:

Vous n’avez plus besoin d’une référence DAO.

Une fois que la référence au moteur de données prend en charge les deux références précédentes de la bibliothèque.

Une édition x32 et x64 bits est disponible (pour que les applications .net, etc., puissent utiliser une édition x64 bits de ce moteur de données). JET était x32 bit seulement.

Le fournisseur ACE continue de recevoir des mises à jour et des améliorations. On ne peut pas en dire autant de JET ni même beaucoup de ADO.

ACE prend désormais en charge les procédures de stockage et les déclencheurs de table. Il prend également en charge les listes SharePoint basées sur les services Web.

Des modifications ont également été apportées à Access/ACE pour fonctionner avec SQL Azure.

Pour utiliser Access avec SQL Server, utilisez simplement ACE et les tables liées. Comme indiqué, la tendance à l'abandon de ADO BEAUCOUP a débuté il y a environ 13 ans, lorsque .net est entré en scène.

Ainsi, l’approche standard recommandée maintenant est ACE + odbc. 

Donc, vous n'avez rien manqué ici. La confusion découle en grande partie de l'article selon lequel JET est amorti, mais THEN laisse de côté le détail TRÈS important, selon lequel les versions d'Access for THE LAST 3 n'utilisent PAS JET, mais utilisent une nouvelle bibliothèque appelée ACE.

Il est IMPORTANT que vous n’ayez plus besoin de, ni ne désiriez une référence à DAO dans vos applications d’accès. 

Vous utilisez certainement une bibliothèque DAO compatible, et il est même recommandé de préfixer DAO avec le code de réétablissement (le code existant plus ancien fonctionnera donc parfaitement si vous l’aviez déjà fait auparavant, ou vous avez toujours laissé de côté le qualificatif DAO lors de la déclaration. jeux d'enregistrements.

Et pour des choses comme SQL pass cependant, vous pouvez simplement utiliser une requête enregistrée de passage, et procédez comme suit:

   CurrentDb.QueryDefs("MyPass").Execute

ou que diriez-vous de t-sql, vous pouvez faire ceci:

With CurrentDb.QueryDefs("MyPass")
  .SQL = "ALTER TABLE Contacts ADD MiddleName nvarchar(50) NULL"
  .Execute
End If

ou appelez une procédure de magasin de votre choix "à la volée" avec un paramètre

With CurrentDb.QueryDefs("MyPass")
  .SQL = "Exec MyStoreProc " & strMyParm1
  .Execute
End If

Les précédents ne sont-ils pas si beaux et propres? Comme indiqué ci-dessus, les exemples de code ci-dessus ont tendance à être FAR moins de code et de tracas que l'utilisation des exemples oleDB/ADO publiés.

Pour les utilisateurs de longue date d’Access qui ont développé leurs compétences autour de ODBC et du serveur SQL, vous n’avez rien à faire, car le secteur a beaucoup décidé que ce que vous feriez depuis le début est l’approche recommandée. 

Bien que JET-DIRECT ne soit pas pris en charge dans ACE, je ne peux imaginer aucun cas où ce choix est manqué en utilisant les exemples de type pass-through querydef décrits ci-dessus à la place de JET direct.

2
Albert D. Kallal

Lors de l’initialisation d’un adodb.connection dans vba, nous avons remplacé

          .Provider = "sqloledb"
          .Properties("Data Source").Value = sServer
          .Properties("Initial Catalog").Value = sDB
          .Properties("Integrated Security").Value = "SSPI"

avec

           .ConnectionString = _
               "DRIVER={ODBC Driver 11 for SQL Server}; " & _
               "SERVER=" & sServer & "; " & _
               "Trusted_Connection=Yes; " & _
               "DATABASE=" & sDB & "; "

Cela utilise .Provider = "MSDASQL.1" mais vous n’avez pas besoin de l’ajouter. 

0
Hein van der Kallen