Discussion :

[thtioxine]

Bonjour,

j'ai plusieurs applications multi users développées en ACCESS/VBA possédant requêtes, formulaires, états, ... et qui , actuellement sont déployées de la façon suivante
A) La base de donnée sur un serveur
B) La base des formulaires sur chaque client par l'intermédiaire de tables liées

On voudrait se débarrasser de cette façon de faire car les montées de versions (soit système, soit Access) nous mettent systématiquement en difficultés. De plus, d'avoir des éléments sur les poste clients nous gênent

On voudrait donc s'orienter vers un système client/serveur tel qu'on pourrait en avoir avec un développement Web
Ceci nous permettrait de gagner suffisamment de temps pour étudier des scénarios de migrations vers JAVA/Postgres

Après avoir lu pas mal d'articles, il me semble que le mieux pour nous, serait d'avoir une VM portant ACCESS et SQL SERVER afin de migrer nos applications vers ADP, ce qui nous permettrait d'avoir un fonctionnement ne nécessitant plus de poser des éléments sur le client
Mais ma méconnaissance crasse d'ACCESS ne me permet pas de juger si j'ai raison ou si je me leurre complètement
J'ai vu que SHAREPOINT ne nous irait sans doute pas compte tenu des limitations actuelles de cet outil et qu'il nous faudrait, sur notre VM être en ACCESS 2010 et SQL 2008 , ce qui nous convient

Si une bonne âme peut me répondre, je lui en serais gré

A+

[nico84]

Bonjour,

Difficile de dire quelle est "la bonne solution", il y a plein de solutions plus ou moins concurrentes selon les circonstances. Qq remarques en vrac :
1. pour la dorsale, postgre et SQL server sont concurrents donc il est dommage d'en choisir un provisoirement pour aller sur l'autre ensuite
2. pour la frontale, access est bien adapté seulement si tous les utilisateurs sont connectés en ethernet (réseau local)
3. cette frontale n'est pas très complexe à déployer mais si c'est un problème ça marche aussi avec la frontale sur le serveur
4. le couple access / SQL server fonctionne bien si toutes les requetes sont en ADO (syntaxe SQL server). Les requetes complexes en DAO (syntaxe access) sont très lentes
5. il me semble qu'adp n'apporte pas grand chose et que d'ailleurs cela n'existe plus dans les versions récentes
6. la VM est aussi une solution simplement c'est plus contraignant pour les utilisateurs qui devront utiliser les 2 environnements. Personnellement je la réserve aux utilisateurs nomades ou connectés en bas débit (wifi, internet...)

Cela fait un certain nombre de compétences distinctes à acquérir donc il vaut mieux ne pas trop se disperser !

[thtioxine]

Bonjour et merci pour cette réponse

Effectivement le déploiement sur le client nous gène car on a déjà eu des chose de type "delete du répertoire",pb de droits au déploiement ou montée de version intempestive de certains postes et d'autre non
D'où l'idée de se retourner vers un pur client serveur
Pour ce que j'avais vu et testé ici, le frontal sur le serveur provoquait des blocages users et tous les forums indiquent la même méthode
Dorsale sur le serveur, frontal chez le client
On passerait toutes nos requêtes en ADO (Ca ferait partie de la migration)
ADP nous plaisait car il existe des outils de migrations et des tuto très complets dur le sujet.
Maintenant, c clair que dans les nouvelles versions ce serait SHAREPOINT sauf qu'en l'état, celui ci est trop peu abouti compte tenu de ce qui a été fait
Pour nous l'avantage de la VM est la stabilité du système et des outils (nous ne sommes pas maitre des montées de version, ce qui explique nos pb)

A+

[nico84]

Pour ce que j'avais vu et testé ici, le frontal sur le serveur provoquait des blocages users et tous les forums indiquent la même méthode
Dorsale sur le serveur, frontal chez le client

C'est vrai mais en pratique j'ai une appli de taille moyenne connectée à une base access et une base oracle. Tout est sur le serveur avec une trentaine d'utilisateurs (dont la moitié en VPN) et ça marche très bien

