Salut
J'ai elaboré une DB Access qui devient de plus en plus grande, comment faire pour passer sous vb
Merci
Salut
J'ai elaboré une DB Access qui devient de plus en plus grande, comment faire pour passer sous vb
Merci
Bonjour
1 - Tu ne peux transformer un fichier .mdb en .exe
2 - Si tu veux passer en VB, il faut que tu réécrives tous (formulaires, etc..) et que tu ne gardes que les tables comme stockage.
Un peu plus de précisions sur la grosseur de ta base ou d'autres détails pour que l'on puisse un peu mieux t'aiguiller.
Bonjour
Pour compléter Starec, je dirais que, pour moi, ce n'est pas tellement un changement Access => VB qui serait nécessaire, mais d'abord Access => SQL server.
Dans un premier temps, cela te permet de ne pas modifier l'interface utilisé pour la gestion des données. Tu peux migrer assez facilement une base de données Access en SQL, puis réutiliser tes formulaires, états, modules... au travers d'un projet ADP (Access comme interface de SQL), sans trop de modifications (Attention toutefois, notamment, aux syntaxes des requêtes dans le code).
Dans un deuxième temps, tu pourras alors utiliser la puissance du SQL server via les procédures stockées, les déclencheurs... et alléger le travail des postes clients et le trafic réseau.
"Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
---------------
Mes billets de blog sur DVP
Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
---------------
Bonjour
Access ne gère pas les données en "client/serveur". Cela signifie que c'est le programme appelant qui se tape le boulot.
En clair, cela veut dire que lors d'une requête sur une base Access, c'est le "client" qui fait le travail d'extraction, de filtrage et de tri. C'est lui aussi qui réalise les opérations sur les champs calculés. Cela signifie plusieurs choses, notamment que c'est le processeur client qui travaille, mais aussi que la charge réseau est très importante.
Imaginons une base Access avec une table de 100000 lignes liées à une table de 10000 lignes. Si on lance une requête "inner join" sur ces deux tables, le "client" va devoir récupérer toutes les lignes des deux tables pour réaliser l'extraction, le filtrage, le tri et les calculs... Si cette requête est lancée régulièrement, on imagine très vite la surcharge sur le réseau. Et ce trafic réseau est multiplié par le nombre de postes qui "attaquent" la base Access.
SQL Server (produit Microsoft de gestion de données) est, comme son nom l'indique, un serveur de données. Le moteur de gestion est installé sur le serveur, le client pouvant alors devenir uniquement un consommateur de données. C'est d'autant plus vrai si la base SQL contient des procédures et fonctions stockées, car tout le travail d'extraction, de filtrage, de tri et de manipulation est délégué au serveur, qui "sert" uniquement le résultat via le réseau. De plus, alors qu'Access est de plus en plus lent en fonction de la taille des tables et du nombre "d'attaquants" simultanés, SQL Server a été conçu pour des volumes de données importants et un nombre de connexions simultanées élevé.
SQL Server peut être installé gratuitement en version light. Plus d'infos en suivant notamment ce lien.
Voilà, en bref, quelques différences entre Access et SQL
"Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
---------------
Mes billets de blog sur DVP
Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
---------------
Partager