PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV 2025 → [WD17] Gestion de la structure de la Base (gestion des GUID)
[WD17] Gestion de la structure de la Base (gestion des GUID)
Iniciado por roland, 04,mar. 2012 14:26 - 8 respuestas
Miembro registrado
223 mensajes
Publicado el 04,marzo 2012 - 14:26
Bonjour à tous.

Parmi l’une de nouveauté qui me semble les + intéressantes de WD17 figure la fonction HModifieStructure.

Elle me parait intéressante, car l’installateur ne sais pas forcement où est la base de donnée utilisée, et il ne sait pas gérer plusieurs bases, par exemple quand on laisse le choix à l’utilisateur de sélectionner une base différente selon son traitement.

Il est donc vraiment intéressant de maitriser par le programme lui-même, la gestion de l’évolution de la structure, plutôt que de bloquer sur une erreur de cohérence.

Toutefois la documentation est un peu avare d’information quant au fonctionnement de HModifieStructure.

J’ai donc envisagé de comparer les « GUID Analyse » de chaque table avec le GUID de la base pour détecter s’il fallait lancer HModifieStructure pour chacune des tables de la base sélectionnée.

Mais là je bloque.

En effet, si HListeFichier fonctionne dans tous les cas (heureusement),
un simple MaTable..GUIDAnalyse nécessite déjà que MaTable soit en cohérence avec l’analyse !!!

Ceci est très gênant et retire donc tout intérêt à l’accès à cette propriété…

Donc WD renvoi allégrement l’erreur 72109 (ou 70016 ?) « La description du fichier logique <MaTable> stockée dans l'analyse est différente de celle stockée dans le fichier physique <D:\PcSoft\Mes projets\Test\Exe\MaTable>. Impossible d'accéder au fichier. »

Constat désolant : impossible de comparer la version réelle des fichiers par rapport à celle de l’analyse, et donc impossible de gérer à précision l’évolution de la structure, à ma « sauce », dommage !

Moi qui avait prévu de tester ensuite dans ma routine MaTable..type pour n’appliquer HModifieStructure qu’aux tables de type hFichierClientServeur ou hFichierNormal pour ne pas toucher mes tables externes MySql concernant des applications tierces (OsCommerce par exemple)…

Je suis donc contraint d’utiliser systématiquement à chaque lancement de l’application une boucle lançant HModifieStructure pour chacune des tables locales et de mettre « en dur » dans un tableau les tables des bases « externes » à ne surtout pas toucher, etc...

Il en résulte donc de nombreuses questions sur le fonctionnement de HModifieStructure :

- S’il n’y a rien à faire, son lancement systématique ne pénalisera-t-il pas trop le temps d’ouverture (cas le + fréquent) ?

- Si l’utilisateur installe une ancienne version du logiciel par-dessus une version plus récente, HModifieStructure va-t-elle revenir à une structure de la Base + ancienne, avec le risque de perdre des informations ???

- Pus accessoirement, apparemment HModifieStructure prévoit de gérer une fenêtre de Message, mais je ne suis pas arrivé à utiliser l’option « fenêtre ».

Si quelqu’un a un avis où des infos, je suis preneur et je pense que cela en intéressera + d’un.

Par contre (pour info concernant d’autres posts), je n’ai pas de problèmes avec HModifieStructure qui fonctionne en HF mais aussi en HF/CS sur serveur distant (à condition bien sur de l’exécuter de suite après HChangeConnexion, et avant HOuvre, de + je teste si la connexion a effetivement changée bien sur).

Bon dev à tous.







--
Roland
Miembro registrado
558 mensajes
Publicado el 05,marzo 2012 - 09:48
Bonjour,
Tu peux mettre une procedure en place dans le menu paramètre pour permettre de lancer la procédure ou mieux, gérer cela dans les érreurs en cas d'erreur, traiter ce type d'erreur et déclencher la procédure.
C'est mon avis
Publicado el 05,marzo 2012 - 11:51
Bonjour,