Je ne connais ni adp ni sharepoint donc je n'ai pas d'avis là dessus...

[thtioxine]

C'est vrai mais en pratique j'ai une appli de taille moyenne connectée à une base access et une base oracle. Tout est sur le serveur avec une trentaine d'utilisateurs (dont la moitié en VPN) et ça marche très bien

Je ne connais ni adp ni sharepoint donc je n'ai pas d'avis là dessus...

Y aurait t'il un paramétrage particulier à faire ?
Je vais me renseigner la dessus car ça va à l'encontre de tout ce que j'ai lu et ce qu tu dis ouvrirait une voie que nous avions abandonné vue notre expérience et les forums sur le sujet

A+

[nico84]

Non rien de particulier...
L'appli (compilée en accde et sans aucune table) fait 8 Mo, sa base 25 Mo (et la base Oracle beaucoup plus)
Je pense que le fait de laisser l'appli sur le serveur ne rajoute que 8 Mo de trafic sur le réseau lorsqu'un nouvel utilisateur se connecte, pour le reste cela ne doit pas changer grand chose.

La base access est liée à l'appli. Les tables Oracle les plus utilisées sont liées aussi, les autres en accès occasionnel par ADO.

C'est vrai que partout il est conseillé de déployer la frontale mais je n'ai pas constaté de gros gains donc je ne le fais pas systématiquement

[thtioxine]

Non rien de particulier...
L'appli (compilée en accde et sans aucune table) fait 8 Mo, sa base 25 Mo (et la base Oracle beaucoup plus)
Je pense que le fait de laisser l'appli sur le serveur ne rajoute que 8 Mo de trafic sur le réseau lorsqu'un nouvel utilisateur se connecte, pour le reste cela ne doit pas changer grand chose.

La base access est liée à l'appli. Les tables Oracle les plus utilisées sont liées aussi, les autres en accès occasionnel par ADO.

C'est vrai que partout il est conseillé de déployer la frontale mais je n'ai pas constaté de gros gains donc je ne le fais pas systématiquement

Ahhhhhhh, je crois comprendre
En fait Access ne contiendrait que les formulaires et les états
Le reste est supporté par Oracle, ce qui veut dire que tu dois faire de l'ado ou/et de la procédure stockée (ce que fait très bien oracle) et comme oracle est une base client/serveur, tu n'as pas le pb du passage de l'ensemble des données à chaque interaction
Oui, tu as raison, ça devrait marcher comme ça

A+

[nico84]

En fait Access ne contiendrait que les formulaires et les états

La frontale contient les formulaires
La dorsale les données saisies dans mon logiciel
La base Oracle les données de la GPAO (que j'utilise principalement en lecture)

Mes formulaires access appellent indifféremment des tables access ou oracle liées, je n'utilise ADO que pour des accès spécifiques en lecture ou en écriture sur la base Oracle. Il n'y a pas de procédure stockée.

[thtioxine]

La frontale contient les formulaires
La dorsale les données saisies dans mon logiciel
La base Oracle les données de la GPAO (que j'utilise principalement en lecture)

Mes formulaires access appellent indifféremment des tables access ou oracle liées, je n'utilise ADO que pour des accès spécifiques en lecture ou en écriture sur la base Oracle. Il n'y a pas de procédure stockée.

Ok , autant pour moi
J'ai relu le fil et je vois l'architecture.
En fait ça conforte l'idée que cette architecture est possible à la condition que les données ne soient pas dans ACCESS sinon,outre le formulaire, les données ACCESS vont être transmises et comme ACCESS ne sait pas transmettre juste ce qui est demandé mais des blocs de données, du coup les tps de réponse s'effondrent

Il y a un lien sur le moteur JET "http://papyturbo.developpez.com/access/articles/devpro/fr/accessdevpro_page3.htm" qui explique ce pb

En tout cas merci de ton aide pour y voir plus clair
En définitif, je retiens que :
A) Soit on va vers sharepoint mais à un coût qui me parait élevé
B) On fait du pur ADP mais tu as raison quand à sql server : C''est idiot de faire du sql server alors que la cible est postgre
ou
C) Un mixte comme toi : La données dans une base client/serveur et le reste dans access : Ça parait pas mal du tout

