Global connection strings?

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

Miha
Mon Oct 18 14:16:14 CDT 2004

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" <blah@blah.com> wrote in message
news:uODCF8TtEHA.2800@tk2msftngp13.phx.gbl...
>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
>
>

Bob
Mon Oct 18 16:08:46 CDT 2004

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 [MVP C#]" <miha at rthand com> wrote in message
news:OXfHxbUtEHA.4040@TK2MSFTNGP09.phx.gbl...
> 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" <blah@blah.com> wrote in message
> news:uODCF8TtEHA.2800@tk2msftngp13.phx.gbl...
> >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
> >
> >
>
>

Rob
Mon Oct 18 17:26:50 CDT 2004

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" <bobatth@hotmail.com> wrote in message
news:OgFjgcVtEHA.412@TK2MSFTNGP14.phx.gbl...
> 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 [MVP C#]" <miha at rthand com> wrote in message
> news:OXfHxbUtEHA.4040@TK2MSFTNGP09.phx.gbl...
> > 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" <blah@blah.com> wrote in message
> > news:uODCF8TtEHA.2800@tk2msftngp13.phx.gbl...
> > >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
> > >
> > >
> >
> >
>
>

PhilWilliams
Mon Oct 18 17:25:03 CDT 2004

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" wrote:

> 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 [MVP C#]" <miha at rthand com> wrote in message
> news:OXfHxbUtEHA.4040@TK2MSFTNGP09.phx.gbl...
> > 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" <blah@blah.com> wrote in message
> > news:uODCF8TtEHA.2800@tk2msftngp13.phx.gbl...
> > >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
> > >
> > >
> >
> >
>
>
>

v-jetan
Mon Oct 18 20:33:37 CDT 2004

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.

v-jetan
Wed Oct 20 20:18:29 CDT 2004

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.

Rob
Thu Oct 21 14:43:17 CDT 2004

No. I'm fine now. Thanks very much.


""Jeffrey Tan[MSFT]"" <v-jetan@online.microsoft.com> wrote in message
news:i8kgjvwtEHA.3608@cpmsftngxa10.phx.gbl...
> 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.
>

v-jetan
Thu Oct 21 20:33:13 CDT 2004

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.