roland a écrit dans le message de news <1cab7e50fc11fbbbca62d0b82c811a3e@news.pcsoft> :
Constat désolant : impossible de comparer la version réelle des fichiers par rapport à celle de l’analyse, et donc impossible de gérer à précision l’évolution de la structure, à ma « sauce », dommage !
--


Depuis plusieurs années (WD10 ou WD12 je ne me rappelle plus), en HF Classic, moi j'utilise la propriété "NuméroGénération" pour vérifier que la structure des fichiers HF qui vont être utilisés par le programme correspond bien à celle attendue par la version de ce programme.

En gros, dans le code init du projet, j'ai un tableau qui est initialisé avec le numéro de génération de chacun des fichiers HF utilisés par la version en cours du programme.
Ensuite et toujours dans le code init et avant tout traitement HF sur les fichiers:
- j'ouvre tous les fichiers HF via la commande HDéclareExterne()
- je récupère via la propriété "NuméroGénération" le n° de génération dudit fichier
- je compare le n° de génération du fichier à celui attendu par le programme

Voilà, c'est tout ce qu'il y a de plus simple.
Ainsi, si à un moment donné le n° de génération ne correspond pas, je déclenche l'ouverte de ma procédure "Mise à jour".
Bien évidemment, à ce moment là, divers messages seront affichés à l'écran de façon à avertir l'utilisateur de la situation, à savoir:
- soit il tente d'ouvrir des fichiers plus anciens que ceux attendus par le programme
- soit il tente d'ouvrir des fichiers plus récents que ceux attendus par le programme

Dans tous les cas, si l'utilisateur valide la mise à jour, je lance "WDModfic.exe" de façon à ce que les fichiers HF soient modifiés de façon à ce que leur structure corresponde à celle attendue par le programme.
Voilà, comme déjà dit, c'est tout ce qu'il y a de plus simple.


Exemple:
J'ai une analyse qui contient 5 fichiers HF:
Ficmnp01
Ficmnp02
Ficmnp03
Ficmnp04
Ficmnp05

Le nombre de fichier est stocké dans une variable
NombreFichiersAnalyse est un entier=5

Ces fichiers HF sont stockés dans un dossier, dont je récupère le chemin dans la variable "LieuEmplacementHF".

Voici le tableau dans lequel je stocke le n° de génération des fichiers utilisés par la version du programme en cours:
StructureFichier est un tableau de 5 entiers
StructureFichier[1]=96
StructureFichier[2]=39
StructureFichier[3]=9
StructureFichier[4]=24
StructureFichier[5]=36


Voici un extrait de ma procédure (que j'ai simplifié pour l'exemple) et via laquelle je vérifie le n° de génération des fichiers qui vont être ouverts par le programme.

i est un entier
ChPr1 est une chaîne
FichierTest est une Source de Données
StructurepasBonne est un booléen

POUR i=1 A NombreFichiersAnalyse
ChPr1=ComplèteRep(LieuEmplacementHF)+"Ficmnp"+Droite("0"+i,2)+".FIC"

SI fFichierExiste(ChPr1)=Vrai ALORS
HDéclareExterne(ChPr1,FichierTest)

SI EnModeTest() ALORS
Trace(i," ",FichierTest..NuméroGénération, " ",StructureFichier[i] )
FIN

SI FichierTest..NuméroGénération<>StructureFichier[i] ALORS
StructurepasBonne=Vrai
HFerme(FichierTest)
HAnnuleDéclaration(FichierTest)
SORTIR
FIN

HFerme(FichierTest)
HAnnuleDéclaration(FichierTest)
FIN
FIN


SI StructurepasBonne=Vrai ALORS
// Traitement de mise à jour des fichiers HF
FIN


