Connection String SQL

  • Thread starter Thread starter Sam
  • Start date Start date
S

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
 
Thats why I am here.

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

What are the best connection practices

Samf
 
Thank You
I will check out all the links

Samf



news:eJUIy%[email protected]...
Click to expand...
[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?
Click to expand...
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
Click to expand...
Click to expand...
Click to expand...

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>
 
As for the SQL Server Native client ... I believe that you only need
that when you aren't leveraging ADO.NET:
Click to expand...
<blockquote>Why do I need SQL Native Client?
Click to expand...
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>
Click to expand...

This quote makes my brain hurt. Where did you get it?
 
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]...
Click to expand...
[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?
Click to expand...
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
Click to expand...
Click to expand...
Click to expand...

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>
 
Back
Top