469,089 Members | 1,250 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,089 developers. It's quick & easy.

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
ol*************@nospamplease-hotmail.com
Jul 20 '05 #1
2 4171
Ed Hawkes (ol*************@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, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #2
Erland Sommarskog <es****@sommarskog.se> wrote in message news:<Xn**********************@127.0.0.1>...
Ed Hawkes (ol*************@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 Hawkes
Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Vai2000 | last post: by
3 posts views Thread by Carl Howarth | last post: by
1 post views Thread by James Goodman | last post: by
3 posts views Thread by Chris Rennert | last post: by
1 post views Thread by Brad Isaacs | last post: by
20 posts views Thread by fniles | last post: by
10 posts views Thread by =?Utf-8?B?UHVuaXQgS2F1cg==?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by kglaser89 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.