Deployment Question, Connection string issue.

When we deploy applications, we have been using DSN's set up on the
users systems. Then in the sqlconnection string, we go "dsn = xyz". I
tried this with our new application, which is the first to be done
with ADO.net and I get the following run time problem:

"An exception 'System.ArgumentException' has occured in <Myapp>".
I do the run time debugging and it tells me: "Keyword not supported:
'dsn'.

For those who have migrated to .Net, how do you handle this issue? I
mean, we are going to distribute this application, and our users will
have different names for their servers, so how do we specify a data
source dynamically.

The way we have it for the moment is that we read the information from
a config file. But it seems like there must be a better way. What
happened to dsn?

Any help on this would greatly appreciated.
Thanks,
Ed Hawkes
olaamigoquepasa@.nospamplease-hotmail.comEd Hawkes (olaamigoquepasa@.hotmail.com) writes:
> When we deploy applications, we have been using DSN's set up on the
> users systems. Then in the sqlconnection string, we go "dsn = xyz". I
> tried this with our new application, which is the first to be done
> with ADO.net and I get the following run time problem:
> "An exception 'System.ArgumentException' has occured in <Myapp>".
> I do the run time debugging and it tells me: "Keyword not supported:
> 'dsn'.
> For those who have migrated to .Net, how do you handle this issue? I
> mean, we are going to distribute this application, and our users will
> have different names for their servers, so how do we specify a data
> source dynamically.
> The way we have it for the moment is that we read the information from
> a config file. But it seems like there must be a better way. What
> happened to dsn?

If you despearately need DSN, I would suppose you could use OleDb
client rather than SqlClient.

As for what happened, I guess DSN got of fashion, and I can't say that
I miss it. Our application - which is VB6 - once used DSN, but now you
can specify server and database on the login form (and the values are
saved in registry between invocations), which I very much like. Of course,
end users normally use the same server and database, and it's only
developers like me, who change all the time. But nevertheless, DSNs
is just one more thing that has to be configured, and which could buy
settings you did not expect.

IF you don't want to prompt your users, a config file seems like a
good way to go.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland Sommarskog <esquel@.sommarskog.se> wrote in message news:<Xns952AF310B27FBYazorman@.127.0.0.1>...
> Ed Hawkes (olaamigoquepasa@.hotmail.com) writes:
> > When we deploy applications, we have been using DSN's set up on the
> > users systems. Then in the sqlconnection string, we go "dsn = xyz". I
> > tried this with our new application, which is the first to be done
> > with ADO.net and I get the following run time problem:
> > "An exception 'System.ArgumentException' has occured in <Myapp>".
> > I do the run time debugging and it tells me: "Keyword not supported:
> > 'dsn'.
> > For those who have migrated to .Net, how do you handle this issue? I
> > mean, we are going to distribute this application, and our users will
> > have different names for their servers, so how do we specify a data
> > source dynamically.
> > The way we have it for the moment is that we read the information from
> > a config file. But it seems like there must be a better way. What
> > happened to dsn?
> If you despearately need DSN, I would suppose you could use OleDb
> client rather than SqlClient.
> As for what happened, I guess DSN got of fashion, and I can't say that
> I miss it. Our application - which is VB6 - once used DSN, but now you
> can specify server and database on the login form (and the values are
> saved in registry between invocations), which I very much like. Of course,
> end users normally use the same server and database, and it's only
> developers like me, who change all the time. But nevertheless, DSNs
> is just one more thing that has to be configured, and which could buy
> settings you did not expect.
> IF you don't want to prompt your users, a config file seems like a
> good way to go.

Erland,
much obliged! I really appreciate the response, and this will help
move our project along. Thanks again.
Cheers,
Ed Hawkessql