Discussion :

[xavier.ninane]

Bonjour,

Je viens de découvrir, à mon grand désarroi, la table "integrity.fic" sur le C/S de Windev (en fait, je veux migrer mon serveur de 19 vers 20, et j'ai fait une sauvegarde. Histoire de voir ce qu'il y'a dans cette sauvegarde, j'ai ouvert ce .fic)

Et là, j'ai des frissons d'horreur. J'ose espérer que la mélasse que je constate n'est que le digne reflet de mon amateurisme !

Je développe une application de type comptable : je l'ai organisée en utilisant la capacité de créer des répertoires sur le serveur (HChangeRep). A la racine, je place des informations partagées par toutes les entités (exemple type : "Civilite").
Ensuite je place dans chaque répertoire les informations individuelles de chacune des entités.

Windev répercute correctement mes règles d'intégrité en créant autant de règles qu'il existe d'entité : je ne peux supprimer une civilité si celle-ci est utilisée dans une des entités. A chaque lien d'intégrité entre civilité (racines) et entités (multiples), Windev crée une ligne dans cette table "integrity.fic")
Voyez ce print-screen :

Civilite (en racine) est en lien d'intégrité avec plusieurs fichiers, chacun dans ses sous-répertoires. Ça roule.



Et puis je découvre des liens d'intégrité à la j'en rien à voir, sorti de je ne sais où.



Des entités censées être indépendantes et étanches sont mises en relation ! ( sous rep 1\... mis en relation avec sous rep 7\ ,etc.)

Alors, là où j'admets que j'ai peut-être bien (lourdement) fauté, c'est que je développe l'appli en classique, et que je bascule en C/S par les fonctions H***Connexion
Deuxième erreur probable : je travaille en développement sur une entité : je crée des rubriques, en efface, crée des clefs composées, bref, je triture le fichier jusqu'à tant qu'il corresponde au comportement souhaité.
Ce fichier, qu'on pourrait considérer comme un dictionnaire, une fois finalisé est placé par "copié-collé" dans chacune des entités, toujours en local.

Ensuite, je fais un import de ce dictionnaire de la BD locale via le centre de contrôle HFSQL vers HFSQL C/S.

Ok, tout ça peut paraître peu orthodoxe, mais accordez-moi que je développe en TPE (nous sommes deux), et que je souhaitais seulement pouvoir déployer sur le serveur les fichiers dictionnaires mis à jour.

Il semblerait que je déploie avec ces fichiers "copié-collé" des dépendances intrinsèques...

Est-ce que vous confirmez ?

Comment puis-je me délier de ces dépendances ?

La doc de PCSoft est très absente sur tout ce qui concerne les comportements et règles en vigueur.

Comment travailler sur un fichier en relation, le tester, l'éprouver, et puis le déployer dénué des relations de tests utilisées ?
Compte-tenu que je ne veux pas basculer mon analyse en client-serveur.

D'avance merci.

X.

[R&B]

Bonjour Xavier.

Je pense comprendre que votre fonctionnement comporte quelques failles.
Ecriture de données locales, puis déport sur le CS... par le centre de contrôle.
Puis analyse des fichiers internes du CS.

Prennez votre C/S comme une base partagée (répétition je sais).
Utilisez des données locales comme temporaires
jusque là pas de problème.

En revanche, les données locales et CS ne peuvent être en relation d'intégrité, sauf si vous reproduisez localement les même condition que votre serveur (chemin, nom physique etc.) pour les données auxquelles vous liez les nouvelles informations.
Je vous recommande plutot de débrancher localement ces clauses d'intégrité, de les vérifier par programmation et de programmer l'écriture finale (copie des enregistrement loaux) dans le C/S avec cette fois l'intégrité active et qui plus est au sein de transaction. Ainsi, vous conservez la saisie locale, et vous sécurisez le report sur le serveur.

[xavier.ninane]

Je précise que bien entendu je ne souhaite pas mettre en relation des données locales et des données serveur - je suis un néophyte, mais tout de même...
La mélasse constatée était intrinsèque au serveur.

Il s'avère que lors de la synchronisation de l'analyse et des données serveur, le processus de synchronisation propose toutes les liaisons envisageables, en sorte que toutes les combinaisons entre tous les sous-répertoires sont proposées.
Je rappelle : j'utilise le HChangeRep sur le serveur - qui fonctionne très bien, ceci dit.

Donc, lors du processus de synchronisation, il faut veiller à ne pas accepter les propositions de liaisons qui sont hors de contexte. Il faut trier et mettre en contexte.
(Et j'avais "bêtement" accepté toutes les mises à jour...)

Pour le surplus, je ne me suis pas interrogé sur la manière dont ce "tri" pourrait ou serait automatisé.
J'y veille manuellement lors de ma synchro entre analyse et serveur. Mon niveau de déploiement me permet de garder un non-automatisme et le contrôle de mes intégrités référentielles.

Je mets en résolu dans la mesure où la mélasse initiale est corrigée.