[thelist] Pros and Cons of a DSN connection x a DSN-less?

Scott Dexter sgd at ti3.com
Thu Feb 28 11:34:01 CST 2002


>
> >Keep the DSN-less connection code in a file. Keep that file
> below the
> >site root. Then, the only way they can get at that information

> A little bit of confusion here. I thought that a DSN-less
> connection was one that does not use DSN. Not one that uses
> DSN information stored on a file. Wouldn't that be like using
> DSN? Here is an example of a DSN-less connection string :
>

What he's talking about is putting that connection string in a file
that's away from your web files, and read it at app init time. A measure
of security. We (work) do that here, keep DB connection settings (db,
server, uid, pwd, etc) in a .ini file that is not in the web server
root, and use a COM object to read in the settings and build the
connection string when the application starts. This buys us a few
things: 1) it gets the connection information away from the ASP code,
which is a good thing for security reasons, 2) it allows us to flip-flop
dbs, db servers, what have you by just changing the .ini file, and 3)
makes it a breeze to develop against, because when we move the site to
production we just change the .ini file and the db settings are cool.

Though, having a file-DSN (system and machine DSNs are kept in the
registry, btw) isn't much different, really. We find the .ini files
easier to manage and keep track of.

But I'm rambling...

sgd



More information about the thelist mailing list