Re: What's best practice using dynamic connections strings
- From: Martin <unko@xxxxxxxxxxxxxxxx>
- Date: Tue, 20 Jun 2006 08:06:02 -0700
Finally, when you are ready to release, you simply change the code that gets
the string from the Settings file to get it from this other mechanism.
But that's exactly my point. That cannot be done. The adapters are GENERATED
by the Data Designer of VS2005, and the code simply get the connection string
from the config file, wheter you like it or not.
In practice, you connect mostly to a databaseserver for which the
connectionstring rarely changes. But for MSA (file based) this is likely to
change more often. I believe that it would be better if the connectionstring
was stored as a user variable instead of an application variable.
I felt this was a shortcoming of the Data Designer, as I cannot control
where it will read the connection string from. My (workaround) solution is to
set the connection property programmatically, but I wonder if that is what
the creators of the Data Designer had in mind.
Hence my question: what's best practice ...
--
It's Software Jim, but not as we know it!
"Kevin Spencer" wrote:
Hi Martin,.
I see. It seems that you want the design-time support for database
connections, but also want to enable the user to change the Connection
String in the final version. I believe this can be achieved without too much
trouble.
First, you need to decide on a different storage mechanism for a Connection
String, such as a file, memory, or system registry. During the time that you
are developing, you can develop a temporary system to copy the Settings
Connection String to this other mechanism.
Then you need to create the user interface for changing the Connection
String stored in this other mechanism.
Finally, when you are ready to release, you simply change the code that gets
the string from the Settings file to get it from this other mechanism.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist
I recycle.
I send everything back to the planet it came from.
"Martin" <unko@xxxxxxxxxxxxxxxx> wrote in message
news:B50C73B5-3023-4E97-99AB-BC81B5E4372E@xxxxxxxxxxxxxxxx
The user can edit the app.config file to change the Connection String.
Sure, but my users are not developers. The point I wanted to make is that
the Table Adapters (generated by the Data Designer) make use of the
settings
in the config file (this is forced by VS2005), but that you are not
allowed
to update these settings programmatically using the My.Settings mechanism
(because it is an Application Setting)
My users have MS access files in various locations, and I can cope with
that
by storing the location and name in user settings. However the table
adapters
that are being generated will look for the connection string variable that
was used during design time. Thus I must override this with a
connectionstring which I have build from my user variable (and setting the
connection property during runtime).
Hence, what is the use of the system generated connectionstrings if they
cannot be changed during runtime?
Hope I make myself clear :-)
--
It's Software Jim, but not as we know it!
- Follow-Ups:
- Re: What's best practice using dynamic connections strings
- From: Linda Liu [MSFT]
- Re: What's best practice using dynamic connections strings
- From: Kevin Spencer
- Re: What's best practice using dynamic connections strings
- References:
- Re: What's best practice using dynamic connections strings
- From: Kevin Spencer
- Re: What's best practice using dynamic connections strings
- From: Kevin Spencer
- Re: What's best practice using dynamic connections strings
- Prev by Date: Re: What's best practice using dynamic connections strings
- Next by Date: Re: Object reference error in Data Sources Configuration Wizard
- Previous by thread: Re: What's best practice using dynamic connections strings
- Next by thread: Re: What's best practice using dynamic connections strings
- Index(es):
Relevant Pages
|