Discussion :

[GCASPIC10]

Bonsoir,

J'ai un doute sur l'utilisation de HChangeRep et autres... ca n'est sans doute pas la meilleur solution

J'ai développé une application "ESSAI" qui se trouve sur mon dossier personnel de développement :
- sous D:\...\ESSAI se trouve mes fenêtres etc...
- et sous D\...\ESSAI\Exe (répertoire par défaut) se trouvent les fichiers HFSQL associés


Je créé un exécutable sur ma clé USB de manière à ce quelle soit autonome :
- sous E:\PROG\ESSAI... se trouve l'exécutable et sans doute ses bibliothèques etc...
- sous E:\DATA\ESSAI... se trouve mes fichiers (vierge de contenu à la création)

Pour faire simple, j'ai copier/coller de mes fichiers initiaux (données déjà saisies pendant le développement) à la place des fichiers vierges sur la clé. A l'exécution le résultat de l'EXE et celui de mon développement son bien identique.

Maintenant, pour éviter d'enregistrer des données ailleurs que sur ma clé USB (EXE), je voudrais inhiber les fichiers de mon répertoire de développement et utiliser ceux sur la clé USB.

Le HChangeRep permet t'il simplement de faire çà !

L'inconvénient est que mon analyse et donc la structure des fichiers existe et sont référencés sur mon répertoire de développement.
Il semblerait qu'il me faille redéfinir le chemin de chacun des fichiers dans l'analyse (sans en oublier) afin de régler çà !
De ce fait je pourrait même supprimer les fichiers de mon répertoire de développement et me servir obligatoirement de la clé USB (en EXE autonome mais aussi lors de mon développement évolutif)

Mon raisonnement tiens t'il ?
Y a t'il une solution simple pour ne pas redéfinir mes chemins dans l'analyse un par un ?

A noter que cette application EXE sur clé USB devra être utilisable en multiposte (répertoire partagé) et sur différents OS Microsoft.

[dsr57]

Bonjour ,

La fonction HchangeRep permet de modifier le chemin d'accès à un fichier de données. Si le premier pqrqmètres est égal à "*", le changement de répertoire est effectué pour l'ensemble des fichiers de l'analyse.

Bon dev

[GCASPIC10]

Merci DSR57,

Je savais cela, mais ma question porte plutôt sur :

Est il préférable de faire un changement de répertoire avec Changerep(*) ou plutôt lier finalement mes fichiers copier sur ma clé à mon EXE (USB) et à mon répertoire de développement (DD).
Dans ce cas, je supprimerais les fichiers du DD après les avoir copier et fait le lien dans l'analyse à l'USB (de ce fait, les fichiers référents seraient uniquement sur la clé).

Pour résumer n'avoir plus qu'une seule source de fichiers et éviter ainsi d'enregistrer sur la mauvaise cible (USB ou DD) en fonction de l'utilisation de l'EXE ou en mode développement.

D'autre part, lors de la sauvegarde journalière automatique de mes développements, n'y a t'il pas le risque de ne pas enregistrer les nouvelles données stockées à l'avenir sur l'USB.
Ca je pourrais le vérifier en faisant une sauvegarde non compressée...

[GCASPIC10]

Pas de réponse ...

Bien, pour le fonctionnement de L'application ESSAI.EXE installé sur ma clé et avec une copie des datas sur les répertoires cités précédemment, l'application fonctionne correctement à partir de l'USB.

La suite des problèmes est à l'exécution de cette application à partir d'un 2ème PC en réseau, car je ne peux pas inclure mon répertoire sur la clé USB en tant que fichier partagé sur Windows 7. En effet, on ne peut mettre une clé USB dans la bibliothèque publique afin de la partager en réseau (refusé)...

Comment faire pour autoriser un autre PC2 (XP ou pas) à lire une clé USB sur le PC1 (Windows 7) ?

[dsr57]

Bonjour ,

Je pense qu'il ne faut pas mélanger les données de production avec les données de développements. C'est à dire, cela doit être deux bases différentes, pour éviter les erreurs de programmation.
Je mettrais en place de bases de données, j'alimenterais régulièrement la base de tests par les données de production.

Pour le point des données sur la clé USB, si tu dois mettre en place une application sur plusieurs postes, il faut procéder autrement.

• choisir entre une installation C/S ou classic ;
• mettre en place un serveur de données (cle peut être un poste utilisateur, mais attention au performance) ;
• lors de l'installation de l'exécutable, sélectionner le type d'instqllqtion et le chemin des données.

Voilà, en espérant avoir apporter des pistes.

Bon dev

[frenchsting]

Comment faire pour autoriser un autre PC2 (XP ou pas) à lire une clé USB sur le PC1 (Windows 7) ?

Je ne sais pas quelle est la taille de ton projet / bdd associée mais j'ai quand même un doute : si tu peux mettre ton projet sur une clé usb, autant ne rien mettre et laisser les fichiers HF dans le dossier de ton exe, ce qui t'évite d'utiliser les hchangerep en prod.

