Discussion :

[LeMin]

Bonjour à tous,

J'ai développé quelques applications Access sur un réseau local d'entreprise selon le principe Frontale / Dorsale.
Certains de mes clients (et c'est une demande croissante) souhaitent pouvoir accéder aux données à distance (et encore plus en cette période de confinement ! ).

Une solution "immédiate" que j'ai trouvé est de laisser 1 ou plusieurs postes dans l'entreprise accessibles via un logiciel de prise à main à distance (style Anydesk). Ici, rien de plus à faire au niveau Access.

D'autres clients, plus évolués dans leur infra structure (serveur microsoft), accèdent à leur poste via TSE, et se retrouvent donc à distance comme s'ils étaient dans l'entreprise. Donc, ici aussi, rien de plus à faire au niveau Access.

Récemment, un client a entendu parler de "sharepoint" et de la migration d'une base access locale vers "sharepoint". J'ai commencé à lire la littérature sur le sujet. Je n'ai pas vraiment l'impression que ce soit compatible avec une application Access existante. J'ai l'impression que je dois tout ré écrire pour transformer l'application car certaines fonctionnalités importantes manquent comme :
- le VBA
- requêtes analyse croisée
- le format conditionnel, ..

Au niveau des tutos, j'ai vu aussi qu'il est possible de mettre ses données sur un serveur SQL AZUR Database
http://www.devhut.net/2014/01/13/how...zure-database/

Et aussi de lier simplement mes tables à un serveur SQL avec la contrainte d'écrire le VBA avec la technologie ADO

Bref: je suis un peu perdu
J'ai compris que ce n'est pas si simple d'avoir ses données accessibles via internet, masi j'ai du mal a m'orienter vers une solution.
Si quelqu'un pouvait m'aider
Merci pour vos explications et conseils.

[nico84]

Bonjour,

C'est un besoin qui revient souvent et malheureusement il n'y a pas de solution miracle... Pour moi le plus simple est d'utiliser la solution TSE mais cela crée des instabilités des données (la frontale plante souvent )

Au niveau des tutos, j'ai vu aussi qu'il est possible de mettre ses données sur un serveur SQL AZUR Database

J'ai essayé ça marche avec un temps de réponse catastrophique

Et aussi de lier simplement mes tables à un serveur SQL avec la contrainte d'écrire le VBA avec la technologie ADO

ADO est nécessaire mais les tables liées restent en technologie DAO donc il faut s'interdire toute l'ergonomie "naturelle" d'access

Bref: je suis un peu perdu

Bref: je crains qu'il faille changer de technologie

Personnellement je suis au "milieu du gué" :
- frontale access avec tables liées mais toutes les requetes en ADO
- dorsale MSQL hébergée localement
- quelques modules ont été réécrits en technologie web pour accéder à certaines fonctionnalités depuis internet (saisie de commandes par les clients principalement aujourd'hui)

Pour avoir un logiciel "full web" il me faudrait réécrire tous les modules en technologie web > beaucoup de travail et à la fin une ergonomie mois bonne car cela va nécessiter de dépouiller les fenêtres

[LeMin]

Merci @nico84 pour tes lumières.

Tu as essayé SQL AZUR Database: faut il faire des modifs au niveau d'access pour essayer ce principe ?
s'il n'y a pas trop de modifs a faire, j'ai bien envie d'essayer: il n'y a pas beaucoup de données a traiter ...

[nico84]

C'était il y a pas mal d'années... Je me souviens que j'avais un peu galéré pour lier les tables ensuite c'est pareil en (beaucoup) plus lent
A l'époque mes requêtes étaient en DAO et mes écrans très chargés. En plus je n'avais pas la fibre. Avec la fibre, de l'ADO et des écrans lights ça peut marcher

[LeMin]

C'était il y a pas mal d'années... Je me souviens que j'avais un peu galéré pour lier les tables ensuite c'est pareil en (beaucoup) plus lent
A l'époque mes requêtes étaient en DAO et mes écrans très chargés. En plus je n'avais pas la fibre. Avec la fibre, de l'ADO et des écrans lights ça peut marcher

Du coup, j'ai envie d'essayer sur une petit appli de test.
J'aimerais utiliser un serveur SQL accessible via le web, gratuit si possible.
Que me conseilles tu pour démarrer ?

Et au niveau manip, j'ai cru comprendre que la base SQL est attachée à Access via un pilote ODBC, comme j'avais fait a l'époque pour récupérer les données de mon site Joomla sur un SQL local. https://www.developpez.net/forums/d1...phone-android/

Et il faut bannir les appels en DAO au profit des appels en ADO

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Private Sub Form_Load()
 
' en DAO:======================================================================
'Dim str_SQL As String
'Dim str_ValeurMetier As String
'Dim objDB As DAO.Database
'Dim objRcdset_Source As DAO.Recordset
'
'
'str_SQL = "SELECT DISTINCT ID_ProfilUtilisateur FROM t_ProfilsUtilisateurs_AntolaCOREADD  ORDER BY ID_ProfilUtilisateur"
'Set objDB = CurrentDb
'Set objRcdset_Source = objDB.OpenRecordset(str_SQL, dbOpenDynaset)
'Set Me.Type_utilisateur.Recordset = objRcdset_Source
'
 
'=================================================================================
'en ADO:
Dim objConnection As ADODB.Connection
Dim objRcdset_Source As New ADODB.Recordset
Dim str_SQL As String
Dim str_ValeurMetier As String
 
'Connection à la Base Access en cours
Set objConnection = CurrentProject.Connection
 
str_SQL = "SELECT DISTINCT ID_ProfilUtilisateur FROM t_ProfilsUtilisateurs_AntolaCOREADD  ORDER BY ID_ProfilUtilisateur"
Set objRcdset_Source = New ADODB.Recordset
objRcdset_Source.Open str_SQL, objConnection, , , adCmdText
 
End Sub

Aurais tu un petit tuto pour faire les manips dans l'ordre ?
Merci pour ton retour.

[nico84]

J'avais utilisé azur et comme c'était gratuit 2 mois j'ai arrêté quand j'ai vu que cela ne me convenait pas

Depuis j'ai fait l'inverse : c'est le site web (en techno web) qui interroge une base MSQL locale car 95% du trafic est local. Du coup je n'ai pas spécialement de conseil à donner sinon qu'il vaut mieux abandonner access si on veut une appli principalement web.


Concernant ton bout de code je vois au moins 2 bugs :
- objRcdset_Source est déclaré 2 fois
- Me.Type_utilisateur.Recordsetrecordset n'est pas renseigné

Avec une petite table comme source ça marchera bien (et en DAO aussi d'ailleurs). Il faut donc rapidement tester une requête complexe et avec un volume de données important avant de valider la méthode.
Enfin il y aura des petites surprises désagréables comme par exemple reset ou requery qui ne fonctionnent plus ou une gestion des accès concurrents moins performante. Il faut toujours garder en vue que pour MS, access est un truc de bricoleurs donc c'est pas grave si ça marche mal

[LeMin]

OK, Merci Nico84 pour ton retour.

Le petit bout de code, je l'ai récupéré d'une précédente discussion: c'était juste pour savoir si c'était la bonne méthode au niveau déclaration.

Je vais chercher un SQL accessible via le web.
Une fois mon choix fait, je reviendrai poster mes remarques.

Si je galère au niveau des déclarations ou du paramétrage, je me permettrai de revenir vers toi.

Bonne journée

[tee_grandbois]

bonjour, nico84,

Il faut toujours garder en vue que pour MS, access est un truc de bricoleurs donc c'est pas grave si ça marche mal

c'est une affirmation qui n'engage que toi et ta propre expérience
je n'ai pas le même avis, ayant eu l'expérience professionnelle avec des applications multi-utilisateurs et, pour certains clients, multi-sites (en Terminal SErver).
La différence réside peut-être du fait que la société où je travaillait avait mis les moyens autant en humains qu'en support technique (notamment des experts Microsoft) pour que cela fonctionne et cela peut faire grimper les budgets très haut ...

Qui penserait aujourd'hui à passer en premier lieu par la hot-line Microsoft (j'en conviens, il faut être un gros ou bon client) pour un problème concernant, il ne faut pas l'oublier, un logiciel développé par une des plus grosses multinationales américaines avant de passer par des forums tenus par des bénévoles ?

Je pense qu'une petite structure n'a pas ce réflexe, sans doute une question de coût ...

[nico84]

Bonjour,

c'est une affirmation qui n'engage que toi et ta propre expérience

Oui comme toutes les affirmations mais elle s'appuie sur 2 ou 3 faits bien réels :
- usage obligatoire d'un runtime
- incompatibilité du moteur JET avec internet et ce depuis près de 20 ans maintenant, c'est donc définitif ce qui conduit à un déclin inexorable
- en novembre on a presque tous été plantés suite à une mise à jour sauvage et MS a mis juste 1 mois à corriger ! Ca serait inimaginable avec SQL server même dans sa version gratuite (enfin j'espère...)
- la base de donnée est théoriquement limitée à 2Go mais en pratique elle devient instable bien avant (100Mo dans mon cas)

Alors oui on peut faire de très beaux bricolages, c'est vrai en menuiserie aussi

[LeMin]

Petite question de débutant sur l'utilisation d'un serveur SQL.
J'aimerais donc faire un essai.
1) Puis je commencer "simplement" par uniquement lier un serveur SQL par ODBC et ne pas faire de modif dans ma base Access ?
2) ou m'inscrire pour avoir une serveur externe SQL gratuit ? (ça n'existe peut être pas ?)

Merci

[nico84]

1) Puis je commencer "simplement" par uniquement lier un serveur SQL par ODBC et ne pas faire de modif dans ma base Access ?

C'est un test simple qui permet de voir ce qui est trop long et ce qui est acceptable (tout et rien dans mon cas)

2) ou m'inscrire pour avoir une serveur externe SQL gratuit ? (ça n'existe peut être pas ?)

Je ne suis pas spécialiste mais en général on paie pour l'hébergement et non pour le logiciel. L'hébergement gratuit ça existe surtout chez l'abbé Pierre
Par ailleurs il y a beaucoup de serveurs SQL disponibles, celui de MS, ceux d'Oracle, mariaDB, postgres... Tous ont une version gratuite mais il faut ensuite le serveur pour l'installer .Ca peut être un PC local dans un 1er temps mais bien sûr dans ce cas on ne teste pas les temps de réponse !

[LeMin]

Merci à toi.
je pense que je vais essayer "mon test simple" avec MS.

Bonne fin de journée.
Jean-Louis.