ADO.NET and DSN
-
I have an odd question here for all you data-centric folks... Let's say that I am developing a webservice that will perform some actions on a SQL database. I am to the point where I am starting to code the data-centric portion of the service. I want to add a connection to my webservice, but find that I can't seem to reference a DSN. It looks to me like I have to reference the servername and database directly. Alot of this fancy ADO.NET integration into the IDE seems to me to look like they expect us to develop on the same system we are going to deploy on? If I am developing on a system where the servers name is 'Serv01' and use all the fancy IDE integration wizzards to set things up, then move to a deployment where I have no control over my server names, how if my app supposed to function? This is why I like DSNs. I can mandate what they are named, and as long as they reference a server that has the proper database that I need my app does not care. Am I the only one that sees this as a problem?
-
I have an odd question here for all you data-centric folks... Let's say that I am developing a webservice that will perform some actions on a SQL database. I am to the point where I am starting to code the data-centric portion of the service. I want to add a connection to my webservice, but find that I can't seem to reference a DSN. It looks to me like I have to reference the servername and database directly. Alot of this fancy ADO.NET integration into the IDE seems to me to look like they expect us to develop on the same system we are going to deploy on? If I am developing on a system where the servers name is 'Serv01' and use all the fancy IDE integration wizzards to set things up, then move to a deployment where I have no control over my server names, how if my app supposed to function? This is why I like DSNs. I can mandate what they are named, and as long as they reference a server that has the proper database that I need my app does not care. Am I the only one that sees this as a problem?
-
We got around this by storing the database server name and database name in the registry. It is set during the installation of the program on the end computer.
yesh, I understand that part, but then all the fancy wizzard stuff goes to hell. If it let you point to a DSN it could all be happy.
-
yesh, I understand that part, but then all the fancy wizzard stuff goes to hell. If it let you point to a DSN it could all be happy.
To point to a DSN, you need to download OBDC.NET from Microsoft's site ODBC .NET Data Provider[^] and instead of using System.Data.OleDb... objects, you use Microsoft.Data.Odbc... objects. Remember that ODBC is a Windows thing but .NET is supposed to be as neutral as possible. Paul
-
To point to a DSN, you need to download OBDC.NET from Microsoft's site ODBC .NET Data Provider[^] and instead of using System.Data.OleDb... objects, you use Microsoft.Data.Odbc... objects. Remember that ODBC is a Windows thing but .NET is supposed to be as neutral as possible. Paul
Well according to the download page this comes as part of Mdac 2.7, which is installed as part of .NET, so I should already have this. I'll take a look at it when I get back to the home office.
-
Well according to the download page this comes as part of Mdac 2.7, which is installed as part of .NET, so I should already have this. I'll take a look at it when I get back to the home office.
Ray Cassick wrote: Well according to the download page this comes as part of Mdac 2.7 No, it says it requires MDAC 2.7 :) Trust me, I've been using it for a while. It lacks some of the wizards that OleDb uses, but that's only a good thing in my opinion. Paul
-
Ray Cassick wrote: Well according to the download page this comes as part of Mdac 2.7 No, it says it requires MDAC 2.7 :) Trust me, I've been using it for a while. It lacks some of the wizards that OleDb uses, but that's only a good thing in my opinion. Paul
Well I'll give it a try then... Thanks.