Ce sujet est résolu.
| 1 | |
| Auteur | Messages |
|---|---|
| spheris | #1 Posté le 8/7/2012 à 19:25:10 |
 | Bonjour, voici mon probleme : J'ai concu un petit soft qui ecrit des données dans un fichier texte (résultats d'analyses d'un chantier) Ce petit logiciel tourne sur 2 PC de 2 techniciens. Chaque technicien réalise ses test durant la semaine. Je souhaiterai créer un fichier texte commun qui rescence l'ensemble des tests des 2 techniciens. A) comment m' y prendre pour qu'il n'y ait pas de doublon dans le fichier commun. B) Comment faire pour que les 2 techniciens aient l'intégralité des données en début de semaine. Le petit plus est que tous les fichiers sont exportés régulièrement par ftp de n'importe quel point wifi. Merci pour vos réponses. |
| Prokopy | #2 Posté le 8/7/2012 à 23:54:34 |
Kinder Pingui | Salut sheris, Il y a plusieurs points de vue possibles pour ton problème, alors je passer sur chacun d'eux : La théorie : Pour "merger" deux fichiers en un seul commun, en permettant de détecter les doublons, la meilleure solution serait je pense d'utiliser des programmes de diff qui permettent de visualiser les différences entre deux fichiers. De mémoire je connais kdiff3 qui fais bien ce genre de petites opérations, il faut voir si il existe des équivalents console pour pouvoir l'interfacer avec ton programme Gambas. La pratique : Si j'ai bien compris, chaque fichier texte comporte les mesures de deux techniciens différents. À moins que tes techniciens soient siamois, ils ne feront en aucun cas les mêmes mesures (heures, emplacements et peut-être même type de mesures différentes). Le point A est donc résolu. Pour le point B, le plus simple est sans doute de conserver les deux fichiers séparés. Ensuite, tu donnes à chaque technicien un "Identifiant" différent (par exemple Tech1 et Tech2). Ainsi, sur ton FTP tu auras un fichier par technicien, par exemple mesureTech1.txt et mesureTech2.txt. Dans ton programme, tu ajoutes ensuite deux boutons : un "Mettre à jour les mesures" et un autre "Propager les mesures". Le premier téléchargera depuis le FTP les fichiers autres que celui du technicien concerné, et le second enverra le fichier de mesures du technicien en question sur le FTP. Ainsi, tout le monde a les mesures de tout le monde. De plus, ce système peut fonctionner avec 2, 10, ou 200 techniciens. C'est aussi simple que cela.  Le point de vue du vieil aigri : Mais spheris, que fais-tu encore sous GB2 ?!   La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand ça marche mais qu'on ne sait pas pourquoi. Quand la théorie rejoint la pratique, rien ne fonctionne et on ne sait pas pourquoi. |
| GarulfoUnix | #3 Posté le 9/7/2012 à 00:15:54 |
By the way | Sinon pourquoi ne pas utiliser une simple BDD comme SQLite? Ca simplifierait grandement la problématique. |
| Prokopy | #4 Posté le 9/7/2012 à 00:32:48 |
| Kinder Pingui | SQLite, c'est bof pour synchroniser des données je trouve. Mais si t'as l'occasion d'avoir un serveur MySQL, cela serait en effet bien plus puissant (et tout aussi simple, surtout avec Gambas !). Le seul problème c'est de passer de fichiers sur FTP à un serveur de BDD. Si dit comme ça ça paraît simple, il faut dire que dans une entreprise ça peut aller du un peu dur à l'impensable (je parle en connaissance de cause). La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand ça marche mais qu'on ne sait pas pourquoi. Quand la théorie rejoint la pratique, rien ne fonctionne et on ne sait pas pourquoi. |
| GarulfoUnix | #5 Posté le 9/7/2012 à 10:08:29 |
| By the way | Je ne vois vraiment pas où est le problème. "A) comment m' y prendre pour qu'il n'y ait pas de doublon dans le fichier commun." Réponse: "Si j'ai bien compris, chaque fichier texte comporte les mesures de deux techniciens différents. À moins que tes techniciens soient siamois, ils ne feront en aucun cas les mêmes mesures (heures, emplacements et peut-être même type de mesures différentes). Le point A est donc résolu." Une simple BDD comme SQLite qui contient toutes les informations concernant les mesures et autres, dont chaque entrée indique le nom du technicien et l'affaire est dans le sac. Peu-être que je visualise la problématique d'une autre façon mais je trouve que l'idée de passer par un fichier commun auquel cas il faut effectuer une différence de fichier dessus, je trouve ça lourd. Avec une BDD (SQLite ou non d'ailleurs), permet de lister l'intégralité des infos respectives de chaque techniciens, et en une seule commande, d'avoir le listing complet des deux. En revanche je suis d'avis avec Adrien. Pourquoi rester en GB2? |
| Prokopy | #6 Posté le 9/7/2012 à 13:29:39 |
| Kinder Pingui | Il est certain qu'utiliser une BDD serait nettement plus puissant, plus simple et plus pratique que de faire joujou avec des fichiers par FTP. Le souci avec SQLite réside dans la synchronisation : SQLite écrit ses données dans un seul fichier. Si tout le monde travaille sur un même PC (et sur une même BDD), alors SQLite fera parfaitement l'affaire. Mais pour synchroniser deux fichiers SQLite entre eux, tu risques de t'en voir, ça reviendrait à faire un diff de fichier textes (peut-être même en pire). D'où mon idée d'utiliser MySQL : un serveur contenant une BDD unique, accessible de partout (pour garder l'esprit du FTP), et pouvant contenir simplement toutes sortes de mesures. On pourra aussi conserver le FTP à côté pour des photos de chantier par exemple. Après, installer un serveur MySQL (ou n'importe quoi d'autre d'ailleurs) ne sera peut-être pas simple dans tous les cas en entreprise. Bon après je ne connais pas l'environnement de travail de spheris. Si tout le monde est un tant soit peu ouvert au changement, alors tout ira très bien (veinard ... ).La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand ça marche mais qu'on ne sait pas pourquoi. Quand la théorie rejoint la pratique, rien ne fonctionne et on ne sait pas pourquoi. |
| Jack | #7 Posté le 9/7/2012 à 16:10:38 |
| Il y a toujours des solutions il suffit de poser les bonnes questions. En entreprise, y'a toujours un vieux pc en rebut dans un coin. Le récupérer n'est pas difficile puisque personne ne le veut ce vieux truc. Tellement vieux qu'on peut même pas mettre Windows dessus. Alors on installe un serveur Debian (ou autre) et un serveur MySQL ou Postgresql et hop ! voila un serveur sur lequel tout le monde peut se connecter. Et si certains postes sont sous Windows il suffit dans ce cas d'installer un serveur Linux avec sessions graphiques + un serveur de bases de données + un serveur freenx ou neatx. Sur ce serveur on créera autant d'utilisateurs que de clients Windows et sur chaque poste Windows les clients nx de nomachine. Mais dans ce cas on aura besoin d'un peu plus de puissance. Je partage l'avis de Prokopy, une base de donnée de type MySQL ou Prostgresql sera a choisir dans les cas ou on se retrouvera dans une situation de multi-utilisateur. Ces bases de données permettent de bloquer l'écriture le temps des mises à jour, je ne connais pas Sqlite mais je ne pense pas qu'elle permette cela or si cette possibilité n'est pas utile en mono-utilisateur, elle devient indispensable en multi-utilisateur. Pour un code démocratique nationalisons Gambas. | |
| manu | #8 Posté le 10/7/2012 à 13:37:49 |
Avec Gambas ca roule ! | Salut a tous, Bon la typiquement, c'est bien une base de données qu'il faut utiliser puisque déjà,il existe une commande sql faite pour ca : insert into table1 select * from table2 .Moi voila comment je vois la chose : Primo : dans le cas de l'utilisation souhaité par Spheris, pas d'architecture client/serveur car les mesures faites par les techniciens sont Hors connexions (bein oui, au milieu d'une fromagerie, d'un hangard à pommes, ou autre il y a rarement du wifi ou des prises rj45... ). Personnellement, je partirais sur une BDD sqlite locale et identique pour chaque technicien. Seul, un champ "technicien" (ou plutôt "idTecnitien" ), permettrait de savoir d'ou viens l'enregistrement. J'utiliserais en revanche le cloud pour cette application plutôt que le FTP. Je m'explique.Il est très facile aujourd'hui d'avoir un espace cloud avec des protocole d'accés libre et gratuit permettant le montage dans votre systeme de fichier (via webdav) de votre cloud. Votre cloud (ou espace disque virtuel) se montera dans par exemple davs://monCloud.com/. J'en profite pour vous signaler que Ikoola vous fournis gratuitement ce service avec 10 Go de diponible... Donc la BDD est dans votre dossier personnel par exemple en locale sur votre ordi et vous faites vos enregistrements. Le soir, vous arrivez à l’hôtel ou chez vous et vous allumez votre ordi, si vous avez une connexion, votre ordi montra votre espace cloud. Votre application détectera ce montage et se préparera donc a une synchronisation. Sur ce cloud sera present un double de la BDD. L'application vous donnera la dernière date de modification de cette base. Si votre collègue est en train de synchroniser, la présence d'un fichier sync.lck, vous empêchera de procéder à la synchronisation de votre base. Si il a fini, ce fichier étant supprimé à la fin de l’opération, vous pourrez procéder a la synchronisation de votre base. La synchronisation consistera d'une part a fusionner les tables des deux bases, puis de faire en sorte que ces deux bases soient identiques sur votre disque locale et votre cloud. voilà pour le principe générale. Enfin et pour finir, le choix de la base de données est le choix a faire, car -1- Grace au composant gb.db.form, tu peux faire des formulaires de saisie sans aucune ligne de code ! -2- Grace au composant gb.report, tu peux faire des états de sortie imprimable sur imprimante ou pdf avec quelques lignes seulement ... (sur gambas3 par contre) Le choix de Gambas2 est donc le mauvais choix (bien que gambas2 soient capable de faire cela) parce que l'utilisation de la base de données est enormement plus simple dans gambas3, mais bon là je parle pas pour Spheris car il est indecrottable la dessus ! Jeanne d'arc, elle a frit, elle a tout compris ! Config : Manjaro linux (excellent !) XFCE 4.1 (simple et efficace) Gambas 3 dans les dépots (confort total) |
| Jack | #9 Posté le 10/7/2012 à 18:19:20 |
| Si, comme le dit Spheris, les fichiers texte sont envoyés régulièrement par ftp alors il suffit de mettre une base coté serveur et de lancer un script de récupération des données lors de la réception des fichiers. Par exemple un petit script qui se lancerait tous les jours a une heure précise par une commande cron. Ce script vérifie la présence des fichiers et si le fichier existe alors on le renomme pour éviter un écrasement malencontreux par un technicien extérieur. Ensuite on fait une lecture ligne par ligne des données et simultanément on met à jour la table "analyses" en vérifiant la présence de l'index. Si l'index est absent alors on créé l'enregistrement et on l'écrit dans un fichier texte (servant de rapport de la récupération) avec la mention "index créé lors de l'import", si l'index est présent alors on l'écrit dans le fichier de rapport avec la mention "index déjà saisit" (c'est un exemple bien sur). A la fin du fichier, on l'efface et on passe au suivant. A la fin du travail on n'oublie pas de fermer le fichier de rapport. En début de semaine, il suffit de lancer un script qui va générer un fichier texte des données contenues dans la table "analyses" qui sera ensuite envoyé aux technicien par mail ou par ftp. NB: Notez que dans ce cas, sqlite suffit coté serveur et que cela pourra fonctionner avec des fichiers envoyés par mail (il suffira de les sauvegarder dans le bon répertoire) NB: J'ajouterai que quant on aime coder, GB2 ou GB3 c'est pareil, l'essentiel est d'y prendre plaisir. J'en connais, à l'ère de l'informatique, qui persistent a écrire sur du papier avec un crayon  et ils aiment çà en plus .Pour un code démocratique nationalisons Gambas. | |
| Fly06 | #10 Posté le 10/7/2012 à 21:29:21 |
| Il y a 2 techniciens pour faire le même boulo. Je suggère de supprimer un poste de technicien. Bonne soirée. | |
| spheris | #11 Posté le 10/7/2012 à 23:21:41 |
| Merci à tous pour vos réponses toutes aussi instructives les unes que les autres. J'ai bien apprécié les : Mais spheris, que fais-tu encore sous GB2 ?! je suis d'avis avec Adrien. Pourquoi rester en GB2? car il est indecrottable la dessus ! ;)  Tous mes softs développés pour mon boulot sont en GB2. Pas sur qu'ils fonctionnent en GB3. A tester mais pas vraiment le temps pour le moment. Pour me recentrer sur le problème, l'idée d'un fichier texte par tech. n'est pas mal avec une petite variante :une mesure correspondrait à une ID.(un compteur local sur chaque PC) de sorte qu'une simple comparaison ID/tech avec le fichier central me dira si la mesure est déjà insérée dans la BDD sqlite ou pas. Quant au licenciement du 2eme tech. c'est un solution envisageable vu les performances médiocres qu'ils fournit (et je dis ça car il ne lira jamais ce post! Merci à chacun. message résolved |
| 1 | |