Discussion :

[bobby5169]

Bonjour à tous et à toutes.

Je suis actuellement en cours de développement d'un outil pour gérer des collectes de besoin à moyen terme.

Il s'agit d'un base multi utilisateurs (5 utilisateurs max en même temps).

La base est actuellement fractionnée en BDD et en formulaires et requêtes (base frontale et dorsale).

La base dorsale, est sur un dossier réseau (disponible hors connexion via l'outils W7).

4 utilisateurs peuvent travailler hors connexion.

Je rencontre donc un problème lors de la création d'enregistrement hors connexion. Les enregistrements sont dans les bases frontales des utilisateurs mais n'apparaissent pas dans la dorsale.

Je pensais que lors de la synchronisation des fichiers aurait permis la mise à jour des enregistrements.

J'ai vu des infos sur la réplication mais qui n'est plus disponible sur Access 2010. Je ne peux pas utiliser une base 2000 car j'utilise l'historisation des champs mémo, et choix multiples dans certains champs.

Comment est ce que je peux synchroniser les données?

Comment éviter les conflits sur les Id des enregistrements?

En vous remerciant par avance.

[loufab]

Bonjour,

Le travail hors connexion n'est pas la tasse de thé de Jet. Parce que c'est une base de données fichier. Les outils de synchro de fichier ne pouvant(sachant) pas lire la structure il leur est impossible de la faire au niveau de l'enregistrement. Ainsi le dernier fichier écrase le précédent purement et simplement.

Pour travailler hors connexion on peut travailler par plage.
Avec une plage totale de -2,147,483,648 à 2 147 483 647, 4 utilisateurs ne devraient pas se gêner.

On peut s'appuyer soit sur NumeroAuto :
- avec le réglage Aléatoire (avec un peu de chance tu peux ne pas tomber sur un doublon)
- avec l'initialisation de plage, chaque utilisateur débute à un N° particulier. (via requête INSERT et compactage)

Sinon on s'appuie sur son propre système (champ LONG) ce qui ne change pas grand chose sauf qu'on s'oblige à gérer l'incrément mais qu'on assoupli la méthode d'initialisation des plages. (pas de compactage)

Cordialement,

[bobby5169]

Bonjour loufab et merci pour ta première réponse.
Je n'ai pas le niveau de certains ici et je ne comprends pas ta réponse.

Il faut que j'utilise un champs avec une valeur unique voire aléatoire?

Si je créé un champs date heure minute seconde (format numérique standard), ça me permettrai donc de comparer si les N° des enregistrement existent et si ils existent, je créé un nouvel enregistrement?

je sais pas si je suis très clair, je réfléchi en même temps que j'écris

[loufab]

Pourquoi créer une étape supplémentaire ?

Soit le champ NumeroAuto est réglé sur Aléatoire, et dans ce cas très peu de chance (vu la plage de N° possible) d'avoir 2 fois le même.

Soit chaque utilisateur a sa propre plage :
Sur cette plage de N° possible : -2,147,483,648 à 2 147 483 647 soit plus de 4 milliards d'enregistrements.
-1 à -1 500 000 = utilisateur 1
- 1 500 001 à -3 000 000 = utilisateur 2
...
1 à 1 500 000 = utilisateur x
1 500 001 à 3 000 000 = utilisateur y

Soit 1 million 500 milles records par utilisateur, en sachant que c'est un "petit" exemple.

Dans ce cas il n'y aura aucune chance qu'il y ai 2 N° identique.

[bobby5169]

Merci Loufab pour ta réponse.

Par contre il faut une intervention "humaine" pour insérer les nouveaux enregistrements et mettre à jour ceux existants?

Comment je peux faire pour déterminer les nouveaux de ceux qui sont déjà existants?


Désolé de toutes ces questions de débutants mais je débute dans le vaste monde d'Access

[loufab]

Pour connaitre les nouveaux il faut procéder par comparaison, avec des requêtes de non-correspondance. On peut en créer via l'assistant du générateur de requête. Sinon c'est une technique assez rependue il y a donc plein d'exemples ici et ailleurs sur le net.

En gros tu compares les ID de la table source avec ceux de la table destination et tu ne traites que ceux qui n'existe pas dans la seconde comme source d'insertion.

[bobby5169]

Merci de ta réponse.
J'ai traité un peu différemment mais l'idée est à peu près là.
J'ai un champs qui prend la valeur "ajout" si on ajoute un enregistrement, et "modif" si on modifie un enregistrement.

Jusque là OK.

Via un bouton je créé un record set:

Code :

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

 SELECT * FROM [tblProjet] WHERE EtatHorsLigne is not null

Ensuite je parcours mon recordset est je fais un requete ajout ou uddate en fonction de la valeur.

Par contre lorsque je fais des tests hors connexion.

Les ajouts et les modifs ne sont ensuite pas répercutés dans la base dorsale.

C'est comme si les enregistrement étaient créés ou modifiés dans une copie de la base dorsale.
L'utilisateur qui a créé cet enregistrement le voit bien dans ses différents formulaires, mais lorsque moi j'ouvre la base dorsale je ne vois pas cet enregistrement.

Si quelqu'un a un explication aide à fournir, je suis preneur.

[loufab]

Si tu les vois mais pas les autres (ou vice-versa) c'est que vous n'êtes pas sur la bonne base ou que les filtres (si requête) ne sont pas les mêmes.

[bobby5169]

Pourtant je n'ai qu'une dorsale et une frontale.

Les utilisateurs rendent dispo hors connexion les frontales et dorsales.

Je pense que je vais créer une table temporaire dans la frontale et ensuite renvoyer les données vers la dorsale lors de la reconnexion au réseau.

Sachant que les controles de mon formulaire sont directement issus de ma table, faut il que je recréé un formulaire pour envoyer les enregistrements et modifs vers la nouvelle table ou existe t'il un moyen facile de changer la destination d'enregistrement?

[micniv]

Bonjour,
Je viens mettre les pieds dans le plat en faisant quelques suggestions.

... Comment éviter les conflits sur les Id des enregistrements?...

Et c'est bien là le problème : la gestion des nouveaux enregistrements.
Si j'avais à réaliser une synchronisation pour une nouvelle appli, je m'interdirais les clés primaires auto-incrémentées, seulement des clés fonctionnelles (sur un ou plusieurs champs) avec des codes saisis manuellement. Car la problématique la plus embêtante est que ces clés primaires sont souvent utilisées comme clés étrangères dans les autres tables et les conflits deviennent vite inextricables.
Le problème de conflit en cas de création de lignes serait en principe résolu.
La détection des nouveaux records se fait alors comme l'a décrit Loufab plus haut (@08h49).
Il faut aussi tenir compte de la dépendance des tables pour assurer un bon ordre des opérations.

CDLT