Discussion :

[Filou07]

Bonjour,

J'ai développé une base qui fonctionne en réseau. Mes collègues me demandent de pouvoir saisir des données sur le terrain (offline) avec leur tablette windows dans une base Access dédiée et de pouvoir les synchroniser à leur retour au bureau. Ils doivent pouvoir partir avec certaines tables à jour (communes, noms de fournisseurs...).

A force de réfléchir je tourne un peu en rond et j'ai besoin d'aide pour en faire ressortir un mode de fonctionnement optimal.

Pourriez-vous m'aider ?

[Gabrieel]

Bonjour

si c'est pour rajouter des données , voici ce que je ferai
créer les applis en stand alone (base fractionnée executable sur poste de saisies , base de données en réseau)
Création d'une table "Offline"
création d'un bouton qui permet de "synchroniser" quand on est connecté au réseau (un bouton qui rajoute les données ou les modifies)

Bien cordialement,
Gabrieel

[shishi666]

Bonjour,
avec un collègue nous avons été confronté au même problème (enfin je pense).

Nos collègues utilise une appli Access avec des tables liées vers une base postgres, lorsqu'ils souhaitent partir sur le terrain faire des mesures on leurs créé une base access sur leur tablette contenant les données dont ils ont besoin sur le terrain (cette base est créée grace à un outil comme talend open studio.
Puis à leur retour du terrain, toujours grâce a talend open studio on effectue certains contrôles sur les saisies puis on intègre tout dans la base postgres.

Je ne sais pas si cela peut répondre a ton besoin.
Bonne journée
Shishi

[Filou07]

Merci pour vos contributions !

[jb.43]

Bonjour à tous.

Je me permets de relancer la discussion car elle correspond le mieux à ma question.

J'ai créé une BDD access destinée à recceuillir des données de suivi de la faune sauvage de façon simultanée dans 2 départements.
Je souhaiterais que les techniciens puissent récolter les données hors ligne ( et de façon simultanée sur les deux sites) grâce à des tablettes de terrain hors ligne (qui seront connectées à un serveur à distance le soir).

Le problème est que je ne sais pas comment gérer la synchronisation de façon à ce que les données saisies la journée soient intégrées le soir et inversement, que les données saisies sur les deux sites soient dispatchées sur toutes les tablettes.

Il faut que les techniciens soient autonomes dans cette synchronisation et que cela soit le plus simple possible pour eux (du genre un bouton synchroniser et voilà).

D'après ce que j'ai pu voir il faut que je suive la démarche suivante:

1- fractionner ma base en conservant les données sur un serveur commun et copier le second fichier sur chaque tablette.

2- créer une table «off line». Mais quel serai son contenu ?

3- créer un formulaire avec un bouton synchroniser si j'ai bien compris. Ne faut-il pas que je lie mes tables à un moment ?

Bref, je n'y vois pas très clair sur comment faire et j'apprends un peu tout seul avec l'aide des forums donc vos conseils me seront d'une grande utilité.

Merci beaucoup d'avance !

Jb

[marot_r]

Bonjour.

Un des problèmes avec la synchronisation c'est de détecter les données, ajoutés, modifiées ou supprimées et de les "fusionner" dans une seule BD "Centrale".

• Si tu as un découpage "clair" de tes données ç-à-d que X travaille uniquement sur les données du secteur Y, W ne travaille que sur les données du secteur Z et à aucun moment X n'a besoin des données de W et vice versa) alors c'est assez simple.
  
  Tu crées une BD qui contient toutes les données dont la personne à besoin pour faire la saisie dans son secteur.
  Les tables peuvent variées selon les besoins. C'est évidement les tables des données du secteur mais cela peut-être aussi des tables de référence qui sont utilisées par tout le monde.
  
  
  1. Le matin, la personne copie ses (oui les siennes) sur son poste (ex toutes les données du secteurs Y).
     Note que cela peut inclure des tables communes.
  2. La personne met à jour ses données.
  3. Le soir la personne se connecte.
  4. Le système détruit toutes les données de l'utilisateur dans la base centrale.
  5. Le système recopie les données de l'utilisateur dans la base centrale.
     Les tables "communes" ne sont jamais reprise des postes.
     Si elles doivent être mise à jour cela se fait dans la BD centrale.
     Attention si tu as des tables "personnelles" mais en relation, la recopie doit être assez subtile pour le gérer. (de même pour la copie le matin).
     Dans les autres cas c'est simplement une requête d'ajout sur les tables "centrales" liées qui preine leur données dans les tables "Locales".
  
  
• Si tu as des données communes qui sont modifiées, là c'est plus corsé car il va falloir les détectées ET décider qui a raison.
  La meilleur solution est d'ajouter à tous tes enregistrements un "timestamp" (horodateur) et l'identification de l'utilisateur.
  Après, avec du code il faut faire les fusions.

