Discussion :

[ted the Ors]

Bonjour,

J'ai développé un gros applicatif en VBA sous Excel (30 000 lignes de codes, 80 formulaires). L'applicatif utilise des userforms, des accès à des bases de données distantes, et toute une multitude de choses mais sans jamais utiliser le fait d'être "encapsulé" dans un document Excel (i.e je ne fais jamais appel à des objets Excel type Workbook et compagnie).
Ma question: est-il possible de porter/migrer ce code dans Access sans trop de modifications? Si oui, à quoi faut-il faire attention ou s'attendre dans ce cas?
Je n'ai pas trouvé grand chose sur le web (français ou autres) sur le sujet.

Pour information, je refléchis à ce portage car Excel ne permet pas d'afficher un tableau dans un userform, ce qu'Access maîtrise tout à fait. Et pour ceux qui me rétorqueront (à raison) que j'aurai du y penser au début, il s'agit d'un outil développé dans un cadre professionnel et l'utilisation d'une licence Access n'était pas accepté par ma hiérarchie lors de la genèse du projet.

D'avance merci et très bonne journée.

[Jean-Philippe André]

Salut,

dans un monde parfait, tu peux faire un export depuis ton Excel et un import dans ton Access, et ca fonctionnera.

Dans la réalité, il est très probable que sur tes 30k lignes de codes, tu utilises des constantes Excel par exemple.

En ajoutant la référence Excel dans ton Access, tu pourrais passer outre, mais ma recommandation serait de faire les choses proprement et corriger le cas échéant le code. Mais le fait de rajouter la librairie peut ;galement être acceptable

[ted the Ors]

Merci pour cette réponse. Je vais donc tester. En attendant, je passe en résolu!

Très bonne journée.

[Pierre Fauconnier]

Salut.

Je suis nettement plus nuancé que JP...

En Excel, on utilise des userforms, objet parfaitement inconnu d'un Access natif qui ne connait, lui, que Form (et ce n'est pas DU TOUT la même chose). Les contrôles sont eux aussi différents (un textbox Access n'a que peu de similitudes avec le msforms.textbox d'Excel, idem pour les combobox, listbox et autres).


Donc NON, mille fois NON, tu ne passeras pas sans douleurs d'Excel à Access. Ce sont deux mondes TRES différents, même si c'est le même langage qui est utilisé pour l'un et pour l'autre.

Cocher la référence à Excel "pour que ça passe" est une conn*** pure. D'abord, parce que cela "ne passera pas", mais ensuite, parce qu'une feuille Excel n'est pas une table Access, pas plus d'ailleurs qu'un tableau structuré.

Excel ne s'appelle pas Access Lite, ce sont des applications différentes qui permettent de réaliser des choses différentes. Croire (et laisser croire) que tu vas "migrer" d'un à l'autre sans douleurssssss est une stupidité sidérale. Tu ne pourras pas passer d'Excel à Access en "corrigeant le cas échéant le code"... C'est juste IM-POS-SI-BLE!! C'est une refonte totale de l'approche et du code à laquelle tu dois t'attendre.

[Jean-Philippe André]

Salut,

je culpabilise en me relisant…

Comme très justement indiqué par Pierre, seuls les codes de module sans aucune manipulation d'excel ou access ni formulaire (donc les fonctions et procédures indépendantes qui ne pratiquent rien dans les objets Excel ou access) seront possible sans heurt. IL est également horrible de ma part d'avoir insinuer que des codes faisant reference à des formulaires soient possible.

Mea culpa

[Pierre Fauconnier]

[...]
Excel ne s'appelle pas Access Lite, ce sont des applications différentes qui permettent de réaliser des choses différentes. Croire (et laisser croire) que tu vas "migrer" d'un à l'autre sans douleurssssss est une stupidité sidérale. Tu ne pourras pas passer d'Excel à Access en "corrigeant le cas échéant le code"... C'est juste IM-POS-SI-BLE!! C'est une refonte totale de l'approche et du code à laquelle tu dois t'attendre.

Pour compléter mon propos:

