Front end Access-BE mySQL ou SQL server: pré-requis dans la construction de la base access?

Bonjour à tous,

J'ai développé une appli access, splitée. Elle est assez petite: env. 20 tables, ttes avec un ID en num auto, env. 15 formulaires. Les requêtes sont directement en code SQL dans les procédures VBA. J'ai quelques procédures avec variables en argument et un module de classe.
Je pilote un fichier excel avec ma base access pour faire du power query et du power pivot.
Problème: les 5 utilisateurs sont aux quatre coins du pays. Après m'être documenté, je pense que la meilleure solution est d'opter pour FE sur Access, BE sur mySQL ou SQL server:
Questions:
- que pensez-vous de cette conclusion?
- quels sont les pré-requis pour passer les tables stockée dans le BE dans mySQL ou SQL server
- quelle solution est la meilleure ds mon cas: mySQL ou SQl server? Je pensais juste stocker les tables. Peut être vaut il mieux que je crée des requetes avec le requeteur et que je stocke aussi les requetes?
- le pilotage du fichier excel sera-t il toujours possible?

La littérature est foisonnante, je n'arrive pas à faire le tri et à définir un solution pour l"instant. Donc un immense merci par avance.
Etxe.

Bonjour,

Access n'est vraiment pas le bon outil pour faire ça, le travail à distance est de loin son plus gros point faible.

La raison est que par défaut il ne fait rien coté serveur mais importe toutes les données sur le poste client et les traite localement. Il y a quand même une exception si on utilise systématiquement ADO sans lier aucune table. Ensuite il faut développer une interface "minimaliste" qui affiche uniquement les données strictement nécessaires (alors qu'en standard access montre toutes les données)

Avec ces contraintes ça peut marcher mais on perd tout ce qui fait qu'access est si pratique...

Bonjour,
Merci beaucoup pour ce retour d'expérience.
Dans mon cas l'appli est petite, j'affecte systématiquement comme valeur à mes contrôles et sous formulaires des DAO.recordset basés sur des requetes que j'écris en code SQL dans les procédures VBA.
Je peux envoyer un exemple si besoin.
Une question: qu'appelles-tu "interface minimaliste" s'il te plaît?
Merci d'avance.
Etxe.

Citation:

---

Envoyé par Etxezarreta

Dans mon cas l'appli est petite, j'affecte systématiquement comme valeur à mes contrôles et sous formulaires des DAO.recordset basés sur des requetes que j'écris en code SQL dans les procédures VBA.

---

On peut le faire en ADO aussi (surtout s'il s'agit d'une requete complexe) par contre c'est en lecture seule je crois

Citation:

---

Envoyé par Etxezarreta

Une question: qu'appelles-tu "interface minimaliste" s'il te plaît?

---

N'afficher que ce que l'utilisateur a demandé, dans l'esprit d'un site web (pas de vue sur toute une table en liste comme le fait access nativement)

bonsoir
petite précision:
ADO (ActiveX Data Objects), bibliothèque logicielle d’accès aux données
DAO (Data Access object), objet d'accès aux données
sont 2 méthodes différentes d'accès aux données

Bonjour Nico84 et Tee,

Il apparaît en effet que ADO est bien plus indiqué pour travailler avec SQL server en BE.
Je suis en train de changer la syntaxe des lignes de code: j'ai mis un exemple ci-dessous (code DAO en haut, ADO en bas): ça fonctionne pour la version ADO, que je ne connaissais aps du tout. Je suis entrain de me documenter durement, avez-vous une remarque sur les bonnes pratiques de syntaxe ou autre svp?
Lorsque je mettrai les tables sur SQL server je devrais modifier l'objet connection n'est ce pas? Il vaudrait ainsi mieux le passer en variable?
Encore merci.
Etxe.

Code:

---

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

---

Oui vu comme ça c'est presque pareil à l'objet connexion près mais en fait pas tant que ça :

1. en DAO le recordset est constitué par le moteur JET d'access, en ADO le serveur crée une vue à la demande d'access et la met à sa disposition. Pour des cas complexes les temps de réponse et la charge réseau sont très différents.
2. cette syntaxe transfère TOUTES les données à la form mais souvent en web ça en fait trop > temps de réponse pourri sauf à mettre un top 10 ou un filtre adéquat
3. en DAO on utilise toujours le SQL access alors qu'en ADO il faut utiliser le SQL de la base et alors on s'aperçoit que le SQL n'a de standard que le nom :(

J'ajoute pour le point 3 que le SQL access (le fameux moteur JET) est très peu performant pour interroger une base non access c'est pourquoi ADO est impératif pour une base non access qu'elle soit locale ou sur le web (sauf pour de petites applis simples)

C'est pourquoi je parle d'interface minimaliste : une form qui affiche peu de données et qui ne permet de les modifier qu'individuellement par code

J'espère être clair. Malheureusement access est le seul outil que je maitrise correctement aujourd'hui et je dois faire appel à d'autres développeurs quand je veux des outils web car avec access je n'arrive à rien et quand je vois ce qu'ils font je n'y comprends rien :calim2: Mais ça marche :mrgreen: