Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
SamC
White Water Yakist
3467 Posts |
 Posted - 2003-12-17 : 11:39:49
|
| I'm installing an application that uses SQL 2000, and it gives me an option of using a DSN connection or a DSN-less connection.Any performance benefit of going DNS-less?Sam |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2003-12-17 : 12:12:08
|
| From what I've read in the past yes, there are some performance advantages, but they are not make or break differences. For a developer, DSN-less connections give you better performance and easier to maintain connection strings vs DSN connections.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-12-17 : 12:16:50
|
| DSN-less! If you've ever had to work on a system with DSNs, you'll know what a pain in the neck they are. Connection strings are so much easier.Tara |
|
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2003-12-17 : 15:28:51
|
| I'm thinking avoid DSN's myself.My vendor says they're easy and don't have any performance penalty.What's up with that?Sam |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-12-17 : 16:22:06
|
| Easy is relative. Easy for him, yes. Easy for the person that has to support it, no. Well easy is the wrong word anyway, they're just a pain in the a$s.Tara |
|
|
|
Granick
Starting Member
46 Posts |
Posted - 2003-12-17 : 17:42:12
|
| I haven't done a bunch of testing to check performance between using and not using a DSN. I have however had to make extensive modifications to an application that uses DSNs, and it can be a real nightmare when you are trying to figure out what the DSN on the remote machine is hooking to, with what login, etc. Makes troubleshooting a LOT harder. The only benefit that I can see to using a DSN would be that you could switch datasources, without having to recompile, as many people embed their connections into their application. With .Net, and even older dev environments, you have a few options of where you can store the Connection String so you don't have to re-compile when/if you change data sources. So I haven't found a good reason to use a DSN yet. Although I have to admit, I am not really looking for a good reason. :)Shannon |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-12-18 : 08:53:22
|
| I'm definitely a non-DSN person, the moment I found out I didn't have to use them I dumped them forever (almost...stupid ODBC apps still need them) I agree that there might be 1 or 2 times where switching the datasource inside the DSN could be helpful, but so far I've never had a situation where DSN-less didn't work out anyway. Most of the advice on connection strings has been to store it somewhere accessible to the program, instead of hard-coding it, so that usually makes it painless to change them. |
|
|
|
mohdowais
Sheikh of Yak Knowledge
1456 Posts |
Posted - 2003-12-18 : 09:19:57
|
Non-DSN definitely. Oh, by the way, did you know that you dont have to physically create a DSN, you could still do that inside a connection string using MSDASQL (MS driver for ODBC) as a provider instead of OLEDB? So in case you *have* to have an ODBC connection, like I do currently for a legacy app, you can still maintain the parameters a global connection string. Before I learnt I could do that, I had spent a few thousand hours begging for physical or terminal access to the server so that I could change the DSN.  btw, I did see some code breaking when I moved an application from ODBC to OLEDB, much of that had to do with changes to recordset behaviour and changes in calls to stored procedures. But there *was* a perfomance gain to make up for it.OwaisWe make a living out of what we get, but we make a life out of what we give. |
|
|
|
|
|
|
|
|
DSN connection