Discussion :

[fevec]

Bonjour à tous,
Je poste ici car il me semble que c'est l'endroit du forum Access, le plus adapté.
Nous avons une application métier développé (qui évolue au quotidien) depuis l'année 2000, qui tourne majoritairement sous Access 2003 et Access2016.
(et tournerait encore sous Access97, si les évolutions de Windows ....)
Frontale et dorsale en .mdb (access 2003)
Frontale et dorsale en .accdb (access 2016)

Tables liées entre frontales et dorsales par DAO. (50 aines de tables liées, mais pas de tables énormes, ex : TblArticles : 35 000 lignes ; maxi 45000 lignes)
(les dorsales font entre 120 et 200 Mo environ)
Beaucoup de code VBA sur l'application Frontale
L'application est à la fois une gestion client (CRM), un logiciel de gestion commerciale, et un logiciel technique métier...
(il y a un module statistiques, avec beaucoup de requêtes complexes, et là on mesure bien les "faiblesses" d'access, mais il ne sert pas au quotidien..)


L'application tourne dans 12 entreprises différentes, en réseau local. (de 1 à 6 utilisateurs suivant les sites)
- 9 entreprises : en poste à poste, sans serveur, un PC sert de "serveur")
- 3 entreprises : en réseau local avec un vrai serveur (Windows server 2008 R2, 2012)

Nous sommes passé sous Access2016 sur 3 sites, par rapport à des pb de comptabilités avec les évolutions de Windows ou les pack office présents (souvent versions plus récentes). On a eu en 2020 des problèmes de base endommagés régulièrement (format de base de données non reconnu).....
que nous avons attribué à ces interférences entre version de pack Office..
ce qui nous amené à passer en Access2016 sur 3 sites.

On a parfois quelques légers soucis de temps de réponse de l'application

Nous sommes dans une phase de réflexion sur l'évolution du logiciel :

Les questions que nous nous posons :
- vers quelle version d'access faut il migrer ? 2016 ? 2019 ? : quels bénéfices ?
(état PDF natif, ça j'ai bien intégré...)
- faut il rester en frontale, dorsale avec DAO ?
- faut il que la dorsale passe dans SQL server ? (ou autre base sql)
- faut il passer en runtime ?
- etc...
Bien sur on se pose la question coûts-bénéfices..
(notamment le temps de modification du code VBA, suivant certains choix, (ex : passage en ADO si projet ADP)

Pour les accès à distance à l'application (frontale sur le poste, dorsale à distance) : il me semble d'après ce que j'ai lu sur le forum ou ailleurs, que rien n'est probant (Access pour Web n'existe plus, SharePoint, Azure..)
Access n'est pas adapté à cela si j'ai bien compris..

J'ai vu dans cette discussion qu'Agyronet évoquait la piste Terminal Server
https://www.developpez.net/forums/d1...onne-solution/

à laquelle je vois les points positifs suivants :
-on garde notre application, frontale-dorsale, on reste en DAO, on modifie pas (ou peu) le code..
-éventuellement cela solutionne la question de l'accès à distance (je pratique déjà comme cela sur un site)
qui n'est pas une demande prioritaire des clients (quoique...contexte codiv-19 avec le télétravail...)

Question subsidiaire : faut il des versions d'access (ou des pack Office) spécifiques pour tourner sur serveur Windows 2008, 2012, etc...
(de mémoire, j'avais essayé d'installer un pack office pro "classique", et j'avais reçu un message me signalant que la version n'était pas la bonne pour un serveur..)

Voilà, cela fait pas mal de questions, en espérant avoir été clair.
Merci de vos avis toujours éclairés.
Bonne journée,

[nico84]

Bonjour,

Effectivement ça fait beaucoup de questions...
Tu parles d'une application mais de plusieurs frontales et dorsales dans des versions différentes d'access. Faut-il comprendre que "l'application" est morcelée en plusieurs logiciels ?

Pour ma part j'ai développé un ERP utilisé par une petite dizaine d'entreprises indépendantes et selon la taille de l'entreprise la dorsale peut être soit en access soit en sql server express. Cela marche très bien mais au début du projet j'avais des temps de réponse inacceptables en SQL server et j'ai donc dû simplifier quelques fenêtres et surtout réécrire la plupart des requetes VBA en ADO (donc avec une syntaxe mixte access / SQL server)
Exemple simple :

Code :

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

cnx.Execute "UPDATE rma SET e_rma='S', fin_rma=" & IIf(msql, "cast(getdate() as date)", "date()") & " WHERE cd_rma='" & cd_rma & "'", dbFailOnError

(les dorsales font entre 120 et 200 Mo environ)

C'est à partir de cette taille de dorsale (après compactage bien sûr) que j'ai commencé à avoir des problèmes de fiabilité. En SQL server express j'en suis à 500Mo sans souci. Par contre il y a plein de nouveaux trucs à apprendre : ADO, le SQL de SQL server, le transact SQL, l'administration de base de données...

La version d'access joue à mon avis assez peu. Seul les développeurs ont besoin d'access, les autres peuvent tous avoir un runtime et pas nécessairement de la même version que leur office. Personnellement je développe en 2007 ainsi je garde une compatibilité ascendante depuis cette version et les utilisateurs ont entre 2007 et 2019.

Pour les accès à distance à l'application (frontale sur le poste, dorsale à distance) : il me semble d'après ce que j'ai lu sur le forum ou ailleurs, que rien n'est probant (Access pour Web n'existe plus, SharePoint, Azure..)
Access n'est pas adapté à cela si j'ai bien compris..

Oui c'est aussi mon expérience. Par contre une base SQL server locale peut être interfacée avec un site web donc on à terme on peut faire migrer certaines fonctionnalités vers le net

J'ai vu dans cette discussion qu'Agyronet évoquait la [B]piste Terminal Server

Le TSE fonctionne bien en local (utilisateurs équipés de "platines" au lieu de PC complets) mais à distance je n'ai pour l'instant pas d'utilisateur régulier même si ça marche aussi

Question subsidiaire : faut il des versions d'access (ou des pack Office) spécifiques pour tourner sur serveur Windows 2008, 2012, etc...

Oui il faut une version server qui est un peu plus chère