Utilisation d'Excel comme frontal pour la base de données Access (avec VBA)
Je construis une petite application pour un ami et ils aimeraient pouvoir utiliser Excel comme frontal. (l'interface utilisateur sera essentiellement des userforms dans Excel). Ils aimeraient pouvoir interroger une série de données dans Excel, mais je ne souhaite pas utiliser Excel comme base de données, car je ne pense pas qu'elle soit adaptée à cet usage et envisage d'utiliser Access. [Au fait, je sais que l'accès a ses défauts, mais le budget est nul et l'accès est déjà disponible sur le PC d'un ami]
Pour résumer, j’envisage de transférer une série de données dans Access, puis d’utiliser Excel en tant que serveur frontal pour interroger la base de données et afficher les résultats dans un environnement de type formulaire utilisateur.
Des questions:
- Est-il facile de se connecter à Access à partir d'Excel avec ADO/DAO? Est-ce assez limité en termes de fonctionnalités ou puis-je faire preuve de créativité?
- Dois-je payer une pénalité de performance (par opposition à l’utilisation de formulaires dans Access comme interface utilisateur)?
- En supposant que la base de données sera toujours mise à jour à l'aide des commandes ADO/DAO à partir d'Excel VBA, cela signifie-t-il que je peux avoir plusieurs utilisateurs d'Excel utilisant cette base de données Access unique sans être confrontés à des problèmes de simultanéité, etc.?
- Y a-t-il d'autres choses que je devrais savoir?
J'ai de fortes compétences Excel en VBA et je pense que je peux surmonter Access VBA assez rapidement, mais je n'ai jamais vraiment créé de lien Excel/Access auparavant. Je pourrais utiliser les données dans Excel et les utiliser comme une quasi-base de données, mais cela me semble plus pénible qu'il ne vaut la peine (et non une solution robuste à long terme)
Tout conseil apprécié.
Alex
Je suis sûr que vous obtiendrez une tonne de réponses "ne faites pas ceci", et je dois dire qu'il y a de bonnes raisons. Ce n'est pas une solution idéale ....
Cela étant dit, j'ai déjà emprunté cette voie (et des voies similaires), principalement parce que le travail le spécifiait comme une exigence essentielle et que je ne pouvais pas en parler.
Voici quelques points à considérer avec ceci:
Est-il facile de se connecter à Access à partir d'Excel avec ADO/DAO? Est-ce assez limité en termes de fonctionnalités ou puis-je faire preuve de créativité?
C'est assez étroit. Vous êtes plus limité que vous ne le feriez avec d'autres outils, car les formulaires VBA et Excel sont un peu plus contraignants que la plupart des langages de programmation complets, mais rien ne peut vous arrêter. Cela fonctionne - parfois c'est un peu moche, mais cela fonctionne. Dans ma dernière entreprise, je devais souvent le faire - et parfois extraire des données d’Access et Oracle via VBA dans Excel.
Dois-je payer une pénalité de performance (par opposition à l’utilisation de formulaires dans Access comme interface utilisateur)?
Mon expérience est qu'il y a vraiment un perf. pénalité en faisant cela. Je ne m'en suis jamais soucié (dans mon cas d'utilisation, les choses étaient suffisamment petites pour que ce soit raisonnable), mais aller sous Excel <-> Access est beaucoup plus lent que de travailler directement dans Access. Cela dépend en partie de ce que vous voulez faire ....
Dans mon cas, ce qui semblait être le plus lent (et le plus pénible) consistait à remplir des feuilles de calcul Excel à partir de données Access. Ce n'était pas amusant et était souvent très lent. Si vous devez emprunter cette voie, assurez-vous de tout faire avec Excel caché/invisible, sans quoi le redessinage vous tuera.
En supposant que la base de données sera toujours mise à jour à l'aide des commandes ADO/DAO à partir d'Excel VBA, cela signifie-t-il que je peux avoir plusieurs utilisateurs d'Excel utilisant cette base de données Access unique sans être confrontés à des problèmes de simultanéité, etc.?
Vous utilisez à peu près Excel comme client, comme vous utiliseriez une application WinForms ou tout autre outil. Les clients ADO/DAO pour Access sont plutôt bons, vous ne rencontrerez donc probablement pas de problèmes de simultanéité.
Cela dit, l'accès ne s'adapte PAS bien. Cela fonctionne très bien si vous avez 2 ou 3 (voire 10) utilisateurs. Si vous allez en avoir 100, vous aurez probablement des problèmes. De plus, j'avais tendance à penser qu'Access avait besoin d'une maintenance régulière afin de ne pas avoir de problèmes de corruption. Des sauvegardes régulières de la base de données Access sont indispensables. Le compactage régulier de la base de données d'accès aidera à prévenir la corruption de la base de données, selon mon expérience.
Y a-t-il d'autres choses que je devrais savoir?
Vous faites cela à la dure. Utiliser Excel pour accéder à Access demandera beaucoup plus de travail que d’utiliser directement Access.
Je vous conseillerais de consulter l'API Access VBA - la plupart d'entre elles sont identiques à celles d'Excel. Vous aurez donc une petite courbe d'apprentissage. Les différentes parties rendent cela plus facile. Vous bénéficierez également de tous les avantages de la création de rapports Access et des formulaires, qui sont beaucoup plus axés sur les données que ceux d'Excel. La création de rapports peut être excellente pour des choses comme celle-ci, et le fait de disposer des macros et des rapports facilitera la vie à long terme. Si l'utilisateur doit utiliser des formulaires pour tout gérer, leur utilisation dans Access sera très similaire à leur utilisation dans Excel et sera presque identique, mais rendra tout plus rapide et plus fluide.
Je le fais tout le temps. Si vous utilisez ADO, vous n'utilisez pas vraiment Access, mais Jet, la base de données sous-jacente. Cela signifie que n'importe qui avec Excel peut utiliser l'application - Accès non requis. Oh, je devrais mentionner, l'endroit où je travaille a acheté un tas de licences Office Small Business - pas d'accès. Avant de travailler ici, j'aurais supposé que quiconque disposant d'Excel aurait également accès à Access. Pas si.
Je crée une classe pour chaque table dans Access. J'exécute très rarement des requêtes via ADO, mais je conserve cette logique dans les modules de classe. J'ai lu avec une instruction SELECT et écrit avec et UPDATE ou INSERT à l'aide de la méthode Execute de l'objet ADODB.Connection.
Voir http://www.dailydoseofexcel.com/archives/2008/12/21/vba-framework-ii/
si vous voulez voir comment je configure mon code.
Pour répondre à vos questions: si vous connaissez déjà Excel VBA, l'apprentissage sera une petite courbe d'apprentissage, mais il y aura quelques apprentissages à faire; vous allez payer une pénalité de performance pour tout faire dans Access, mais ce n'est pas si grave et vous seul pouvez décider si cela en vaut la peine; et vous pouvez avoir plusieurs personnes accédant à la base de données.
Il suffit de sauter la partie Excel - les formulaires utilisateur Excel ne sont qu'une version pour les pauvres du moyen plus robuste des formulaires Access. Aussi, Access VBA est identique à Excel VBA - il vous suffit d'apprendre le modèle d'objet d'Access. Avec une application simple, vous n’aurez de toute façon pas besoin d’écrire beaucoup de VBA car dans Access, vous pouvez câbler des choses très facilement.
Si l'utilisateur final dispose d'Access, il pourrait être plus facile de développer le tout dans Access. Access intègre des outils de conception de formulaire WYSIWYG.
À moins d’avoir un avantage certain à exécuter votre formulaire utilisateur dans Excel, je choisirais une solution 100% Access permettant d’exporter les rapports et les données vers Excel sur une base ad hoc.
D'après ce que vous décrivez, Access semble être le candidat le plus puissant, car il est conçu pour travailler avec des données:
vous auriez beaucoup plus d’outils à votre disposition pour résoudre tout problème de données que de contourner les limitations d’Excel et de le faire passer à l’achat ...
Quant à vos questions:
Très facile. Il y a eu d'autres questions sur SO sur ce sujet.
Voir par exemple celui-ci et celui-là .Je ne sais pas, mais j'imagine qu'il pourrait y avoir une petite pénalité.
La principale difficulté que je vois est d’essayer d’obtenir toutes les fonctionnalités d’Access et de les recréer dans Excel.Oui, vous pouvez avoir plusieurs utilisateurs Excel et une seule base de données Access.
Ici encore, utiliser Access comme interface frontale et conserver les données dans une base de données Access liée sur votre réseau aurait plus de sens et c'est simple comme bonjour, il y a même un assistant dans Access pour vous aider à le faire: c'est à seulement 1 clic .
En réalité, comme l’ont dit la plupart des gens, il vous faudra un peu de temps pour vous familiariser avec Access, cela vous fera économiser beaucoup de temps et de problèmes.
Vous connaissez peut-être mieux Excel, mais si vous avez déjà parcouru 80% du chemin déjà si vous connaissez VBA et connaissez le modèle objet Office.
Les autres avantages de le faire dans Access: le Access 2007 runtime est gratuit , ce qui signifie que si vous déployiez l'application sur un ou 30 PC, le coût serait le même: rien.
Vous n’avez besoin que d’une seule version complète d’Access pour votre travail de développement (Runtime n’a pas de concepteurs).
Cela dépend vraiment de l'application. Pour un projet normal, je recommanderais d'utiliser uniquement Access, mais parfois, les besoins sont spécifiques et une feuille de calcul Excel peut être plus appropriée.
Par exemple, dans un projet que je devais développer pour un ancien employeur, il était nécessaire de donner accès à différentes personnes sur des formulaires (pré-remplies avec certaines données, différentes pour chaque personne) et de les faire remplir, puis de réimporter les données. Les données.
Étant donné que le formulaire utilisait des calculs complexes, il était plus logique de le créer dans Excel.
Les classeurs Excel des différentes personnes ont été créés à partir d'un modèle utilisant VBA, puis enregistrés dans un emplacement approprié, avec les droits d'accès au dossier.
Tous les classeurs ont été attachés en tant que tables externes aux classeurs, à l'aide de plages nommées. Je pourrais alors interroger les classeurs à partir de l'application Access. Tous les éléments administratifs ont été créés à partir de la base de données, mais les utilisateurs finaux n’ont accès qu’à leur classeur respectif.
Développer une application Excel/Access de cette façon a été une expérience agréable et l'interface utilisateur était plus conviviale que si elle avait utilisé Access.
Je dois dire que dans ce cas, cela aurait pris beaucoup plus de temps dans Access que dans Excel. En outre, le modèle objet d'application semble meilleur dans Excel que dans Access.
Si vous envisagez d’utiliser Excel comme interface frontale, n’oubliez pas de verrouiller toutes les cellules, mais modifiables, et n’hésitez pas à utiliser des lignes et des colonnes masquées (pour construire des tables de sortie pour la base de calculs, etc.).
Vous devez également désactiver le calcul automatique lors de l'importation de données.
Il est très facile et efficace d’utiliser Excel comme outil de reporting pour les données Access .____ Une approche rapide "sans programmation" consiste à définir une liste ou un tableau croisé dynamique, lié à votre source de données externe. Mais c'est hors de portée pour Stackoverflow.
Une approche programmatique peut être très simple:
strProv = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & SourceFile & ";"
Set cnn = New ADODB.Connection
cnn.Open strProv
Set rst = New ADODB.Recordset
rst.Open strSql, cnn
myDestRange.CopyFromRecordset rst
C'est tout !
Compte tenu de la facilité d'utilisation d'Access, je ne vois pas de raison impérieuse d'utiliser Excel, si ce n'est d'exporter des données à des fins de traitement des données. Access est conçu pour créer facilement des formulaires de données et, à mon avis, sera beaucoup plus facile et prend moins de temps que d’utiliser Excel. Quelques heures à apprendre le modèle d'objet Access seront rentables à maintes reprises en termes de temps et d'effort.
Je l'ai fait dans l'un de mes projets. J'ai utilisé MDB pour stocker les données sur les factures et Excel pour les restituer, donnant à l'utilisateur la possibilité de les adapter.
Dans ce cas, la meilleure solution est:
Ne pas utiliser d’ADO/DAO dans Excel . J'ai tout implémenté en tant que fonctions publiques dans les modules MDB et je les ai appelés directement à partir d'Excel. Vous pouvez même renvoyer des objets de données complexes, tels que des tableaux de chaînes, etc. en appelant des fonctions MDB avec les arguments nécessaires. Ceci est similaire à l'architecture client/serveur des applications Web modernes: votre application Web ne fait que le rendu et l'interaction utilisateur, la base de données et le niveau intermédiaire sont alors côté serveur.
Utilisez des formulaires Excel pour l’interaction de l’utilisateur et la visualisation des données.
J'ai généralement une toute dernière feuille avec certaines régions de noms pour les paramètres: le chemin d'accès aux fichiers MDB, certains paramètres (utilisateur actuel, mot de passe si nécessaire, etc.). fin "données.
Cela dépend du nombre de fonctionnalités que vous attendez de la solution Excel <-> Acess. Dans de nombreux cas où vous n'avez pas de budget pour obtenir une solution d'application complète, ces petits utilitaires fonctionnent. Si la portée du projet est limitée, je choisirais cette solution, car Excel vous offre la possibilité de concevoir des feuilles de calcul en fonction de vos besoins. Vous pouvez ensuite utiliser les feuilles prédéfinies que les utilisateurs peuvent utiliser. Concevoir une feuille de calcul comme un formulaire dans Access prend plus de temps, est plus difficile et nécessite un certain ActiveX. Il s’agit peut-être d’un objet non seulement qui manipule des données mais se présente sous forme de feuille de calcul comme des formats, alors cette solution devrait fonctionner avec une portée limitée.
Connecter Excel to Access à l'aide de VBA est très utile, je l'utilise quotidiennement dans mon métier. La chaîne de connexion que j'utilise est conforme au programme trouvé dans le lien ci-dessous. Le programme peut être automatisé pour effectuer plusieurs connexions ou tâches, mais le code de connexion de base est identique. Bonne chance!