Ne me surestime pas. Il y a un an, je ne connaissais même pas l'existence de VB.NET !(à moins que la DB cible ne changent également et qu'il y ait plus de choses à charger mais je ne pas que noftal soit du genre à passer à côté de ce genre de choses évidentes).
Qu'entends tu par "à moins que la DB cible ne change également ?
Comme un bon débutant, j'ai développé mon appli en utilisant au maximum l'IDE.
De ce fait, j'ai d'abord construit ma BdD. Puis j'ai importé les tables dans une page xsd (version graphique). Pour cela, j'ai donc dû relier cette table à une connectionString par défaut enregistrée dans les paramètres de mon projet.
Mais comme le propre de mon appli est de se baser sur une BdD créée par l'utilisateur, la connectionString est par définition variable. Or je ne peux pas la modifier dans les paramètres (je me souviens que ce point avait déjà fait l'objet d'une demande de support sur ce forum il y a plusieurs mois). Donc, par le code, je suis obligé de redéfinir une connectionString en allant chercher le Path de ma BdD existante qui est stockée dans les paramètres de l'utilisateur (stockés eux-mêmes dans la base de registre).
En résumé :
- pour créer mon xsd, il me faut définir une connectionstring statique qui figure dans les paramètres de mon projet. A priori, cette connectionString n'est utilisée que pour consulter le contenu de mes tables dans le xsd en mode design, et n'est pas utilisée lors de l'exécution du programme. Quoique (????)
- Lors de l'exécution de mon appli, mon code définit une connectionString en fonction des paramètres de l'utilisateur et toutes les connection.open s'appuient uniquement sur cette connectionString.
Je ne sais pas si c'est ce que tu voulais dire, Kropernic, mais à y réfléchir, n'y a-t-il pas effectivement double connexion à la base de données en procédant comme je fais ?
A quel moment l'utilisateur choisit-il la base de données qu'il va attaquer ???
Je suis perplexe car tu dis que tu ne peux pas changer la ConnectionString dans les paramètres alors c'est justement à cela qu'ils servent via le fichier app.config ou qqch du genre (suis jamais sûr du nom).
Si le fichier de config du mode release pointe vers une DB inexistante, le temps perdu pourrait très bien venir de là. Ton application attend en vain une réponse d'un objet qui n'existe avant de décider qu'il avait attendu trop longtemps.
Vérifie donc cela.
Kropernic
Peut-être est-ce un bug lié à la version du Framework ?
Enfin il n'est pas recommandé de livrer en mode Debug pour toutes les raisons que l'on connait.
Less Is More
Pensez à utiliser les boutons , et les balises code
Desole pour l'absence d'accents, clavier US oblige
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
à l'époque où on a commencé en .net, on avait livré notre 1ère appli en mode debug, et notre appli qui devait fonctionner h24 plantait au bout d'une vingtaine d'heure
en compilant en release nous n'avions plus ce problème de fuite de mémoire (liée au code différent en debug surement)
et nous avions vu sur une page d'msdn que microsoft "interdisait" la livraison d'exe en mode debug
Outre le fait de la longueur entre debug et release,
(il faudrait que tu nous indiques comment tu testes entre debug et release ? debug sur ton PC avec BDD de test, release sur le PC d'un utilisateur avec BDD réelle ? tout sur le même pc de dev ? auquel cas tu démarres sur la BDD de test, puis bascule sur le réel)
Tu as un problème de conception ici
1er point
Pour la partie lier les DataGridView à la BDD directement dans le designer avec l'assistant, vb cré des fichiers
NomBDDDataSet.xsd dans lequel tu trouves ta chaîne de connexion (setting défini dans les paramètres du projet et visible dans app.config, fichier de config) du style (test avec Nwind)
(
Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 <Connections> <Connection AppSettingsObjectName="MySettings" AppSettingsPropertyName="NwindConnectionString" ConnectionStringObject="" IsAppSettingsProperty="true" Modifier="Assembly" Name="NwindConnectionString (MySettings)" PropertyReference="ApplicationSettings.WindowsApplication1.My.MySettings.GlobalReference.Default.NwindConnectionString" Provider="System.Data.OleDb" /> </Connections> <Tables>
Ex : App.config (fichier de config)
)
Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 <?xml version="1.0" encoding="utf-8" ?> <configuration> <connectionStrings> <add name="WindowsApplication1.My.MySettings.NwindConnectionString" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\Nwind.mdb" providerName="System.Data.OleDb" /> </connectionStrings>
NomBDDDataSet.Designer.vb dans lequel il fait toutes les liaisons et chargement ; notemment il y a une méthode
Qui se sert de la chaîne de connexion (setting fichier de config)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 Private Sub InitConnection() Me._connection = New Global.System.Data.OleDb.OleDbConnection() Me._connection.ConnectionString = Global.WindowsApplication1.My.MySettings.Default.NwindConnectionString End Sub
Normalement, tu ne touches pas ces 2 fichiers (NomBDDDataSet.xsd NomBDDDataSet.Designer.vb), il sont générés automatiquement.
2ème point
Tu lis une chaîne de connexion inscrit dans la base de registre
Là, tu risques de ne pas être sur la même BDD.
Normalement, comme l'indique Kropernic, la chaîne de connexion se défini dans le fichier de config lié à l'appli.
Il porte le même nom que l'appli : NomApplication.exe.xml
Suivant la façon dont tu testes, tu tombes sur le problème. (ou pas)
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
@rv26t
1er point : je regarderai quand je serai sur mon PC de dev, mais ça se passe très probablement comme tu dis, puisque la chaîne de connexion qui me permet de créer mon xsd est enregistrée dans le settings/paramètres du projet.
2ème point : soit, mais comment résoudre ce dilemme :
- pour créer un fichier XSD, je dois renseigner une chaine de connexion "en dur" dans l'IDE
- une fois le fichier XSD créé, cette chaine de connexion ne sert plus
- à l'exécution je crée ma chaine de connexion dynamiquement
- il n'est pas possible de modifier dynamiquement la chaine de connexion enregistrée dans Settings/Paramètre (celle servant au XSD)
S'il y a possibilité de supprimer ma chaine de connexion statique maintenant que mon XSD est créé, je veux bien mais je crois avoir déjà essayé par le passé. Evidemment, le XSD râle.
Rappelons que l'intérêt du XSD était pour moi de créer un dataset fortement typé. Toute ma communication avec ma BdD utilise le caractère fortement typé de mon dataset.
Pour répondre à ta première question : je teste depuis VS2010 ouvert, projet ouvert, mais avec une vraie Bdd utilisateur (la mienne). Puis, je fais varier le champ Release/Debug et je lance l'appli avec la flèche "Exécuter" (pas celle du mode debug hein ?)
Cela dit, je n'ai pas vérifié si, en pratique, le path de ma Bdd est la même que celui de la chaine de connexion utilisée par le xsd. Je crois que oui, mais je vérifierai. Mais si je te suis, peu importe que les chaines soient identiques, il y a risque d'ouvrir 2 fois la Bdd ?
A travers les propriétés du projet par exemple. Et il cré un fichier app.config. Il doit aussi le faire lors de la création pour les dataset à travers l'ide lorsqu'il demande la BDD et réalise la connexion (dans mon test le fichier de config a été créé ainsi (note : je n'utilise pas ces créations automatiques)
Ben si, pour tout les éléments créé automatiquement par l'assistant.
Dans le designer.vb du form il fait appel à des beginInit qui sont dans NomBDDDataSet.designer.vb (créé par l'assistant) (sur NomBDDDataSet, NomTableDataGridView, ...)
Dans le code du designer du dataset NomBDDDataSet.Designer.vb qui sert à l'init automatique du dataset et compagnie.
je trouve d'ailleurs cette méthode dans NomBDDDataSet.Designer.vb
Non, il faut prendre celle du fichier de config, qui sera ainsi la même que celle de l'init généré de façon automatique.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 Private Sub InitConnection() Me._connection = New Global.System.Data.OleDb.OleDbConnection() Me._connection.ConnectionString = Global.WindowsApplication1.My.MySettings.Default.NwindConnectionString End Sub
Il faut modifier le fichier de config de l'appli, puis lancer l'appli ainsi la nouvelle chaîne de connexion sera prise en compte (par la partie générée automatiquement et la partie codée.
Lance l'exe (release) [Edit](dans le répertoire release tu dois avoir monapp.exe et monapp.exe.config)[/Edit]
Normalement tu ouvres la connexion au moment ou tu en as besoin, puis la ferme une fois ta ou tes requête(s) faite, non ? (je n'utilise pas les trucs automatiques dans mes dev)
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
Quelque chose du genre (en quasi-langage) :Il faut modifier le fichier de config de l'appli, puis lancer l'appli ainsi la nouvelle chaîne de connexion sera prise en compte (par la partie générée automatiquement et la partie codée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 Masource = InputBox("Chemin de la BdD utilisateur") Chercher dans le fichier app.config la ligne <add name="WindowsApplication1.My.MySettings.NwindConnectionString" connectionString=Data source = C:\Users\noftal\Documents\MonAppli\DefaultBdd.db" providerName="System.Data.SQLite" /> Remplacer la chaine Datasource=... par Masource Enregistrer app.config
Mais je me pose 2 questions :
- Le fichier app.config n'est a priori pas déployé avec mon appli. Il ne figure en effet pas dans le répertoire Release (ni Debug) mais dans le répertoire parent. Cela veut dire que, une fois compilé, le .exe ne le connait plus. Une fois l'appli déployée comment mettre en oeuvre le code évoqué ci-dessus ?
- quelle classe me conseilles-tu pour faire ces interventions sur le fichier. J'ai bien pensé à la classe File mais les méthodes de cette classe me laissent entrevoir un code assez lourd alors que ce doit être assez simple, non ?
Sinon, j'ai vérifié, ma bdD est dans le même répertoire que celui indiqué par défaut pour mon Xsd
Le fichier app.config n'est pas déployé avec ton appli, c'est normal.
Il est utilisé pour créer un nouveau fichier qui s'appele monappli.exe.config (de type XML configuration file) (comme tous tes .vb sont compilés pour faire un .exe ; monappli.exe)
Le fichier de config a le même nom que l'application (avec l'extention .exe incluse dans le nom du fichier de config) de type XML
Dans bin\release tu as : monappli.exe, monappli.exe.config, d'autres fichiers.
idem dans bin\debug tu as : monappli.exe, monappli.exe.config, d'autres fichiers + d'autres encore.
Tu installes : monappli.exe et monappli.exe.config, tu configures manuellement avec notepad monappli.exe.config pour qu'il pointe sur ta BDD de production.
Ensuite lors des mises à jour tu installes seulement l'exe (et éventuellement met à jour le fichier de config manuellement si tu as fait des changements)
Il faut modifier le fichier de config appartenant à l'application manuellement (pas depuis l'application) avec notepad ou notepad++ à la première installation.
Une fois installé et modifié, tu n'y touches plus. et ne le réinstalle pas, sinon tu écrases tes modif.
Comme cela est placé dans les settings, (propriétés du projet, paramètres, l'élément de type "(Chaîne de connexion)" montre son nom et sa valeur)
Et c'est ainsi que tu accédes à la chaîne de connexion pour la suite des accès avec ton code. (après l'init automatique du désigner)
Code : Sélectionner tout - Visualiser dans une fenêtre à part MessageBox.Show(My.Settings.NwindConnectionString) ' NwindConnectionString est le nom de ma connection de mes tests avec la BDD Nwind
Quand tu testes en réel lance l'exécutable.
(quand tout l'ensemble sera clarifié on verra pour des stopwatch dans le désigner (comme indiqué par Pol63 avec une copie de ton projet)
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
Mon appli fonctionne autour d'une base de données locale. Il s'agit d'une gestion de bibliothèque.
Lorsque l'utilisateur lance l'appli, l'appli doit vérifier si une base a été déjà renseignée (1). Sinon, il demande à l'utilisateur à quel endroit il souhaite implanter le fichier de bdd (2).
Les solutions mises en oeuvre jusqu'ici sont les suivantes :
(1) L'appli interroge la base de registre. Si une clé "DBfolder" existe, alors c'est que l'utilisateur a déjà utilisé le logiciel et a donc renseigné un chemin pour son fichier de base de données. L'appli lit cette clé et crée une chaine de connexion à partir du chemin contenu dans cette clé.
(2) L'appli crée un fichier de BdD et le stocke au chemin indiqué par l'utilisateur. Dans le même temps il écritune clé "DBfolder" dans la base de registre pour y stocker le chemin.
Pour le (1), je suis d'accord qu'on pourrait lire une chaine de connexion stockée dans les Settings, mais auparavant, à la première utilisation, il faut que je puisse stocker cette chaine de connexion dans ces mêmes settings, et ce, dynamiquement (par le code). Comme ce n'est pas possible, il faut bien que je passe par un autre moyen de stockage. Ce peut être du XML ou une base de registre...
Mais surtout, dans ce que tu m'indiques, je ne vois pas le moyen de modifier la chaine de connexion dynamiquement.
Sinon, je n'ai pas de fichier monappli.exe.xml mais j'ai monappli.xml et monappli.exe.config.
Hello,
Plusieurs points sur lesquels je désire intervenir / taper sur le clou :
- Quand on crée un dataset, la chaîne de connexion utilisée à la création est celle utilisée dans le programme sauf indication contraire. Si dans un formulaire, tu as bindé un objet du dataset à un contrôle, je pense (je reste prudent car ça fait des années que je n'utilise plus ces machins-là) que les objets des datasets se créent/remplissent plus ou moins "tout seul" sans demander ton avis durant le processus d'instanciation du formulaire. Ce qui fait que si la DB utilisé en design n'est plus présent lors des tests, ça pose forcément problème et ça devrait générer une exception.
- Si tu n'as pas d'exception, il y a de forte chance que tout cela se passe durant l’événement Load du formulaire. Or un bug connu du framework est que, si une exception est levé durant cet événement, l'exécution s'arrête et le formulaire s'affiche sans te signaler quoi que ce soit. Cependant, je pense que cela ne se produit qu'en mode Debug (à vérifier).
- Il a été dit que le fichier de config ne se trouve pas dans le répertoire Debug / Release du projet. Il est toujours possible que j'aurai modifié la config de VS sans m'en souvenir mais chez moi, il s'y trouve bien. Par contre, son extension est .config et pas .xml comme signalé par Hervé. Il s'agit cependant bien d'un fichier XML.
- Il est tout à fait possible de modifier des paramètres de projet à l'exécution. Il faut juste s'assurer que le paramètre en question soit de portée User et pas Application. Un paramètre de type ConnectionString est malheureusement par défaut de portée Application. Mais vu que ce n'est quand même rien de plus qu'un type String déguisé, cela fonctionne parfaitement en utilisant un type String et une portée User pour y mettre notre de chaîne de connexion.
- Je pense qu'utiliser une clef de registre est une bonne chose. Cela évitera des problèmes avec les utilisateurs plus avancés qui risquent d'aller chipoter à ce qu'ils ne devrait pas dans le fichier de config de l'application. Cependant, cette vérification doit se faire en amont de l'ouverture du formulaire pour les raisons que j'ai indiqué au point 1. Pareil pour le choix que l'utilisateur doit faire en cas de clef inexistante. Les splashscreens sont là pour ça il me semble.
Voilà, je pense que c'est tout. Si j'ai dit des conneries, n'hésitez pas à me le faire remarquer.
Kropernic
Oui désolé, c'est bien monappli.exe.config avec l'extention .config de type xml (j'ai tapé un peu vite hier soir sans faire attention, j'ai corrigé mon post)
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
En fait, tu n'a pas le choix, avec la solution génération automatique, il lit dans les settings.
code dans "...DataSet.Designer.vb"
C'est le problème des générations automatiques, tu n'as pas la main sur tout. Mais comme je n'utilise pas ce principe, je ne peux pas t'affirmer que c'est impossible.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 Private Sub InitConnection() Me._connection = New Global.System.Data.OleDb.OleDbConnection() Me._connection.ConnectionString = Global.WindowsApplication1.My.MySettings.Default.NwindConnectionString End Sub
Faut voir si d'autres intervenants connaissent bien ou ont des idées.
La seule solution que je connais est d'aller dans le fichier de config mettre à jour.
Il faudra donc modifier ce fichier de config par code lors du choix de l'emplacement de la BDD.
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
OK, donc on en revient au problème initial.
Quoique je fasse (hormis tout recoder en abandonnant mon bon vieux dataset typé), je ne peux pas empêcher mon appli d'exécuter une première connexion lié au fichier XSD avec la Var1 = ConnectionString figurant en dur dans les settings, puis d'effectuer une 2ème connexion avec la Var2 = chemin de l'utilisateur. Même si Var2 est stocké dans le exe.config, le .exe, lui va d'abord lire Var1 qui est compilé avec lui.
A la réflexion, je me demande si le pb que j'évoquais ici (et que je n'ai toujours pas résolu) ne serait pas lié.
Je ne sais pas ce qu'il fait de ce xsd. c'est un xml descriptif.
Mais tu peux modifier le fichier de config avant d'ouvrir ta fenêtre, ainsi les méthodes initConnection utilisées par le "...dataset.designer.vb" utiliseront le fichier de config mis à jour. (et ton chargement automatique par le designer pointera sur la bonne BDD)
Après le choix de l'emplacement de la BDD par l'utilisateur tu fais (NwindConnectionString est le nom de ma chaîne de connexion)
le fichier de config de mes tests :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 MessageBox.Show(ConfigurationManager.ConnectionStrings("WindowsApplication1.My.MySettings.NwindConnectionString").ToString) ' ou MessageBox.Show(My.Settings.NwindConnectionString) Try Dim FichierConfig As Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None) FichierConfig.ConnectionStrings.ConnectionStrings("WindowsApplication1.My.MySettings.NwindConnectionString").ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\data\test\Nwind.mdb" FichierConfig.Save(ConfigurationSaveMode.Modified, True) ConfigurationManager.RefreshSection("connectionStrings") Catch ex As Exception MessageBox.Show(ex.ToString) End Try MessageBox.Show(ConfigurationManager.ConnectionStrings("WindowsApplication1.My.MySettings.NwindConnectionString").ToString) ' voir après ' ou MessageBox.Show(My.Settings.NwindConnectionString)
Avant modif (par code)
Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 <connectionStrings> <add name="WindowsApplication1.My.MySettings.NwindConnectionString" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\Nwind.mdb" providerName="System.Data.OleDb" /> </connectionStrings>
Après modif (par code)
Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 <connectionStrings> <add name="WindowsApplication1.My.MySettings.NwindConnectionString" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\data\test\Nwind.mdb" providerName="System.Data.OleDb" /> </connectionStrings>
Ensuite pour tes connexions, tu fait l'appel classique aux settings de la chaiîne de connexion.
Fait bien attention dans tes tests, on a vite mélangé entre debug, release.
Code : Sélectionner tout - Visualiser dans une fenêtre à part ... = My.Settings.NwindConnectionString
Le mieux installe l'exe et son fichier de config dans un répertoire de test, et lance l'exe.
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
Salut,
J'ai un pb de syntaxe avec ConfigurationManager, Configuration et ConfigurationSaveMode
Faut-il importer une référence particulière ? Si oui, l'IDE ne m'en suggère aucune.
EDIT : j'ai trouvé : system.configuration
OK mais qu'est-ce que ça va changer par rapport à mon code actuel qui est le suivant :
Je vois bien que la chaine de connexion va être stockée dans le fichier config au lieu de la BdR. Mais, comme dans mes tests réalisés la connectionstring qui se trouve par défaut dans ce fichier est la même que celle que je renseigne lors de l'éxécution de l'appli, cela ne va rien changer en termes d'optimisation de l'appli. A la rigueur on pourrait admettre que ça change quelque chose si un jour je fais un test avec des chemin différents. Personnellement, je ne l'ai pas fait, mais d'autres utilisateurs ont testé mon appli et leur log_perfo ne semblait pas dégradé par rapport au mien. ll était même souvent meilleur, ceci s'expliquant par la puissance de leur machine.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 public strDataBaseCon as string Dim nodeReg As Microsoft.Win32.RegistryKey nodeReg = My.Computer.Registry.CurrentUser.CreateSubKey("Software").CreateSubKey(Application.ProductName) ' ... ' ici j'intercale la procédure qui demande le chemin à l'utilisateur et stocke ce chemin dans une clé Dbfolder de la BdR '... ' je stocke dans une variable publique ma connectionString strDatabaseCon = "Data source = " & Chr(34) & Path.Combine(CStr(nodeReg.GetValue("DBfolder")), DB_CURRENT) & Chr(34) '... ' puis, à chaque fois que je doit agir sur la BdD, je fais : Dim con As New SQLiteConnection(strDatabaseCon) con.Open() '... con.Close()
Ben justement,
La partie automatique du designer pointera sur une base de données défini dans les settings (embarqué dans l'exe ou dans le fichier de config si présent)
Et ton code pointera (citation ci-dessus - chance) sur la même ou ton code pointera (choix utilisateur autre emplacement - pas de chance) sur une autre base de données.
Ce n'est pas une question de performance (quoi que)
Explication
Lancement de la partie automatique par le designer
1er cas : exe seul
au lancement de l'application, ne trouvant pas le fichier de config la chaîne de connexion est prise dans les settings embarqué par defaut dans le code.
fichier : settings.designer.vb ; propriété en dur dans les attributs du code (tu ne peux rien faire)
2ème cas : exe et son fichier de config
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 <Global.System.Configuration.ApplicationScopedSettingAttribute(), _ Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _ Global.System.Configuration.SpecialSettingAttribute(Global.System.Configuration.SpecialSetting.ConnectionString), _ Global.System.Configuration.DefaultSettingValueAttribute("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\Nwind.mdb")> _ Public ReadOnly Property NwindConnectionString() As String Get Return CType(Me("NwindConnectionString"),String) End Get End Property
au lancement de l'application, la chaîne de connexion est prise dans le fichier de config (méthode InitConnection) (tu peux seulement mettre à jour le fichier de config).
fichier : form1.designer.vb, NwindDataSet.designer.vb ;
'NwindDataSet.designer.vb
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 'form1.designer.vb Private Sub InitializeComponent() ' ... CType(Me.OrdersBindingNavigator, System.ComponentModel.ISupportInitialize).BeginInit() Me.OrdersBindingNavigator.SuspendLayout() CType(Me.OrdersDataGridView, System.ComponentModel.ISupportInitialize).BeginInit() CType(Me.OrdersBindingSource, System.ComponentModel.ISupportInitialize).BeginInit() CType(Me.NwindDataSet, System.ComponentModel.ISupportInitialize).BeginInit() Me.SuspendLayout() ' ...
Affichage du datagridview
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 <Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _ Global.System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")> _ Private Sub InitConnection() Me._connection = New Global.System.Data.OleDb.OleDbConnection() Me._connection.ConnectionString = Global.WindowsApplication1.My.MySettings.Default.NwindConnectionString End Sub
Dans toute cette partie automatique tu ne peux pas modifer le code pour lui dire d'aller chercher la chaîne de connexion dans la base de registre.
La seule chose que tu peux faire, c'est de modifier le fichier de config avec le code que je t'ai donné.
Tel que tu as construit ton appli, a partir d'ici tu vas chercher la chaîne de connexion dans la base de registre, si l'utilisateur à choisi un autre emplacement que celui par défaut, il pointe au démarrage sur une base de données, puis passe sur une autre qui sera utilisée par ton code.
Fait le, tu verras que tu passes d'une bdd à une autre.
If faut te servir du fichier de config (tu n'as pas le choix) ou ne plus utiliser la partie designer et tout recoder
Si tu ne veux pas tout recoder tu dois utiliser le fichier de config
Le modifier (avec le code que je t'ai donné) à l'install, et utiliser les settings dans ton code (tu affectes le settings connection à ta variable).
A adapter
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 public strDataBaseCon as string Dim nodeReg As Microsoft.Win32.RegistryKey nodeReg = My.Computer.Registry.CurrentUser.CreateSubKey("Software").CreateSubKey(Application.ProductName) ' ... ' ici j'intercale la procédure qui demande le chemin à l'utilisateur '... Dim FichierConfig As Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None) FichierConfig.ConnectionStrings.ConnectionStrings("WindowsApplication1.My.MySettings.TonNomConnectionString").ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & VarCheminNomBDD FichierConfig.Save(ConfigurationSaveMode.Modified, True) ConfigurationManager.RefreshSection("connectionStrings") ' je stocke dans une variable publique ma connectionString 'strDatabaseCon = "Data source = " & Chr(34) & Path.Combine(CStr(nodeReg.GetValue("DBfolder")), DB_CURRENT) & Chr(34) strDatabaseCon = My.Settings.NwindConnectionString ' ou ConfigurationManager.ConnectionStrings("WindowsApplication1.My.MySettings.TonNomConnectionString").ConnectionString '... ' création et affichage fenêtre - ok - même bdd designer et code
Teste avec l'exe (attention sans fichier de config il va aller chercher la bdd dans tes rep de dev, c'est trompeur)
Traductions d'articles :
La mémoire en .NET - Qu'est-ce qui va où ?
Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager