Chemin vers Base de Données sans DialogBox

Question

Bonjour à tous,

J'ai déjà réussi à faire en sorte qu'un utilisateur puisse, via une boîte de dialogue, choisir une base et ensuite récupérer son chemin pour s'y connecter.

Maintenant, dans l'application que je développe, on souhaite que personne ne puisse choisir la base, il faudrait donc que la connexion se fasse via des infos en dur, mais pas dans le code. J'avais donc pensé à stocker le chemin dans un fichier texte et en cas de déplacement de la base, il aurait suffit de modifier le fichier texte dans recompiler. Le problème, c'est que ce fichier texte doit bien être trouvé par le programme, et que donc son chemin ne doit pas varier.

Auriez vous une solution pour ce problème ?

Merci d'avance !

lolokun · Answer

Bonjour,

Fichier texte ou ini dans le répertoire de l'exe (facilement récupérable avec application.startuppath en .net).Mais bon cela n'empêcherait pas un utilisateur lambda de le déplacer ou de le supprimer..

Tu peux également inscrire cette info dans la base de registre.

Et au lancement ton programme ira vérifier le fichier texte ou la base de registre pour récupérer le chamin de ta base


L'expérience, c'est une connerie par jour, mais jamais la même..

dullbrain · Answer

Les utilisateurs lambda devront juste se servir du soft, pour eux ça s'arrête là, le truc du chemin pas en fixe c'est pour des raisons de facilité en cas de changement de serveur ou autre.

Du coup, comment on lie un fichier texte à un exe ?

Mayzz · Answer

Salut,

J'ai créé une boite de dialogue pour la connexion à MS SQL Server, tu peux t'en servir ou t'en inspirer.

Personnelement pourquoi tu ne met pas tes infos de connexion au sein du soft, je sais bien que tes utilisateurs n'irons pas configurer la connexion, mais il n'irons pas non plus modifier ou supprimer des propriétés ou des fichiers... Si tu penses comme ca alors pense à vérouiller les dossier système au cas ou, et aussi interdite l'exéctution d'application, puis boucler la tour dans un placard pour éviter que par accident il y mettent le feu ou la fasse tomber...

Il y en a qui n'y connaissent rien je te l'accorde, moi même ayant un pied dans la maintenance je suis bien placé pour le savoir, mais de la a passer par des méthodes comme celle-ci il n'y a aucun intérêt...

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

dullbrain · Answer

Lol, je suis en stage et je fais juste ce qu'on me dit ! On m'impose un chemin qui peut varier et qu'on doit pouvoir changer sans recompiler, après je dois le faire point barre ! ceci dit je suis bien d'accord avec toi, mais bon j'ai pas le choix ! Je vais donc essayer avec un fichier texte ! Merci :)

BOBO CALIMERO · Answer

Personnellement, dans mes applis, j'ai toujours une commande de menu qui envoi vers une fenêtre de configuration dans laquelle, l'utilisateur peut spécifier les chemins d'accès vers les fichiers "supports" (bases de données, documents modèles, etc.). L'ensemble de ces informations de configuration sont enregistrées dans le répertoire de ton application (App.Path), sous forme de fichier ini ou autre.

Au démarrage de mon application, des tests sont effectués pour vérifier la présence du fichier (par exemple ini) dans le répertoire d'application et pour vérifier également que les chemins d'accès qu'il mentionne sont accessibles. En cas de problème, je renvoie l'utilisateur à la fenêtre de configuration...

Ton fichier ini (ou autre, dans ton App.Path) porte toujours le même nom (précisé dans ton code) en revanche, les infos qu'il contient sont spécifiés par l'utilisateur lors de la configuration. Le programme utilise systématiquement ces chemins d'accès pour lire/écrire des infos.

dullbrain · Answer

D'accord, en gros ça revient à créer un fichier avec une extension en .ini, la mettre dans les ressources, tester au début du programme si ce fichier est présent, et ensuite aller lire dedans le chemin dans mon cas de la base à utiliser. Et du coup pour la modification de ce .ini, ça se fait via ton programme ?

Mayzz · Answer

j'ai toujours une commande de menu qui envoi vers une fenêtre de configuration dans laquelle, l'utilisateur peut spécifier les chemins d'accès vers les fichiers "supports" (bases de données, documents modèles, etc.

Je pense que oui 

Comme je te l'ai dis j'ai crée une boîte de dialogue pour les connexions distantes (MS SQL Serveur) mais c'est facilement adaptable pour d'autres serveurs de données, le principe est simple tu saisis les paramètres de connexion au serveur distant, puis tu les enregistres, ces données sont sauvegardés dans un fichier crypté sur le disque, puis l'utilisateur a juste a choisir sa connexion au démarrage du logiciel (sans avoir a saisir quoi que ce soit à nouveau), ce qui permet la connexion facile a plusieurs serveurs/bases. Cherches "SQL Connector" dans mes sources.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

BOBO CALIMERO · Answer

D'accord, en gros ça revient à créer un fichier avec une extension en .ini, la mettre dans les ressources, tester au début du programme si ce fichier est présent, et ensuite aller lire dedans le chemin dans mon cas de la base à utiliser. Et du coup pour la modification de ce .ini, ça se fait via ton programme ?

C'est exactement ça : quand l'utilisateur veut modifier des paramètres de configuration, il passe par la fenêtre de configuration. Tous les paramètres qu'il modifie sont enregistrés dans le fichier ini (ou autre...) après avoir été vérifiés par ton programme (bien entendu.)

dullbrain · Answer

Du coup si jamais la boîte change de serveur, le gars il a juste à lancer le soft, ça ne se connecte évidemment pas, du coup il change le .ini avec le nouveau chemin valide, et hop c'est reparti. C'est le principe ?

Désolé si je pose beaucoup de questions mais ce stage est assez important pour moi donc je veux vraiment pondre un bon truc au final ! Et merci à tous de répondre :)

Mayzz · Answer

Oui c'est le principe =)

En .Net, tu as aussi les paramètres d'application pour stocker des variables sur le disque et les retrouver au prochain démarrage, ce qui t'évite d'avoir à saisir le code pour l'enregistrement/lecture dans le fichier. Si c'est une base locale (Ecxel, Access, CSV etc...) qui ne nécessite qu'un chemin d'acceès pour la connexion (pas de paramètres ou d'identifiants) alors tu peux en effet le stocker dans les paramètres d'appli, dans le cas contraire, ce n'est pas recommandé pour des questions de sécurité, car le fichier est en claire sur le disque. 


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Utilisateur anonyme · Answer

Personnellement, pour qu'une appli retrouve facilement un fichier, j'utiliserai les SpecialsDirectory de l'espace de nom My

Pour le fameux dossier "mes documents"
My.Computer.FileSystem.SpecialDirectories.MyDocuments

ou plus commode le très utile dossier temp
My.Computer.FileSystem.SpecialDirectories.Temp

Mais ca n'est qu'une suggestion.
Bonne soirée.

Chemin vers Base de Données sans DialogBox

11 réponses

Votre réponse

Discussions similaires