Discussion :

[b_reda31]

Bonjour,
j'ai un petit problème, je vous explique le contexte en simplifiant un peu :

J'ai deux fichiers HFSQL :
- Produits_Serveur : de type HFSQL C/S stocké sur un serveur
- Produits_Local : de type HFSQL Classique stocké sur un poste client qui accède aussi à la base (Produits_CS) via internet.

Les deux fichiers ont strictement la même structure et devraient aussi avoir le même contenu.
Initialement, le contenu du fichier Produits_Local est rempli par Produits_Serveur, ce qui les rend identique ... au départ...

Ensuite, il arrive que l'administrateur modifie le fichier Produits_CS, en ajoutant de nouveaux produits, ou en modifiant un produit, ou en supprimant un produit.

Je voudrais ainsi "synchroniser" le fichier Produit_Local avec Produit_CS depuis le poste client à la demande.

Pour cela, j'ai pensé à 2 solutions mais qui ne sont pas tout à fait optimale/correcte :

Solutions 1 : Pas optimal
Au niveau du poste client, je récupère le numéro de version de Produit_CS à l'aide de HVersion, si celui-ci est supérieur à la dernière version connue (stockée en local),
je synchronise les fichiers de manière "naive" : je vide le fichier Produit_Local et je le rempli par Produit_CS (requête de sélection sur l'ensemble du fichier Produit_CS).
Cette technique a le mérite de bien marcher, seulement elle n'est pas très optimale. Ceci est principalement dû au fait de la lourdeur de la requête (SELECT * FROM Produit_CS)
Au lieu de récupérer seulement les ligne à modifier, là je récupère toout le contenu du fichier. Ce dernier peut contenir des milliers de lignes, et comme le traitement transite par internet, j'obtient des latence assez importantes !

Je souhaite donc trouver un mécanisme qui me permette de récuperer seulement les tuples qui ont été modifiés (depuis la dernière synchronisation) et non tous les tuples de manière naïve
Pour cela j'ai commencé à mettre en place la Solution 2 : (Incomplète)
- J'ai ajouté aux deux fichiers une nouvelle rubrique "NumVersion".
- J'ai mis en place au niveau de Produit_CS, un trigger qui incrémente le NumVersion à chaque modification d'une ligne par l'administrateur.
- Ainsi, il devient possible de récupérer depuis le poste client les tuples ayant été modifiés (après dernière synchronisation), et ce par une simple requête sql de la forme :

Code :

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

1
2
3
 
//Récupération des tuples dont le numversion serveur est supérieur au numversion local
SELECT * FROM Produit_CS, Produit_Local WHERE Produit_CS.ID=Produit_Local.Id AND Produit_CS.NumVersion>Produit_Local.NumVersion;

Comme vous l'avez certainement remarqué, bien que cette méthode est plus optimale que la première, seulement on ne peut récupérer à l'aide de cette requête les nouveaux produits ou les produits à supprimer !
Si l'admin ajoute de nouveaux produits, ces derniers ne seront pas récupéré par cette requete.
Il en est de même pour la suppression... Quoi qu'ici je peux considérer une suppression comme une modification et ce par la mise à 1 d'une rubrique "Supprimé", afin d'éviter toute suppresion physique,
mais pour l'ajout, je n'arrive pas à formuler cela en SQL : "Récupérer de Produit_CS, les tuple dont le Id n'existe pas en Produit_Local"

Des suggestions ?

PS. Je souhaite éviter de passer par le serveur de réplication windev.

[tbc92]

Pour recenser les product_id qui existent dans Produit_CS mais pas dans produit_Local, tu peux faire cette requête :

Code sql :

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

1
2
3
select product_id from produit_CS 
minus
select product_id from produit_local

Ou si tu veux récupérer via cette requete les product_id, mais aussi le contenu de l'enregistrement :

Code sql :

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

1
2
select * from produit_CS p1 
where not exists (select * from produit_local p2 where p2.product_id = p1.product_id)

Et tu peux aussi gérer les suppressions par une requête similaire, en inversant les rôles de produit_CS et produit_local.

[Voroltinquo]

Fait aussi attention lors des ajouts dans ta table locale. En fonction de l'ordre des traitements, tu risques d'avoir des problèmes d'ID, surtout lors du premier remplissage de ta table.
Les options hFIxedIdAuto ou hForcedIDAuto seront bien utiles.

[b_reda31]

Ou si tu veux récupérer via cette requete les product_id, mais aussi le contenu de l'enregistrement :

Code :

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

1
2
select * from produit_CS p1 
where not exists (select * from produit_local p2 where p2.product_id = p1.product_id)

Super! merci cela marche très bien, j'ai fusionné votre requête à la mienne à l'aide de la clause UNION, ce qui permet de récupérer en une seule requête les nouveaux enregistrements ainsi que ceux modifiés depuis dernière synchronisation.
Merci encore!!

Fait aussi attention lors des ajouts dans ta table locale. En fonction de l'ordre des traitements, tu risques d'avoir des problèmes d'ID, surtout lors du premier remplissage de ta table.
Les options hFIxedIdAuto ou hForcedIDAuto seront bien utiles.

j'imagine que vous parlez ici des IdAutomatique ? il est vrai que cela peut poser problème, notamment lors du remplissage, il possible d'avoir les mêmes produits avec des ID différents...
Dans mon cas, je n'utilise pas de IDAuto, je gère la génération de l'Id à la main. les ID sont des rubriques clé primaire de type entier. Donc je pense que le problème ne se pose pas, à moins que je vous ai mal compris

[Voroltinquo]

Je n'aime pas répondre à des sujet clos, mais en effet, je parlais des Id Auto et donc le pb ne se pose pas

[periplo94]

bonjour b_reda31, je suis un débutant de windev, puisque je dois mettre à jour une table identique selon votre exemple, je voulais vous demander s'il est possible d'avoir le code windev complet de vos deux requêtes de mise à jour pour Solutions1 et Solution2 merci et salutations
francesco

Super! merci cela marche très bien, j'ai fusionné votre requête à la mienne à l'aide de la clause UNION, ce qui permet de récupérer en une seule requête les nouveaux enregistrements ainsi que ceux modifiés depuis dernière synchronisation.
Merci encore!!




j'imagine que vous parlez ici des IdAutomatique ? il est vrai que cela peut poser problème, notamment lors du remplissage, il possible d'avoir les mêmes produits avec des ID différents...
Dans mon cas, je n'utilise pas de IDAuto, je gère la génération de l'Id à la main. les ID sont des rubriques clé primaire de type entier. Donc je pense que le problème ne se pose pas, à moins que je vous ai mal compris