A+

[nico84]

En fait ça conforte l'idée que cette architecture est possible à la condition que les données ne soient pas dans ACCESS sinon,outre le formulaire, les données ACCESS vont être transmises et comme ACCESS ne sait pas transmettre juste ce qui est demandé mais des blocs de données, du coup les tps de réponse s'effondrent

Avec un réseau ethernet gigabit ça ne s'effondre pas si vite finalement et la base access est presque aussi performante que la base SQL quand les 2 sont vues par access comme tables liées. Surtout cela permet de très bonnes ergonomies car l'utilisateur a beaucoup d'informations sur son écran

C''est idiot de faire du sql server alors que la cible est postgre

Je voulais aussi migrer vers postgre mais pour l'instant j'y ai renoncé par manque de support et de forum dynamique. Pour l'instant j'utilise SQL server express dont les limites me conviennent et dont le SQL est plus proche de celui d'access. J'ai eu du mal à avoir une liaison performante entre access et SQL server mais au final ça marche bien et on a même un site de vente en ligne directement connecté à base locale grâce à la technologie .net qui semble assez en avance sur ce point

Ce sont des choix difficiles à faire car à un moment il faut se décider sans pouvoir tout tester en vraie grandeur

[thtioxine]

Avec un réseau ethernet gigabit ça ne s'effondre pas si vite finalement et la base access est presque aussi performante que la base SQL quand les 2 sont vues par access comme tables liées. Surtout cela permet de très bonnes ergonomies car l'utilisateur a beaucoup d'informations sur son écran

Je voulais aussi migrer vers postgre mais pour l'instant j'y ai renoncé par manque de support et de forum dynamique. Pour l'instant j'utilise SQL server express dont les limites me conviennent et dont le SQL est plus proche de celui d'access. J'ai eu du mal à avoir une liaison performante entre access et SQL server mais au final ça marche bien et on a même un site de vente en ligne directement connecté à base locale grâce à la technologie .net qui semble assez en avance sur ce point

Ce sont des choix difficiles à faire car à un moment il faut se décider sans pouvoir tout tester en vraie grandeur

Désolé du tps pour répondre
J'avoue que je ne saisie pas l'idée du nombre d'infos. Vu que ce sont des formulaires qui sont, in fine, renvoyé, les infos sont les mêmes quelque soit la base non ?
Notre IT préconise postgres, du coup on aura du support si nécessaire. Ça vaut donc le coup de tenter d'y aller.
On ira pas vers .net car ces outils sont développés et maintenus par des gens qui connaissent très bien vba mais pas du tout vb.net.

Oui, je suis d'accord. On va tester ACCESS / POSTGRES et si ça donne pas de résultats probants, on en restera sans doute à ACCESS/JET
Mais bon, si on arrive à ne plus avoir de frontal chez le client, ce sera déjà une bonne avancée

Bonne journée

[argyronet]

Bonjour,

J’apporte aussi ma petite contribution à ce sujet en exposant une possibilité qui n'est pas totalement stupide et qui fonctionne plutôt bien, à savoir, une connexion Terminal Serveur qui se traduit par un raccourci sur le bureau du poste utilisateur.

Le fichier *.rdp est configuré pour pointer sur la version locale de Microsoft Access du serveur complété à la chaîne représentant le chemin dans lequel est installée l'application à ouvrir avec la syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"%OfficePath%\MSACCESS.EXE" "%APPPATH%\App.accdb"

Le seul souci dans ce cas et que l'on ne doit pas partager une base de données dite frontale, en l'occurrence l'application qui est d'ailleurs liée à la base de données ne contenant que les tables dans le même répertoire.

Pour pallier à cela, il existe une solution pas très élégante certes, mais qui fonctionne : il suffit de dupliquer autant de fichiers représentant les applications frontales que nécessaire en les nommant expressément avec le nom de chaque utilisateur ou plutôt de donner un nom générique à ces applications frontales de manière à ne pas rendre exclusif, en quelque sorte, le nom de application pour un utilisateur donné...
Ainsi, les fichiers *.rdp verront leur ligne de commande modifiée avec le nom de l'application en conséquence du nouveau nom :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"%OfficePath%\MSACCESS.EXE" "%APPPATH%\App001.accdb"