Voilà.
Bien évidemment, tout est fait pour que cela soit le plus simple possible, notamment quand il y a beaucoup de fichiers HF (j'ai des applications où il y a plus de 25 fichiers HF).
Ainsi et plutôt que de nommer les fichiers "Client.fic", "Article.fic", "Catalogue.fic", etc ... je nomme les fichiers de façon à ce qu'ils puissent être "traités" dans une boucle.
Miembro registrado
223 mensajes
Publicado el 05,marzo 2012 - 13:46
Bonjour Val.

En fait dans mes applications je laisse toujours le choix à l'administrateur : HF+emplacement des fichiers ou HF/CS+serveur,etc...

En tous cas c'est une bonne idée le HDeclareExterne pour ouvrir les tables sans quelles soient liées à l'analyse courante, je vais "piocher" dans ce sens.


Val a écrit dans le message de news <32cc46f65a97ebacd85d592e6ee2735e@news.pcsoft> :
Ainsi et plutôt que de nommer les fichiers "Client.fic", "Article.fic", "Catalogue.fic", etc ... je nomme les fichiers de façon à ce qu'ils puissent être "traités" dans une boucle.



Concernant les noms des tables dans ta procédure, tu pourrais utiliser une boucle et un tableau associatif des numéros de génération et donc t’affranchir de ta contrainte de nommage par exemple :

sListetables, sNomTable sont des chaînes
sListetables = HListeFichier()
POUR TOUTE CHAINE sNomTable DE sListetables SEPAREE PAR RC
SI {sNomTable,indFichier}..Type = hFichierClientServeur OU {sNomTable,indFichier}..Type = hFichierNormal ALORS
//
// traitement dans ta boucle POUR en utilisant sNomTable au lieu de "Ficmnp"+Droite("0"+i,2)
//
FIN
FIN


Je n'utilise pas cette propriété de Numéro de Génération, et je n'ai pas l'impression qu'on le retrouve dans l'analyse pour chacune des tables.
Tu est donc obligé des les coder en dur non ?
Publicado el 05,marzo 2012 - 16:14
Bonjour,

Pour ma part j'ai une erreur "Le fichier <NomFic> provient d'une analyse différente" lorsque je tente d'éxecuter HmodifieStructure(). Il devrait y avoir un mode plus permissif, qui permette de convertir un fichier vers la structure voulue sans aucune contrainte.
Publicado el 05,marzo 2012 - 21:55
Bonjour,

Je n'ai pas encore WD17, mais si vous ne voulez pas que Windev vérifie votre structure de fichier un simple appel a HVérifieStructure("Votre nom de fichier ici ou *", hSansContrôle), devrait règlé le cas. J'utilise déjà ceci dans des versions antérieures de Windev et ca fonctionne bien !

Sylvain







Kriegel Frederic wrote in news message <00eb04bbca74ff24995002672f0cfa67@news.pcsoft>:
Bonjour,

Pour ma part j'ai une erreur "Le fichier <NomFic> provient d'une analyse différente" lorsque je tente d'éxecuter HmodifieStructure(). Il devrait y avoir un mode plus permissif, qui permette de convertir un fichier vers la structure voulue sans aucune contrainte.
Publicado el 06,marzo 2012 - 12:15
Bonjour,
Merci mais j'ai déjà tenté avec le hverifiestructure qui effectivement donne pour certaines choses de bons résultats.
Là je butte sur une table article qui avait été créé sur une autre analyse puis importée dans l'analyse en court, et bien que wdmodfic soit capable de me mettre à jour ce fichier, hmodifiestructure ne le peut pas.
Publicado el 09,marzo 2012 - 17:57
Pour information, le ST m'a confirmé qu'il y avait un bug dnas la fonction hModifieStructure() qui serait bientot corrigé, qui empeche la mise à jour de la structure d'un fichier si il avait été créé sous une autre analyse.
Miembro registrado
14 mensajes
Publicado el 11,septiembre 2019 - 13:31
Vous avez trouvez une solution ? On est en WD24, et ce problème existe toujours.