Le hchnagerep pourra être utilisé en mode test (si enmodetest() alors hchangerep("*",xxxx).

Tu veux que ton projet soit utilisable sur un pc distant. Créer un partage de dossier devrait suffire.. et attaquer le pc distant avec un chemin unc (\\pcdistant\dossierpartagé). Cela t'évitera la déconvenue d'un changement de lettre dudit lecteur. De plus, le pc qui ne connecte "n'est pas obligé" de voir le chemin complet du pc distant.

Là ou ça me chagrine vraiment, c'est que la clé usb est "mobile" et peut être débranchée à tout moment.

[GCASPIC10]

Merci DSR57,

Bien d'accord sur l'importance d'éviter les doublons de fichiers data.

Par contre et on est bien d'accord, lorsque tu fais évoluer ton programme test et par conséquent aussi tes fichiers test (colonnes en plus, lien en plus etc...), ton exécutable après recompilation et installation sur la clé n'a plus les bons fichiers data sur ta clé.
Il te faut donc recopier ces fichiers data (format etc...) sur le répertoire de ta clé et là malheureusement tu perds les datas rajoutées au fur et à mesure de l'utilisation de l'exe de ta clé.

Je pense que la solution la plus appropriée (puisqu'il y a intégration de données au fur et à mesure du développement) est de cibler les fichiers de la clé dans mon analyse avec le chemin de la clé USB... comme çà, je modifie la structure et intègre les data dans mon exe ainsi que pendant mes développement.
Bien sûr, il me faudra sauvegarder régulièrement mes fichiers data de la clé pour éviter les crashs intempestifs et la perte de ces datas.

Tu en penses quoi ?

La clé n'a pas pour objectif de servir à l'installation sur d'autres postes PC, mais simplement de support lors de déplacements et d'utilisation de l'EXE depuis n'importe quel PC à partir de la clé USB (lettrage de la clé USB identique bien sûr)

Bonjour ,

Je pense qu'il ne faut pas mélanger les données de production avec les données de développements. C'est à dire, cela doit être deux bases différentes, pour éviter les erreurs de programmation.
Je mettrais en place de bases de données, j'alimenterais régulièrement la base de tests par les données de production.

Pour le point des données sur la clé USB, si tu dois mettre en place une application sur plusieurs postes, il faut procéder autrement.

• choisir entre une installation C/S ou classic ;
• mettre en place un serveur de données (cle peut être un poste utilisateur, mais attention au performance) ;
• lors de l'installation de l'exécutable, sélectionner le type d'instqllqtion et le chemin des données.

Voilà, en espérant avoir apporter des pistes.

Bon dev

[frenchsting]

Tes données de clé ne sont pas perdues si tu modifies ton analyse. Il faut les passer par wdmodfic.

Concernant ton utilisation (que je comprends mieux), regarde du coté de la réplication (hreplicaxxx et autres).

[GCASPIC10]

merci frenchsting

Pour l'instant c'est un petit projet qui devrait être partagé par 2 ou 3 utilisateurs en même temps sans aucune contrainte d'obligation et de disponibilité pour les 2/3 des utilisateurs.

L'avantage de la clé est sa petitesse, sa portabilité et sa facilité de mise en œuvre avec cependant une lenteur à l'exécution un peu marquée à l'initialisation du programme
Une variable d'utilisation à lire pour charger la lettre du lecteur USB serait une solution éventuelle pour faire rapide (par exemple un fichier TXT avec 1 caractère et par défaut le I).

Sinon, sa capacité ne pose aucun problème car les données seront plutôt restreintes en volume mais par contre très confidentielles.

L'inconvénient du HChangerep comme je l'ai dis précédemment me conserverait 2 répertoires de datas (permutable à souhait) mais je voudrais éviter car risque de doublon ou de différences d'enregistrements entre les 2 cibles DEV et EXE (hormis la sauvegarde bien sur).

Dis moi ce que tu en penses !

Je ne sais pas quelle est la taille de ton projet / bdd associée mais j'ai quand même un doute : si tu peux mettre ton projet sur une clé usb, autant ne rien mettre et laisser les fichiers HF dans le dossier de ton exe, ce qui t'évite d'utiliser les hchangerep en prod.

Le hchnagerep pourra être utilisé en mode test (si enmodetest() alors hchangerep("*",xxxx).

Tu veux que ton projet soit utilisable sur un pc distant. Créer un partage de dossier devrait suffire.. et attaquer le pc distant avec un chemin unc (\\pcdistant\dossierpartagé). Cela t'évitera la déconvenue d'un changement de lettre dudit lecteur. De plus, le pc qui ne connecte "n'est pas obligé" de voir le chemin complet du pc distant.

Là ou ça me chagrine vraiment, c'est que la clé usb est "mobile" et peut être débranchée à tout moment.

[Yusep]

Bonsoir.
Je pense que c'est une idée dangereuse que donner tant de confiance à des supports amovibles pour enregistrer des données sensibles.
Faux contacts, problêmes électriques, etc...
Cette année j'ai vu 3 ou 4 clients pleurer après la perte irremediable de leurs fichiers.

[frenchsting]

Une idée pour éviter les doublons, est de créer un dossier par utilisateur. Lorsque l'utilisateur travaille sur sa clé, il pointe sur le dossier "Dupont". Lorsqu'il travaille en "normal", il pointe sur la base complète. De là, il peut réintégrer les nouvelles données issues de sa clé usb.

A réfléchir suivant ton projet, bien sûr.

[GCASPIC10]

Bonjour et merci à vous,

Vous n'aviez pas toutes les données en main... je comprends votre raisonnement de prudence.

Il s'agit d'une base connaissance partagée entre plusieurs mais qui ne subira que très peu de modification dans le temps (une fois créée et renseignée).

Quelques corrections, quelques ajouts d'enregistrements personnels ou collectifs ponctuellement et dont l'utilisateur "auteur" gardera la maîtrise parfaite.
La notion de partage sera ou non autorisée par l'auteur suivant le thème.

Sinon, je viens de modifier dans la description de mon programme DEV, le chemin de mes fichiers data maintenant ciblés vers la clé USB. J'ai supprimé (sauvegarde faite au préalable) les data du DD.
Cela fonctionne a merveille (lecture/écriture avec mon EXE et mon DEV).

Bref, une sauvegarde régulière des fichiers data USB pourra éviter une perte conséquente et pourra être proposée d'ailleurs par le programme dès qu'une modification importante sera effectuée.

Sinon, pour poursuivre et toujours dans l'esprit clé USB :

1°) J'ai procédé à des modifications fonctionnelles sur mon DEV et voudrais maintenant automatiser les mises à jour vers l'EXE (pour essai car là je n'ai qu'une seule cible qui est la clé USB) dans le principe des mises à jour WinDev via le net... Si vous avez des infos !

2°) J'ai toujours pas réussit à faire reconnaître la clé USB de mon PC1 (Windows 7), auprès d'un PC2 en réseau interne (Windows XP). Problème d'UAC semble t'il ? Et là c'est pas top...

[GCASPIC10]

Oui, l'idée est intéressante, mais le programme implique une bonne maitrise de la réintégration des données des multiples fichiers data sollicités et en lien entre eux.
S'il ne s'agissait que d'un lot de données (même très faible en enregistrement) mais dans un seul fichier, j'aurais cherché en ce sens... Et puis on connait bien le problème, il ne faudrait pas pouvoir apporter de modification sur l'existant chargé en mode autonome car si 2 personnes modifient le même enregistrement stocké dans sa base autonome, qui aurait priorité sur l'autre (écrasement mutuelle).

Une idée pour éviter les doublons, est de créer un dossier par utilisateur. Lorsque l'utilisateur travaille sur sa clé, il pointe sur le dossier "Dupont". Lorsqu'il travaille en "normal", il pointe sur la base complète. De là, il peut réintégrer les nouvelles données issues de sa clé usb.

A réfléchir suivant ton projet, bien sûr.

[frenchsting]

Pour ton pb windows, regarde du côté du centre réseau et partage / modifier les paramètres avancés (connexion sans mot de passe,...).

Je reviens également sur le pb de sécurité physique de la clé. Si la volumétrie de tes fichiers est importante, outre la lenteur, le risque de perte données est important. (Point également soulevé par Yusep).

[GCASPIC10]

Windows 7... je vais regarder çà de plus près, sinon volume de data, comme je le disais précédemment, elles seront on ne peut plus faible en volume.

Pour te dire, là je viens de regarder le volume utilisé qui est de l'ordre de 512ko. Bien sûr, çà va évoluer en DEV et contenu mais globalement, je dirais que le répertoire data pourrait atteindre au maximum quelque 10Mo.

Après et suivant la lenteur, d'autres solutions pourraient être envisagées.
Pour la sauvegarde, je m'en suis expliqué sur le post DSR57

Pour ton pb windows, regarde du côté du centre réseau et partage / modifier les paramètres avancés (connexion sans mot de passe,...).

Je reviens également sur le pb de sécurité physique de la clé. Si la volumétrie de tes fichiers est importante, outre la lenteur, le risque de perte données est important. (Point également soulevé par Yusep).

[Ben13d10]

Bonjour,

Je vais peut être dire une bétise mais as tu pensé à la réplication ?

Ta base de connaissance sur clef USB est volatile, dynamique et le support USB pas fiable.

Une base MAITRE que tu utilise en Production ...

@+

[GCASPIC10]

Merci Ben,

Pour une base plus conséquente et avec des électrons libres comme utilisateurs, c'est envisageable mais ce n'est pas le cas pour cette appli.
De plus il faudrait parfaitement gérer cette opération et admettre qu'il y ait potentiellement des interactions de data avec plusieurs utilisateurs.

Le com1 qui va chez ses clients1 boulangers (par exemple) va enregistrer des modifs propres à ses clients1.
Pareils pour le com2 etc...

Dans ce cas, la réplication ne souffre d'aucun problème de chevauchement de data car elles sont totalement exclusives à chaque com...

Ben là, pour moi ca ne sera pas le cas.. chacune des modifs pourrait être faite par l'un ou l'autre des utilisateurs. Donc la solution ultime est de verrouiller l'enregistrement en cours de modif.