Dans quelle situation es-tu ?

Note qu'on peut n'avoir qu'une seule version de l'application qui couvre l'aspect mobile et fixe mais il faut le penser attentivement.

A+

[Filou07]

Bonjour,

Si ça peut aider, j'ai adopté la solution suivante :

Au niveau des tables :

1. utilisation des tables liées pour le mode "en ligne",
2. les mêmes tables locales avec le suffixe "_COPY" pour partir avec une copie des données,
3. d'autres tables locales avec structure identique aux tables liées avec le suffixe "_OFFLINE". Ces tables sont destinées à recevoir les nouveaux enregistrements et les enregistrements modifiés
   

Création d'un formulaire "Synchronisation" avec 2 boutons [Je pars] et [J'arrive].

Le bouton [Je pars] n'est actif que si les tables "_OFFLINE" sont vides. Il nécessite d'être en ligne. L'utilisateur choisit les enregistrements avec lesquels il veut partir : ils sont alors recopiés dans les tables "_COPY" et se voient attribués d'un flag qui les rend "en lecture seule" pour les autres utilisateurs connectés.

Sur le terrain chaque enregistrement modifié ou créé est mis dans les tables "_OFFLINE" (avec un flag "nouveau" ou "modif") et dans les tables "_COPY"

Le bouton [J'arrive] est actif s'il y a des enregistrements dans les tables "_OFFLINE". Il faut être connecté au réseau. Tous les enregistrements de ces tables sont mis à jour/créés dans les tables liées. Les tables "_OFFLINE" et "_COPY" sont ensuite vidées.

[jb.43]

Bonjour et merci pour vos réponses.

Je vais vous détailler un peu plus ma base de données si cela peut vous permettre de mieux comprendre mes besoins et cerner quelle solution serait la meilleure.


La base est composée de 10 tables toutes identifiées par une double clé primaire correspondant aux champs suivants: "SITE" avec deux modalités selon le site d'étude et "ID" avec un numéro automatique.

Dans ce cette configuration et pour répondre à marot_r, je pense que le découpage est assez clair entre les sites (sous réserve que l'utilisateur ne se trompe pas en saisissant le champ "site"). En revanche, dans cette configuration il ne me sera pas possible de scinder les données par besoin propre à chaque site puisque les données des deux sites sont saisies au sein des même tables.

Au niveau de la facilité d'utilisation pour les technicien, je pense que la solution proposée par Filou_07 (avec simplement 2 boutons) est la mieux mais je n'ai pas assez d'expérience pour savoir si elle correspond au mieux à ma BDD.

Mon faible niveau en Access fait que j'ai plusieurs questions pour mieux comprendre:

Utilisation des tables liées pour le mode "en ligne"

=> Autrement dit, j'utilise ma base de données classique avec toutes mes relations c'est cela ?

l

es mêmes tables locales avec le suffixe "_COPY" pour partir avec une copie des données,

=> Concrètement je fais cela en fractionnant la base de données ? Ou je crée de nouvelles tables dans une base de données distincte de la première ?

d'autres tables locales avec structure identique aux tables liées avec le suffixe "_OFFLINE". Ces tables sont destinées à recevoir les nouveaux enregistrements et les enregistrements modifiés

=> Même question

Création d'un formulaire "Synchronisation" avec 2 boutons [Je pars] et [J'arrive].

Le bouton [Je pars] n'est actif que si les tables "_OFFLINE" sont vides. Il nécessite d'être en ligne. L'utilisateur choisit les enregistrements avec lesquels il veut partir : ils sont alors recopiés dans les tables "_COPY" et se voient attribués d'un flag qui les rend "en lecture seule" pour les autres utilisateurs connectés.

Sur le terrain chaque enregistrement modifié ou créé est mis dans les tables "_OFFLINE" (avec un flag "nouveau" ou "modif") et dans les tables "_COPY"

Le bouton [J'arrive] est actif s'il y a des enregistrements dans les tables "_OFFLINE". Il faut être connecté au réseau. Tous les enregistrements de ces tables sont mis à jour/créés dans les tables liées. Les tables "_OFFLINE" et "_COPY" sont ensuite vidées.

=> Cette interface me parait simple d'utilisation pour les techniciens mais concrètement, je ne vois pas comment faire. Je dois créer quel type de macro liée à l'exécution des deux boutons? Liée à une/des requêtes de mise à jour ?

Désolé pour mes questions mais vous pouvez le constater, l'apprentissage sur le tas a parfois des limites.

Merci beaucoup d'avance de votre aide.

Jb

[marot_r]

Bonjour.

Avant de te lancer dans une solution il serait important de savoir comment tes données sont partagées.

Sinon pour répondre à tes questions.

Pour la base locale (celle accessible sans connexion au réseau), au niveau de la structure elle peut être une simple copie de ta base centrale (celle accessible quand on est connecté).

L'idée générale est d'avoir 3 bases :

Base Frontale de saisie

Base Locale (utilisable hors connexion)
Base Centrale (utilisable avec connexion)

Le pont entre les 2 bases se fait via ta base frontale qui est liées aux tables de la base locale et aux table de la base centrale.

La manière de transférer de la loacle à la centrale et vice versa dépend de la réponse à la question initiale sur le partage des données.

Et au niveau pratique si passes toujours par des requêtes pour accéder à tes tables, basculer la même appli de loacle à centrale se fait assez facilement.
Cela te permet de n'avoir qu'une seule version de l'application qui marche partout.

Si tu retiens cette idée, tu as pour chacune des tables une requête reqNomTaTable qui vaut soit :

Code sql :

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

select [nomTaTableLocale].* from [nomTaTableLocale]

Code sql :

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

select [nomTaTableCentrale].* from [nomTaTableCentrale]

Au moment de la connexion ou de la déconnexion, tu modifies le SQL de tes reqNomTable par VBA pour les "brancher" sur les bonnes table.

Les seules exceptions à cela ce sont les requêtes pour le transfert de local à centrale et vice versa.

Ci-joint une micro maquette d'une architecture possible

Synchro.zip
Il te faut refaire les liens des tables pour pouvoir la tester.

Dans cette maquette les 2 BD dorsales ont exactement la même structure mais il n'est pas obligatoire qu'il en soit ainsi dans ton appli.

Le fromulaire frmChangerSource te permets de passer d'une frontale à l'autre.
Il faut que les autres objets soient fermés quand tu fais le basculement.
Note qu'il n'y a pas de transfert de données, juste un basculement vers une autre source.
Grâce aux requête, les formulaires de consultations res identiques quelle que soit la source.

A+

[Filou07]

Pour faire un mix entre tes questions me concernant et la solution évoquée par marot_r :

Mon organisation fonctionne sur 2 bases Access : la base centrale et base frontale (qui équivaut à base frontale + la base locale de Marot_r ). La solution à 3 bases est pas mal aussi car si tu mets à jour la frontale (correction de bugs, nouvelles fonctionnalités...), les données locales ne sont pas perdues.

La base de données frontale est celle que tu appelles "ma base de données classique avec toutes mes relations"

Quand tu dis

"Concrètement je fais cela en fractionnant la base de données ? Ou je crée de nouvelles tables dans une base de données distincte de la première ?"

=> Je réponds :

• Si tu utilises 2 bases : il faudra lancer une copie des tables de la base centrale vers la frontale (en leur donnant un suffixe _COPY par exemple)
• Si tu utilises 3 bases : un simple changement de chemin dans les tables liées suffit.

Dans tous les cas, il te faudra passer par des macros (bof bof) ou du code vba (mieux !)

Cette interface me parait simple d'utilisation pour les techniciens mais concrètement, je ne vois pas comment faire. Je dois créer quel type de macro liée à l'exécution des deux boutons? Liée à une/des requêtes de mise à jour ?

=>Tu ne pourras pas échapper à l'écriture de code vba

[jb.43]

Bonjour à vous deux et merci beaucoup pour vos réponses (PS: désolé pour le retard de retour de ma part).

Pour répondre à la question sur le partage des données, celles-ci seront partagées sur un serveur VPN.

Merci beaucoup pour ce modèle. Je vois un peu mieux la marche à suivre maintenant. Je vais essayer de résumer ce que je dois faire ci-dessous. Merci de me reprendre si ce n'est pas cela.

1- Concrètement, la "frontale" c'est ma base de données telle qu'elle est actuellement c'est bien cela? Cependant, par la suite, il faudra que je réalise dans cette base une copie de toutes les tables avec le suffixe centrale ou locale ?

2- Ensuite, je copie cette base frontale sur les tablettes des différents utilisateurs, de même que les tables (et uniquement les tables) "locales" pour un usage hors connexion. Pour ne garder que les tables, je procède à un fractionnement de la BDD frontale ?

3- Idem, je réalise une copie des tables "centrales" sur le serveur VPN.

4- Je lie les tables locales/centrales via la base frontale.

5- Je crée dans la BDD frontale un formulaire de synchronisation avec un champ de liste de déroulante et un bouton de MAJ relié à la procédure événementielle suivante:

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
31
32
Option Compare Database
Option Explicit
 
Private Sub bnChangerSource_Click()
 
    If Me.lstSource & "" = "" Then
        Exit Sub
    End If
 
    Dim db As DAO.Database: Set db = CurrentDb
    Dim t As DAO.TableDef
    Dim r As DAO.QueryDef
 
    For Each t In db.TableDefs
 
        If t.Connect <> "" Then
 
            If t.Connect Like "*_" & Me.lstSource & ".accdb" Then
                'C'est une table de la BD source
                Set r = db.QueryDefs("req" & t.Name)
                'Change le SQL de la requête
                r.SQL = "select [" & t.Name & "].* from [" & t.Name & "]"
            End If
 
        End If
 
    Next t
 
    Set t = Nothing
    Set r = Nothing
    db.Close: Set db = Nothing
End Sub

Je ne maîtrise pas vraiment le code.

6- les utilisateurs de tablettes peuvent synchroniser leurs données en sélectionnant la source locale quand ils reviennent du terrain puis centrale avant de repartir. C’est bien cela ?

Est-ce-que je loupe une étape dans le cheminement ?

Merci d’avance.

[marot_r]

Bonjour.

Pour répondre à la question sur le partage des données, celles-ci seront partagées sur un serveur VPN.

Quand je parlais de partage des données, je parlais de partage des données entre les utilisateurs pas comment tu vas les partager techniquement.
Donc est-ce qu'il a des démarcations franches dans tes données ?
Par exemple le commercial qui couvre la région parisienne n'a pas besoin des données qui concerne provence-côte d'azur et vice-versa.
J'ai pris l'exemple d'un découpage géographique mais cela peut être un autre découpage, sur les games de produit par exemple.
Bref n'importe quoi qui permette de savoir que ce sont les données de machin et pas de truc.

1- Concrètement, la "frontale" c'est ma base de données telle qu'elle est actuellement c'est bien cela?
Cependant, par la suite, il faudra que je réalise dans cette base une copie de toutes les tables avec le suffixe centrale ou locale ?

Si tu vas avec 3 bases oui.

2- Ensuite, je copie cette base frontale sur les tablettes des différents utilisateurs, de même que les tables (et uniquement les tables) "locales" pour un usage hors connexion.
Pour ne garder que les tables, je procède à un fractionnement de la BDD frontale ?

Oui

3- Idem, je réalise une copie des tables "centrales" sur le serveur VPN.

Oui.

4- Je lie les tables locales/centrales via la base frontale.

Dans ma solution, tu relies la frontale aux 2 bases dorsales.
Ensuite tu décides dans les requêtes où tu vas pécher les données.

Dans l'autre solution, oui tu décides de l'un ou de l'autre au niveau de la liaison.

5- Je crée dans la BDD frontale un formulaire de synchronisation avec un champ de liste de déroulante et un bouton de MAJ relié à la procédure événementielle suivante:

Ce code change les sources de données, il ne fait pas la synchronisation.

6- les utilisateurs de tablettes peuvent synchroniser leurs données en sélectionnant la source locale quand ils reviennent du terrain puis centrale avant de repartir. C’est bien cela ?

Non, il faut faire du code pour cela. Et après changer la source, le simple changement de source ne suffit pas.
Le code peut être déclenché par l'utilisateur mais cela te prend du code et probablement des requêtes de synchronisation.
Le tout dépend de la question initiale : sur quel critère tes données sont-elles réparties entre tes utilisateurs.

A+

[Filou07]

Bonjour,

Je plussoie la réponse de Marot_r

[philippe.paul]

Bonsoir,

Je suis très intéressé par la méthode que tu proposes, as-tu la possibilité de développer un peu plus ta procédure ? Quelle méthode pour recopier les enregistrements choisis dans les tables _COPY et OFFLINE ?

As-tu une base exemple ?

Merci d'avance.

Bonjour,

Si ça peut aider, j'ai adopté la solution suivante :

Au niveau des tables :

1. utilisation des tables liées pour le mode "en ligne",
2. les mêmes tables locales avec le suffixe "_COPY" pour partir avec une copie des données,
3. d'autres tables locales avec structure identique aux tables liées avec le suffixe "_OFFLINE". Ces tables sont destinées à recevoir les nouveaux enregistrements et les enregistrements modifiés
   

Création d'un formulaire "Synchronisation" avec 2 boutons [Je pars] et [J'arrive].

Le bouton [Je pars] n'est actif que si les tables "_OFFLINE" sont vides. Il nécessite d'être en ligne. L'utilisateur choisit les enregistrements avec lesquels il veut partir : ils sont alors recopiés dans les tables "_COPY" et se voient attribués d'un flag qui les rend "en lecture seule" pour les autres utilisateurs connectés.

Sur le terrain chaque enregistrement modifié ou créé est mis dans les tables "_OFFLINE" (avec un flag "nouveau" ou "modif") et dans les tables "_COPY"

Le bouton [J'arrive] est actif s'il y a des enregistrements dans les tables "_OFFLINE". Il faut être connecté au réseau. Tous les enregistrements de ces tables sont mis à jour/créés dans les tables liées. Les tables "_OFFLINE" et "_COPY" sont ensuite vidées.