Enfin et surtout, en cas de modification de la base frontale, il faudra faire en sorte que celle-ci possède une fonction de rattache automatique des tables et tout ce qui va avec. En cas de changement ou d'évolution de cette application, il faudra réitérer l'opération de duplication pour autant d'utilisateurs qu'il y a.

Je conçois que ce n'est pas très conventionnel comme mode opératoire, mais en tout état de cause c'est de loin le moins coûteux et le plus rapide à mettre en œuvre puisqu'il peut même fonctionner avec le Runtime ce qui évite une licence complète à installer sur le serveur.

Argy

[ypicot]

Un point important à prendre en compte : la volumétrie des tables.

En effet, si les tables sont "simplement" attachées, c'est JET qui continue à faire le boulot des requêtes... en local.
Cela signifie que si on a une table tClient et qu'on recherche seulement ceux qui habitent Trifouilli, toutes les données de tClient (et pas uniquement les trifouillens) vont débouler sur le réseau, pour que la requête soit effectuée sur le poste utilisateur (il y a différentes optimisations, mais l'idée générale est là).

D'où la nécessité, dès qu'on a des tables un peu volumineuses, de travailler au maximum avec des requêtes stockées sur le serveur, et de limiter au maximum l'accès "en direct" aux tables. C'est ce que faisait en natif le défunt .adp, dans lequel tout le boulot de requête se faisait sur le serveur.

Si on n'y prête pas attention, cette "petite nuance" peut rendre l'appli inutilisable dès qu'on dépasse certaines volumétries (lesquelles ? bonne question, cela dépend du cache, du réseau et de sa charge moyenne, du nombre d'utilisateur, ...). Donc, vive ADO Direct, mais il vaut mieux en tenir compte dès le début.

Concernant Sharepoint, il faut faire attention à la limitation des 5000 lignes, qui invalide sérieusement certaines applications.

Tout cela pour dire que, s'il y a du volume, la solution proposée par Argyronet est à envisager sérieusement.

Yvan

[nico84]

si les tables sont "simplement" attachées, c'est JET qui continue à faire le boulot des requêtes... en local.

Si les tables sont attachées mais les requêtes en ADO (sur une table MSQL ou postgre) le boulot est fait par le serveur me semble-t-il
Et les tables attachées restent accessibles directement par les fenêtres.

C'est surtout sur les requetes complexes que le gain est important. Tant qu'il s'agit d'un select basique sur 2 ou 3 tables JET s'en sort bien (ma plus grande table a 200.000 lignes)...

[thtioxine]

Si les tables sont attachées mais les requêtes en ADO (sur une table MSQL ou postgre) le boulot est fait par le serveur me semble-t-il
Et les tables attachées restent accessibles directement par les fenêtres.

C'est surtout sur les requêtes complexes que le gain est important. Tant qu'il s'agit d'un select basique sur 2 ou 3 tables JET s'en sort bien (ma plus grande table a 200.000 lignes)...

Désolé pour ma réponse hyper tardive

Enfin, bref, voici le retour de ce qui a été finalement développé (et mis en prod)
Compte tenu de toutes les remarques précédentes, on a choisi de ne plus utiliser de tables liées et on a choisi sqlserver car le driver ADODB est natif sur les postes
Donc, base sql express et formulaires ACCESS

Le gain de temps à été phénoménal (compte tenu que l'appli initiale avait peu de tables mais une très grosse)
Les modifications ont été assez longues (on en a profité pour gérer des transactions, documenter l'appli, nettoyer le code) et la simulation des maj dés qu'un champ change à été "ardue"
Le retour user est enthousiaste et le productivité pas mal augmentée compte tenu du moindre stress (attente qui énerve) et de l'utilisation de fonctions enfin utilisables (Certaine mettaient tellement de temps à répondre qu'elles n'étaient plus utilisées)

Merci de vos conseils

A+