does a registry look up other than that they are about the same.<BR><BR><BR>the reason you MAY choose to use a DSNless connection is you do not have to bother creating the DSN on the web server.<BR><BR><BR>
DSN-less connections are a *TINY* bit faster. A very tiny bit.<BR><BR>DSN connections have the advantage that you can move the DB anyplace you want--even to another machine--and all you have to do is change the DSN. Your ASP code (or any code utilizing the DSN) changes not one iota.<BR><BR>DSN-less connections allow the ASP author to change things on the fly.<BR><BR>DSN's allow the system database admin to change things the way they *need* to be changed.<BR><BR>Short answer: I would *never* use a DSN-less connection to anything but an Access DB. Since other DB's are truly server based and the server could be moved at any time to any place on the network--and often is in any organization of more than a few people.<BR><BR>
If you are on a shared-site server, you might not have the option of using a DSN. I know that on the server my son uses they charge extra for adding a DSN, just for the human time involved. Some shared servers don't even allow DSNs, just because of the hassle.<BR><BR>But almost always, this applies to Access DBs. I think my answer stays the same for non-Access DBs.<BR><BR>
DSN's just add a step to the process. I think using DSN-Less is the way to go. It runs slightly faster, and when installing your code or script it is one less step of setup. Plus, if you only have remote access to your scripts, dsn-less is easier to change.
...a company with 30 servers on its web site.<BR><BR>Where the DB is moved around about once a month or more often.<BR><BR>And *then* see if you enjoy going and fixing up all the broken ASP pages that weren't using DSNs. <BR><BR>No thanks.<BR><BR>Yeah, if it's a tiny site. If it's a site using Access. If it's a shared-server site. But not for any site of any size.<BR><BR>