Discussion :

[siosnarf69]

Access 2016 version 16.0.11929.20436

Bonjour,

Le sujet suivant revient sur la table régulièrement, à savoir existe-t-il une solution efficace pour faire fonctionner le back end Access au travers d'un VPN (WAN) ?
Je dispose d'une application scindée en 2 parties: la base de données (back end) posée sur un serveur, et le frontal (front end) compilé en .accde déployé sur des postes clients.
Le frontal est connecté aux tables de ma base par des tables liées.

Mon application fonctionne très très bien en LAN (=dans les bureaux de l'entreprise) mais rame de fou en WAN. (=VPN à la maison)

En effet, comme vous l'avez surement vu ou lu, le problème d'Access est que c'est le font end qui fait tout le boulot et qu'il a besoin de toutes les données pour effectuer les requêtes, et que au regard de la latence engendrée par un VPN, c'est très très lent.
Donc les solutions comme déployer un SQL Server (ou autre) font que c'est le serveur qui bosse : Il reçoit les requêtes SQL du front end, il les traite et renvoie les données : Donc beaucoup moins de trafic réseau, peut impactant même pour du VPN avec de la latence.
On peut même créer toutes les procédures stockées dans le back end, comme ca c'est encore plus optimisé.


Malheureusement, n'ayant pas à dispo le serveur qui est administré par un prestataire, je suis coincé.

Ce qui me rend fou c'est que j'ai une fibre 1Go coté client et au moins 100Mo coté serveur ou est stocké le fichier Access et que malgré cela, un formulaire met 20 secondes à s'ouvrir avec l'utilisation du VPN.
Par contre la copie de fichier est très rapide forcément avec un tel débit théorique mais c'est cette latence qui tue Access.

Je pensais utiliser le TSE que je pourrais éventuellement avoir à dispo mais c'est pas sur, et c'est moins pratique que de démarrer son front end en local.


Bref, voila si quelqu'un a trouvé quelque chose depuis le temps que ce sujet existe, comme par exemple :
- une solution d'optimisation de requêtes depuis le frontal par exemple pour n'envoyer que le minimum d'info au back end Access
- un paramétrage d'Access pour "aspirer" le contenu d'une table ou même d'une base complète en SQL et ne bosser qu'avec ce cache local.
- une solution d'optimisation d'un VPN ou un type de VPN paramétré différemment pour réduire la latence.
- etc..

, ca m’intéresse !


Merci

[User]

Bonjour,

A première vue, je ne vois pas d'autre solution que d'optimiser les requêtes ou le code

Pouvez-vous poster une image de votre modèle de données avec les relations entre les tables ?

Cdlt,

[siosnarf69]

Bonjour,

Ayant aussi fait le test avec une base quasi vide, le temps de réponse est toujours inacceptable pour le commun des mortels... (avec le VPN activé bien entendu, en LAN ca bombarde)
Après ce sont plutôt les requêtes qu'il faudrait optimiser de par le mécanisme d'Access mais je ne sais pas si ca vaut le coup que je reprenne toutes mes requêtes pour par exemple limiter le renvoi (LIMIT) des clauses SELECT etc...
Ou si c'est peine perdue, ca ramera toujours...

A noter que je ne travaille qu'avec des RECORDSET dans mon code, pas avec des requêtes sources dans les formulaires, comme ca c'est moi qui gère les enregistrements dans la base.

Ci-dessous le schéma relationnel :


Cdt,

[User]

Après ce sont plutôt les requêtes qu'il faudrait optimiser de par le mécanisme d'Access mais je ne sais pas si ca vaut le coup que je reprenne toutes mes requêtes

Vous avez essayé d'ouvrir manuellement une requête pas trop complexe pour voir les temps de réponse ?

Cdlt,

[EricDgn]

Bonjour,
Une autre possibilité (non testée): contourner le problème par une connexion bureau à distance (RDP, RemoteApp, ...).
Cordialement.

[siosnarf69]

@User
Je viens d’exécuter un SELECT sur 2 champs sur une table avec 10000 enregistrements :
En LAN (réseau local) : 0,125 s
En WAN (VPN) : 5,781 s

Pour info, j'ai mesuré avec la fonction GetTickCount très pratique pour cela

Code :

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

Public Declare Function GetTickCount Lib "kernel32" () As Long

En gros, même si dans un formulaire tu as par exemple ne serait-ce que deux zones de liste à afficher avec une petite requête SQL intégrée à la propriété .RowSource de la zone de liste, et bien à chaque .Requery, tu prends 2 ou 3 secondes par zone de liste.


@EricDgn
Tout à fait c'est que j'évoquais dans mon 1er post, TSE ou Terminal Service, ou du "Connexion bureau à distance", je sais que ça fonctionne car le front et la base sont sur le même LAN voir le même PC, ce qui est parfait.
Mais, je ne suis pas sur que le prestataire me le permettra.

Ca pu ca pu