> 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?

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.