• 30000 lignes de code, ça me semble énorme et il y a probablement moyen de factoriser, de réécrire, de rendre générique une partie du code;
• Le code servant aux échanges Formulaires/Feuilles va devenir inutile puisque les formulaires Access sont liés aux tables sans besoin de VBA pour ce faire. Il y aura du VBA pour contrôler les saisies, mais les mécanismes d'échange Formulaire/DB ne nécessitent pas de VBA, ou très peu dans certains cas spécifiques;
• Les contrôles TextBox disposent de mécanismes de vérification, tant durant la saisie qu'à la validation, pour vérifier la séquence de saisie, le fait que l'on a bien saisi une date ou une valeur numérique, sans aucune ligne de code VBA, ce dernier n'étant utilisé que pour la validation "métier" des données si celle-ci ne peut être effectuée par les propriétés desdits contrôles, mais la vérification technique (est-ce bien une date? Le numéro d'article est-il encodé selon la bonne séquence? ...) est parfaitement possible sans code;
• Les mécanismes d'intégrité référentielle, liés à la notion de clé primaire (souvent un long autoincrémenté) ne demandent aucune ligne de code VBA, alors que j'imagine que dans ton appli Excel, tu as dû coder tout cela;
• Sur une "appli pareille", je suppose que tu as dû prévoir des feuilles de reporting, à grand renfort de code tant pour la récupération des données que pour leur mise en forme, les sauts de page, ... Avec Access, les états (reporting) peuvent être créés sans aucune ligne de code (pour une utilisation habituelle d'un état);
• Les requêtes Access sont normalement créées via le QBE (Query By Example). Là aussi, pas ou peu de code, alors qu'Excel t'impose soit de coder des filtres automatiques ou avancés, soit de code l'extraction et la mise à disposition des données;
• Les userforms utilisés en Excel sont inconnus d'Access et ne sont pas mis à disposition, facilement en tout cas, sur simple appel de la bibliothèque nécessaire à leur manipulation. Cela implique que même les userforms non liés aux données devront être recréés à la sauce Access;
• Il y a fort à parier qu'il va falloir repenser jusqu'à la découpe en tables, repenser les schémas de données et les liaisons entre elles, le typage des informations (inconnu d'Excel au niveau des colonnes d'une table);
• ...
• ...
• ...

Passer d'Excel à Access "en changeant quelques lignes" te fera courir droit à la catastrophe et il me semblerait judicieux de profiter de cette transformation qui est tout sauf bénigne pour repenser ton appli, ton besoin...

[Thumb down]

Bonjour,

L'applicatif utilise des userforms, des accès à des bases de données distantes, et toute une multitude de choses mais sans jamais utiliser le fait d'être "encapsulé" dans un document Excel (i.e je ne fais jamais appel à des objets Excel type Workbook et compagnie).

Désolé pour mes ilustres prédécesseur, mais je suis pas d'accord.

Certe le demandeur devra recréer tous ses formulaire sous Access, mais pas forcément l'intégralité du code vue que son traitement fait appel à une base de données externes et pas à des objets Excel.

Mais pourquoi pas passer en VB.Net. Vidual Studio Comunity est gratuit !

Pour ce qui concerne les 30 000 lignes je suis dubitatif également.

[Pierre Fauconnier]

Salut.

Perso, j'attends toujours de ceux qui prônent le passage VBA à VB.NET qu'ils exposent les avantages, inconvénients, checklists et autres. Dire "il y a aussi VB.NET" sans lister le pour et le contre (et s'il y a à mon avis peu de "pour", il y a à mon avis du lourd côté "contre") et en avançant comme unique argument le fait que c'est gratuit ne sert à mon sens pas à grand-chose.

Dire qu'il ne faudra pas revoir l'intégralité du code sans le voir, ce code, et notamment sans voir l'architecture de "l'application" et le code, ça ne me semble pas très raisonnable.

Laisser croire (je n'ai pas dit que c'est ce que tu faisais, Thumb) qu'il suffit de copier le code VBA vers VB.NET est à mon sens une tromperie.

VBA est essentiellement procédural, même s'il intègre des notions "Objet", alors que VB.NET est clairement orienté "Objet". Croire que l'on passe de l'un à l'autre sans douleurs est un leurre. Et je ne parle pas ici des contraintes liées à VB.NET (obligation de compiler, de déployer, d'installer les framerworks dot.net, ...) qui, en environnement pro, vont se heurter aux règles du service IT, notamment.

Je désespère toujours de voir un jour un tuto traitant de la migration VBA-DOT.NET d'un projet un peu construit (et un projet de 30000 lignes et de 80 formulaires, c'est un projet, certes mal construit, mais construit quand même).

Ca me fatigue (ce n'est pas une attaque personnelle, Thumb) que l'on vienne brandir la solution .NET sans évoquer les avantages/inconvénients, les chausse-trappes à éviter, la refonte du code, ..., et je n'ai encore vu nulle part un tuto ou un billet sur "comment migrer de vba à vb.net sans douleurs"... Clément Marcotte venait bêler et vomir du VB.NET à tout va, mais n'a jamais été foutu d'établir une checklist des avantages/inconvénients d'un passage à VB.NET, se contentant de brandir l'argument, inepte à mon sens, de la gratuité de la version Express (comme si on choisissait une solution sur l'unique critère de sa gratuité).

Le simple fait de devoir passer par l'IT de la boite pour pouvoir déployer sa solution (ben oui, n'importe quel quidam ne peut pas installer n'importe quoi sur son pc pro sans l'aval de l'IT... Faut pas oublier ça, quand même) va déjà poser un souci. Et faire croire que n'importe qui peut faire migrer son appli de VBA à VB.NET relève presque de l'injure envers les personnes qui passent du temps à obtenir un diplôme de développeur.

Du reste, mais ça reste un avis perso, tant qu'à basculer en .NET, alors, je basculerais en C#, VB.NET me semblant être une "attrape" Microsoft pour faire croire que VBA et VB.NET, c'est pareil et qu'il suffit de quelques tours de vis sur des copier-coller pour y arriver.


Du reste, sans voir l'appli dont il est question ici, ce n'est que pérorer que d'envisager des solutions, quelles qu'elles soient.

[Thumb down]

Je réitère ce que j'ai dis!

Il n'est pas forcément une obligations de réécrire tout le code pour passer en access VBA, mais sans doute une partie vu que le demandeur precise qu'il n'utilise pas d'objets Excel !

VB.net n'a absolument rien à voir avec VBA!
J'entends qu'il faut décocher la librairie visualiser Basic qui est comme tu le dis un attrap nigo de Microsoft

Passer en VBA.net permet une passerelle de compreantion entre VBA et vb.net

Je sais par expérience personnelle que le C# petturbe ! C'est un peu comme le français et l'anglais avec l'inverton du sujet. Je passai plus de temps pour une simple boucle For !

Notre ami utilises des Userform pour manager, selon lui, des bases de données distantes.

On peut être d'accord qu'une procédure qui récupère le résultat d'une requête peut être la même sous excel ou Access ?

Si d'aventure il as bien séparé les parti métier, client et base de données sous Access il n'aura que la parti formulaire à réécrire !

À l'époque où je développait en Vb6 je découpais mes projets en 3 tiers.

Chose que je fais toujours en C# et VB.net , je le faisais déjà pour le turbo Pascal dans les années 90!

Du reste, sans voir l'appli dont il est question ici, ce n'est que pérorer que d'envisager des solutions, quelles qu'elles soient.

[Pierre Fauconnier]

Je ne détiens pas LA vérité. Je donne juste mon avis et je ne vais pas dire à chaque fois "à mon avis"... Jusqu'ici personne n'est arrivé à me convaincre qu'il était simple de passer de vba à vb.net, ne parlons même pas de C#...

Les userforms vba n'ont rien à voir avec les forms de dot.net, de sorte que toute cette partie est a récrire;
Sur Access, on va pouvoir supprimer le codes d'échange Form <> DB, mais en vb.net, il va falloir tout récrire . Normalement pas en adodb mais en ado.net;
VB.NET est orienté objet, mais pas vba. Si même certains codes "génériques" passent, ils devraient, à mon avis, être récrits en .net pour mieux coller à l'orientation objet du langage;
Quid de l'installation des frameworks, du déploiement? Ce n'est pas le tout d'avoir la vision "developpeur" car après il faut compiler, installer... Dans sonnpetit microcosme à soi, ok, mais pour déployer chez les utilisateurs, c'est une autre affaire. Je connais quantité boîtes dans lesquelles le service IT bloque ce genre de trucs, à raison d'ailleurs.

On peut être d'accord qu'une procédure qui récupère le résultat d'une requête peut être la même sous excel ou Access ?

Non, ça dépend comment elle est écrite... Et tu parlais de vb.net, pas d'Access. Il ne faut pas me répondre en changeant de sujet ou d'orientation. J'ai dit que l'on pouvait garder certaines procédures entre Excel et Access, mais j'affirme que ce n'est pas le cas entre vba et vb.net. A toi de me prouver le contraire... Mais même avec Access, le simple fait que userform <> form et que les contrôles Access soient différents des contrôles de userform va déjà rendre une simple migration compliquée, voire impossible. Je serais curieux de voir comment on implante facilement un userform dans Access... Je veux bien des exemples, histoire d'apprendre. Pour ce qui est des connexions aux DB, dans la mesure où Access le permet nativement, on n'a normalement beaucoup moins besoin de s'y connecter par code, et de plus, Access lie DB et formulaires sans code. Dès lors, toute cette partie, aussi bien architecturée soit-elle, devient obsolète. Ce n'est pas pour autant que c'est "plus simple", car il faut redessiner les forms, et y placer le code vba qui servira au contrôle des saisies, etc. Dans la mesure où les forms et contrôles sont différents, il ne pourra pas non plus s'agir d'un simple copier-coller.

J'entends qu'il faut décocher la librairie visualiser Basic qui est comme tu le dis un attrap nigo de Microsoft

J'ai dit que la migration vba vb.net était justement bien autre chose qu'une simple liaison à des bibliothèques

Passer en VBA.net permet une passerelle de compreantion entre VBA et vb.net

Ca n'existe pas, VBA.NET. Et c'est bien là qu'est l'os. Beaucoup croient que VB.NET, c'est "juste" le grand frère de VBA, mais ce dont deux mondes radicalement différents, l'un étant objet et l'autre pas. Un simple copier-coller ne passe pas la rampe.


Si d'aventure il as bien séparé les parti métier, client et base de données sous Access il n'aura que la parti formulaire à réécrire !
[...]
À l'époque où je développait en Vb6 je découpais mes projets en 3 tiers.[/quote]
J'aurais apprécié tombé sur tes codes VB6, parce que de mon expérience, je tombe toujours sur des trucs pourris où les couches sont mélangées, avec des trucs en hard coding, avec des tableaux qui commencent parfois à 0 parfois à 1, avec des variables non typées, mal nommées, des fonctions qui sont elles aussi non typées...

Alors oui, si il y a une vraie découpe 3 tiers, la réécriture sera plus facile (je n'ai pas parlé de migration, parce que je n'y crois pas), mais je le répète, c'est rarement le cas. Et lorsque l'on me parle de 30.000 lignes pour un projet VBA, j'ai des doutes que ce soit du 3 tiers bien écrit, factorisé, etc... (Aucune attaque personnelle envers ted the Ors dans mes propos)



J'attends toujours que l'on me ponde un tutoriel expliquant la migration d'un projet vba en vb.net qui soit complet, explicitant la démarche, les inconvénients et les avantages, et qui soit tant à charge qu'à décharge. Et j'attends toujours que l'on me démontre que c'est simple et sans douleurs. Pas besoin donc de le prendre personnellement, il suffit de m'apporter des arguments techniques en béton (armé ).

Et encore une fois, j'exprime juste mon avis. Pas besoin de considérer mes.propos ni comme la Vérité Unique ni comme une attaque personnelle... 😘

[Thumb down]

Je parlais bien d'Access

Certe le demandeur devra recréer tous ses formulaire sous Access, mais pas forcément l'intégralité du code vue que son traitement fait appel à une base de données externes et pas à des objets Excel.

Elle je fais une suggestion

Mais pourquoi pas passer en VB.Net. Vidual Studio Comunity est gratuit !

Je passe !

[Pierre Fauconnier]

C'est marrant d'être accusé de mauvaise foi lorsque l'on n'est pas d'accord avec quelqu'un. Ca situe le niveau de l'argumentation technique...

Je réagissais bien plus à ta suggestion de VB.NET sous l'unique argument qu'il était gratuit. Et je maintiens ma position, il est utopique d'imaginer passer sans douleurs de VBA à VB.NET. Dès lors, de mon avis, il est inutile de proposer cette solution.

Passer en VBA.net permet une passerelle de compreantion entre VBA et vb.net

Tu parles de VBA.NET (???) comme d'une passerelle entre de compréhension entre VBA et VB.NET, mais VBA.NET, ça n'existe pas. Il y a VBA et VB.NET... Ca ne veut rien dire, ton truc. Que voulais-tu exprimer?

Pour ce qui est d'Access, je maintiens que les mondes sont différents et qu'il faudra une refonte du code, Access permettant de se passer de code pour les échanges Formulaire/DB, mais nécessitant une réécriture pour les vérifications des saisies et autres, puisque forms et userforms sont des choses très différentes, et les contrôles utilisés étant eux aussi très différents. Je pense donc que ce qui sera récupérable sera minime au regard des 30.000 lignes annoncées, puisque je mets ma main au feu que de toutes façons, il y a beaucoup trop de lignes là-dedans et que l'on peut factoriser. J'ai donné dans mes billets de blog et mes contributions du code générique qui peremt d'attaquer des DB en ADODB depuis Excel et ça fait économiser un paquet de lignes. Perso, je ne vois pas où il y a de la mauvaise foi dans mes propos.

A chacun son avis, bien sûr. Désolé que tu le prennes pour une attaque personnelle, mais je m'en fous. Le monde des bisounours où on doit être d'accord sur tout au risque de froisser des susceptibilités mal placées et dans lequel je suis confronté au vide abyssal et au néant des arguments techniques étayés, j'en ai un peu ma claque. Amenez des arguments techniques pour soutenir vos positions et on pourra discuter. Ca en devient franchement casse-c***, à la fin.

Je suis preneur, et je veux bien participer, d'un projet de migration d'un truc "Excel-VBA" même sans manipulation de données Excel vers de l'Access et/ou vers .NET, histoire de documenter de façon rigoureuse les méthodes à mettre en place, les avantages, inconvénients, embûches, problèmes, solutions d'un tel boulot. J'y apprendrais sûrement des trucs propres à me faire revoir ma position. Jusqu'ici, à par des "Mais pourquoi pas passer en VB.Net. Vidual Studio Comunity est gratuit !", je n'ai rien eu de concret. "C'est gratuit", c'est un peu faible pour moi. Clément Marcotte avait essayé une débilité qui ne tenait pas la route à coup de Lync mal torché, mais c'était loin de m'avoir convaincu. Ca plantait dans tous les sens et ça ne servait strictement à rien d'autre qu'à montrer qu'on savait avoir l'équivalent d'un listbox en .NET. Wouah, ça décoiffait. Mais sur le plan des arguments: Rien, nada, nuts.

Dur dur, les forums techniques qui s'apparentent à du mauvais FB

[Thumb down]

Si tu reprends mes propos J'ai enlever tout ce qui ce référait à la mauvaise foi car ça n'était aucunement justifié !

En revanche si le passage du VB au dot.net as été une formalité pour toi ça ne l'a pas été pour moi. Heureusement après plus de 15 ça mieux que bien !

[Pierre Fauconnier]

Au temps pour moi. Ton message parlant de mauvaise foi de ma part et que tu supprimé depuis, était apparu dans mon Outlook et c'est sur celui-là que j'ai réagis au départ, sans faire attention qu'il avait été supprimé