Global connection strings?

  • Thread starter Thread starter Rob Oldfield
  • Start date Start date
R

Rob Oldfield

I have a question regarding connection strings. Most of my apps have
multiple forms each of which stores a connection string back to (generally
speaking) the same SQL db (i.e. it's set up the way that VS.Net appears to
work by default).

Is there any advantage in having some kind of global connection string?
(...apart from the obvious one about making it easier to update if the db
moves to a different server...). What is best practice?

Thank you
 
Hi Rob,

IMO is better to have a global connection string.
One reason you already stated (it is really good to have it in one place).
The other reason would be that connection strings has to be indentical for
connection pooling to work.
 
Our approach is to have one connection string in the app.config file, read
it on program startup, test to see if the connection works, if it does, then
store it in a global variable for that particular exe. If it does not work,
advise the user of the error. Since it does not need to be changed often
(only when servers are being changed) its ok to let tech personnel do the
change with a text editor in the app config file when this happens.
Otherwise we write a configuration menu item that lets users call a form
allowing them to change and test the connection strings, By the way, we
always try to use Windows integrated security for user login to SQL server -
User names and passwords and accesses are managed by administrators and we
don't have to have user names and passwords in the connection strings in the
app.config file.
Hope this helps,

Bob
Miha Markic said:
Hi Rob,

IMO is better to have a global connection string.
One reason you already stated (it is really good to have it in one place).
The other reason would be that connection strings has to be indentical for
connection pooling to work.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Rob Oldfield said:
I have a question regarding connection strings. Most of my apps have
multiple forms each of which stores a connection string back to (generally
speaking) the same SQL db (i.e. it's set up the way that VS.Net appears to
work by default).

Is there any advantage in having some kind of global connection string?
(...apart from the obvious one about making it easier to update if the db
moves to a different server...). What is best practice?

Thank you
Click to expand...
Click to expand...
 
I use a similar approach. I load the connection string from a config file on
startup and test I everything is ok. But I don't shared the connection
string - I create one instance of SqlConnection (or OleDbConnection) and
share this one connection between all the forms in the app.

Regards,
Phil.

Bob Dufour said:
Our approach is to have one connection string in the app.config file, read
it on program startup, test to see if the connection works, if it does, then
store it in a global variable for that particular exe. If it does not work,
advise the user of the error. Since it does not need to be changed often
(only when servers are being changed) its ok to let tech personnel do the
change with a text editor in the app config file when this happens.
Otherwise we write a configuration menu item that lets users call a form
allowing them to change and test the connection strings, By the way, we
always try to use Windows integrated security for user login to SQL server -
User names and passwords and accesses are managed by administrators and we
don't have to have user names and passwords in the connection strings in the
app.config file.
Hope this helps,

Bob
Miha Markic said:
Hi Rob,

IMO is better to have a global connection string.
One reason you already stated (it is really good to have it in one place).
The other reason would be that connection strings has to be indentical for
connection pooling to work.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Rob Oldfield said:
I have a question regarding connection strings. Most of my apps have
multiple forms each of which stores a connection string back to (generally
speaking) the same SQL db (i.e. it's set up the way that VS.Net appears to
work by default).

Is there any advantage in having some kind of global connection string?
(...apart from the obvious one about making it easier to update if the db
moves to a different server...). What is best practice?

Thank you
Click to expand...
Click to expand...
Click to expand...
 
Interesting.... and thanks to both of you.

One possibility that comes to me would be to write the connection string
into the registry via a login script and then read that into a variable.
Would avoid the need for people to be editing config files....

Any thoughts...

(....and apologies to Bob for sending directly....)


Bob Dufour said:
Our approach is to have one connection string in the app.config file, read
it on program startup, test to see if the connection works, if it does, then
store it in a global variable for that particular exe. If it does not work,
advise the user of the error. Since it does not need to be changed often
(only when servers are being changed) its ok to let tech personnel do the
change with a text editor in the app config file when this happens.
Otherwise we write a configuration menu item that lets users call a form
allowing them to change and test the connection strings, By the way, we
always try to use Windows integrated security for user login to SQL server -
User names and passwords and accesses are managed by administrators and we
don't have to have user names and passwords in the connection strings in the
app.config file.
Hope this helps,

Bob
Miha Markic said:
Hi Rob,

IMO is better to have a global connection string.
One reason you already stated (it is really good to have it in one place).
The other reason would be that connection strings has to be indentical for
connection pooling to work.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Rob Oldfield said:
I have a question regarding connection strings. Most of my apps have
multiple forms each of which stores a connection string back to (generally
speaking) the same SQL db (i.e. it's set up the way that VS.Net
Click to expand...
Click to expand...
appears
to
Click to expand...
Click to expand...
 
Hi Rob,

Based on my understanding, you want to know the good practise about where
to store the connection string.

Normally, for your situation, we suggest you store the connection string in
a config file(app.config or web.config). But because the config file is
plain text, we have several alternatives, please refer to:
"Database Security"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html
/vxconDatabaseSecurity.asp
These options is for the connection string security.

For your idea of storing in registry, it is not very perfect. Storing in
registry will not eliminate the user from getting and modifying the
connection string.(user may use reg monitor to get the registry key, then
modify it). So the options in the article above should be good practise.
=======================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi Rob,

Does my reply make sense to you? Do you still have concern on this issue?

Please feel free to feedback. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi Rob,

Thanks very much for your feedback!

I am glad your problem resolved. If you need further help, please feel free
to tell me, I will work with you , thank!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top