Re: ConnectionString using DSN not working
- From: "William \(Bill\) Vaughn" <billvaRemoveThis@xxxxxxxxx>
- Date: Sun, 22 Apr 2007 17:58:45 -0500
Over the years application designers have tried to create generic
applications that can work regardless of which backend database engine is
accessed. This assumes that each DBMS is the same--supports the same SQL
dialect (or at least a common subset), other functionality, admin processes,
connection strategies and other aspects. For the most part they don't. For
example, Oracle, SQL Server and JET all use different approaches to stored
procedures and SQL. All have different admin functions (like backup,
restore, user account management, security), different performance tuning
approaches and on and on.
This means that when you use an "OSFA" (one-size-fits-all) generic interface
like ODBC or OLE DB (and there are others) you must go to great lengths to
take advantage of the specific features you pay for when you buy SQL Server
or other SQL engines.
When you use SqlClient or OracleClient your code talks directly to the SQL
Server-specific TDS data stream or the Oracle-specific data stream.
Performance of ODBC and OLE DB is not nearly as good nor as flexible. If you
want to access all of the features of any serious DBMS engine, you can't
depend on ODBC or OLE DB to expose them.
Using SqlClient or other provider-specific interface, changing the
connection string to address the new targeted DBMS is something that can and
is done quite often as long as you design in the approach. Yes, the
TableAdapter and other wizards don't make this easy, but it can be done.
Consider that the application properties are accessible via code--they
include the connection string used to access the DBMS. As long as the schema
and rights of the target DBMS match the development system your application
should work fine.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
"Fendi Baba" <effendi@xxxxxxxxxxxxxx> wrote in message
news:1177212508.584011.106300@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thank everyone. One of the concern we have is the fact that using not
using ODBC means connecting to te server direct. This works out nicely
for development environment but when we move to production where the
database server is in a server famr, we have to change the config file
to change to the server accordingly. Is there a way we can "make" this
server change automated? My administrators would definitely appreciate
that.
Regards
.
- References:
- ConnectionString using DSN not working
- From: Fendi Baba
- Re: ConnectionString using DSN not working
- From: Mary Chipman [MSFT]
- Re: ConnectionString using DSN not working
- From: Fendi Baba
- Re: ConnectionString using DSN not working
- From: Paul Clement
- Re: ConnectionString using DSN not working
- From: Fendi Baba
- Re: ConnectionString using DSN not working
- From: Paul Clement
- Re: ConnectionString using DSN not working
- From: William \(Bill\) Vaughn
- Re: ConnectionString using DSN not working
- From: Paul Clement
- Re: ConnectionString using DSN not working
- From: Fendi Baba
- ConnectionString using DSN not working
- Prev by Date: Re: Anyone know where I can get a Postal Job?
- Next by Date: Forms and Labels
- Previous by thread: Re: ConnectionString using DSN not working
- Next by thread: SQL issue with spaces in source name
- Index(es):
Relevant Pages
|