À l'aide de ADODB à accès ouvert de fichier xls

Bien que j'ai travaillé avec VBA pour Excel pour un temps assez long, j'ai un problème que je ne peut pas résoudre par moi-même. J'ai décrit ci-dessous, l'espoir d'obtenir de l'aide ou des conseils.
Je suis à l'aide d'Excel 2007 et Windows XP, tous mis à jour avec les nouveaux patchs.

Je suis très souvent à l'aide de code suivant pour obtenir des données à partir d'un autre classeur:

Set conn = New ADODB.Connection
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=g:\source.xls;Extended Properties=Excel 8.0;"

Sql = "SELECT Field1, Field2 FROM [Sheet1$]"

Set rst = New ADODB.Recordset
rst.Open Sql, conn, adOpenForwardOnly

Worksheets("Results").Range("A2").CopyFromRecordset rst

rst.Close
Set rst = Nothing

conn.Close
Set conn = Nothing

Aussi simplement que peut - il suffit de se connecter à des fichiers et d'obtenir quelques données. Il travaille parfait tant, comme le fichier source qui est situé sur un lecteur réseau (g:\source.xls) n'est pas ouvert sur un autre ordinateur.
Quand un autre utilisateur sur un autre ordinateur a ouvert le fichier et j'essaie d'exécuter le code suivant, j'ai remarqué une chose que je tiens à vous débarrasser de: le fichier source Excel est ouvert (en mode lecture seule) sur mon ordinateur et il n'est pas fermé après la connexion à ce fichier a été fermé. Ce qui est pire, même si je ferme ce fichier source manuellement, il laisse peu de déchet dans mon dossier, comme il n'a jamais été fermé: voir l'image après quelques exécution de code (la source des fichiers a été fermé avant):
À l'aide de ADODB à accès ouvert de fichier xls

J'ai commencé à croire que c'est un bug qui ne peut pas être résolu espère que je me trompe 🙂

OriginalL'auteur mj82 | 2012-01-24

  1. 3

    C'est en fait un bug connu, voir: http://support.microsoft.com/default.aspx?scid=kb;en-us;319998&Product=xlw. L'interrogation d'ouvrir un classeur Excel avec VBA provoque une fuite de mémoire se produire que la référence n'est pas libérée, même lors de la fermeture de la connexion et de compensation de l'objet.

    Eh bien, si c'est un bug alors il n'y a pas beaucoup à faire avec elle. Je vais tester les deux solutions de contournement méthodes mentionnées sur la page liée et essayez d'utiliser le pilote OLEDB.12 lorsque c'est possible.
    Ouais, ça craint, mais c'est encore une manière EXTRÊMEMENT utile d'obtenir des données à partir d'Excel. Vous avez juste à faire de petits changements ici et là pour obtenir autour de problèmes potentiels. Puisque la plupart des données que vous auriez accès à cette méthode est la substance qui est mieux adapté dans une base de données de toute façon j'ai l'habitude de finir par l'agrégation de tous les trucs que j'ai envie de tirer dans un peu d'Accès DB avec cette méthode, puis de publier quoi que feuille de calcul Excel, PDF, etc de qui.
    Cette URL a été l'origine de boucle de redirection. Essayez de https://support.microsoft.com/en-us/kb/319998.

    OriginalL'auteur Kittoes0124

  2. 4

    Votre Excel version 2007 ou plus tard?

    si est l'utilisation de Microsoft.ACE.OLEDB.12.0 au fournisseur et votre problème est résolu.

    []s

    OriginalL'auteur Bruno Leite

  3. 0

    Vous serait beaucoup mieux d'ouvrir votre source de données Excel en utilisant le construit en référence Excel, plutôt que d'une connexion ADO e.g:

    Dim xlApp As New Excel.Application
Dim xlWrkBk As Excel.WorkBook

xlApp.WorkBooks.Open FILENAME
Set xlWrkBk = xlApp.ActiveWorkbook

    Et puis aller à partir d'ici, au lieu

    Pourquoi pensez-vous qu'il est beaucoup meilleure solution? Je ne pense pas tellement à cause de 2 choses: la 1ère: de l'ouverture du fichier prend beaucoup plus de temps que de simplement connexion ADO, et la 2ème: je ne vais pas être en mesure d'utiliser des requêtes SQL, qui est la principale raison pour laquelle je suis à l'aide d'ADO (à moins que je me connecte avec un fichier ouvert, qui est à peu près la même situation)... Le seul point positif que j'ai trouvé est qu'il devrait (pas encore testé) vous débarrasser de cette "poubelle" refences que j'ai maintenant, mais pour moi, le temps d'ouverture croissante n'est pas la peine...
    Pourquoi votre magasin de base de données les informations de style sur lequel vous pouvez exécuter SQL; dans un fichier Excel, pourquoi ne pas utiliser l'Accès ou un autre objet construit programme de base de données? La seule raison pour laquelle je préfère cette méthode est que vous pouvez le faire par le biais de différents domaines sur les feuilles et, finalement, la capture d'éventuelles mauvaises données plus facilement.
    C'est parce que je travaille avec déjà existante de l'utilisateur des fichiers Excel. Il n'est pas temps-économique pour reconstruire chaque fichier ils utilisent déjà, juste pour mettre les mêmes données dans Access. Et - plus important - la plupart des utilisateurs ne savent pas Access et VBA, alors ils préfèrent travailler avec l'outil qu'ils connaissent et qu'ils peuvent utiliser pour modifier ou ajuster sur leur propre, ce qui est tout simplement un fichier Excel. Bien sûr, où je peux et quand j'ai créer une application à partir de zéro, je préfère utiliser la base de données en tant que bien, mais dans la plupart des cas, j'essaie de "s'intégrer" les différentes sources de données, y compris .les fichiers xls, qui sont la cause de ce problème...

    OriginalL'auteur Matt Donnan