Connection String SQL

[Sam]

What is the best practice for using a connection String?

Eg: In the Language I was writing in I would store it in a File then read
the
connection string into a global variable to connect to the SQl DB

In C# I am using OLEDB and am coding the connection string into
the Application.

What is the best practice for this -
and are there any example links

TIA

Samf

 

[Sam]

Sorry I Forgot - I am using MSSQL 2005 and 2008

samf

----- Original Message -----
From: "Mark Rae [MVP]" <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
Sent: Monday, August 24, 2009 12:11 AM
Subject: Re: Connection String SQL

What database are you using?



http://tinyurl.com/noyjmq

 

[Sam]

Thats why I am here.

What should I be using -
(Native MSsql)??

What are the best connection practices

Samf

 

[Sam]

Thank You
I will check out all the links

Samf

[please don't top-post]

What should I be using?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.aspx
http://www.connectionstrings.com/Providers/sqlconnection
http://www.connectionstrings.com/sql-server-2005#p1

 

[henry.lee.jr]

Thank You
I will check out all the links

Samf

news:eJUIy%[email protected]...

[please don't top-post]

Sorry I Forgot - I am using MSSQL 2005 and 2008
So why on earth are you using OleDb...???
What should I be using?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.aspx
http://www.connectionstrings.com/Providers/sqlconnection
http://www.connectionstrings.com/sql-server-2005#p1

I think this is a decent question and I would actually be interested
in the answer also. I think in addition to just information on what to
put in a connection string, the original poster was also curious as to
what approach makes sense as far as how to handle storing them. Do you
put them in the Properties.Settings fields, in a custom config, or
other? How best to handle switching environment dynamically, do you
use different config files on your PROD and QA box, or do you have
both environments available and toggle them based on a user name and
DB lookup?

I guess to answer the original poster's question, what I do is:

1. Store the connection string information in a config file that is
machine specific. So my PROD server has a PROD connection string, and
the same application on my QA server has a QA connection string. This
enforces a server-based environment.

2. I just use this connection string: conn = "Data Source=
[Server];Initial Catalog=[Database];Integrated Security=SSPI"; Without
specifying the Provider, I believe the system either recognizes or
assumes that you are connecting to SQLServer and uses the appropriate
interpreter.

As for the SQL Server Native client ... I believe that you only need
that when you aren't leveraging ADO.NET:

<blockquote>Why do I need SQL Native Client?

When would you actually want to use SQL Native Client as opposed to
MDAC, or even ADO.NET? The answer is – only if you are upgrading
existing or developing new COM-based (or native) applications that
will target the new features of SQL Server 2005. If you don’t need any
of the new features of SQL Server 2005, then you don’t need to use SQL
Native Client, your existing OLE DB and ODBC code will work just fine.
Of course, if you have or are planning on moving to a managed code
base for data access, then the ADO.NET data access classes of the .NET
Framework is what you should use.</blockquote>

 

[Jeff Johnson]

As for the SQL Server Native client ... I believe that you only need
that when you aren't leveraging ADO.NET:

<blockquote>Why do I need SQL Native Client?

When would you actually want to use SQL Native Client as opposed to
MDAC, or even ADO.NET? The answer is – only if you are upgrading
existing or developing new COM-based (or native) applications that
will target the new features of SQL Server 2005. If you don’t need any
of the new features of SQL Server 2005, then you don’t need to use SQL
Native Client, your existing OLE DB and ODBC code will work just fine.
Of course, if you have or are planning on moving to a managed code
base for data access, then the ADO.NET data access classes of the .NET
Framework is what you should use.</blockquote>

This quote makes my brain hurt. Where did you get it?

 

[Sam]

Henry,

Thank you.

That was what I was asking. As I have
decided to make C# my Programming language of choice
All my new dev work will be done in C#

Again Thank You

Sam

Thank You
I will check out all the links

Samf

message

news:eJUIy%[email protected]...

[please don't top-post]

Sorry I Forgot - I am using MSSQL 2005 and 2008
So why on earth are you using OleDb...???
What should I be using?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.aspx
http://www.connectionstrings.com/Providers/sqlconnection
http://www.connectionstrings.com/sql-server-2005#p1

I think this is a decent question and I would actually be interested
in the answer also. I think in addition to just information on what to
put in a connection string, the original poster was also curious as to
what approach makes sense as far as how to handle storing them. Do you
put them in the Properties.Settings fields, in a custom config, or
other? How best to handle switching environment dynamically, do you
use different config files on your PROD and QA box, or do you have
both environments available and toggle them based on a user name and
DB lookup?

I guess to answer the original poster's question, what I do is:

1. Store the connection string information in a config file that is
machine specific. So my PROD server has a PROD connection string, and
the same application on my QA server has a QA connection string. This
enforces a server-based environment.

2. I just use this connection string: conn = "Data Source=
[Server];Initial Catalog=[Database];Integrated Security=SSPI"; Without
specifying the Provider, I believe the system either recognizes or
assumes that you are connecting to SQLServer and uses the appropriate
interpreter.

As for the SQL Server Native client ... I believe that you only need
that when you aren't leveraging ADO.NET:

<blockquote>Why do I need SQL Native Client?

When would you actually want to use SQL Native Client as opposed to
MDAC, or even ADO.NET? The answer is – only if you are upgrading
existing or developing new COM-based (or native) applications that
will target the new features of SQL Server 2005. If you don’t need any
of the new features of SQL Server 2005, then you don’t need to use SQL
Native Client, your existing OLE DB and ODBC code will work just fine.
Of course, if you have or are planning on moving to a managed code
base for data access, then the ADO.NET data access classes of the .NET
Framework is what you should use.</blockquote>