UDL Files

  • Thread starter Thread starter Philip Townsend
  • Start date Start date
P

Philip Townsend

Has anyone used UDL files with C#.net? I have not done this before and
have always used the normal connection string, but have been asked to
research this. Does anyone have an example? Are there any disadvantages
to doing it this way? Does the UDL method still take advantage of
connection pooling? Thanks!
 
Hello Philip,

It's actually easy.

You create an empty file in any editor and name it, say, "MyConnection.udl".
Then double-click on this file in Windows Explorer to bring up the Data Link
Properties window and set up necessary connection parameters. Then use the
"Test Connection" button to ensure the connection has been properly
configured.

Next, construct a connection string like this:

"File Name = e:\MyConnection.udl" (not sure this is enough for ADO .NET
though, worked like a charm with ADO)

and you are done.

Connection pooling should work as usual.
 
One more addition - seems that with ADO .NET, UDLs can be used with the
OLEDB managed provider, but not with the MSSQL managed provider.
 
Philip Townsend said:
Has anyone used UDL files with C#.net? I have not done this before and
have always used the normal connection string, but have been asked to
research this. Does anyone have an example? Are there any disadvantages
to doing it this way? Does the UDL method still take advantage of
connection pooling? Thanks!
Click to expand...

In addition to Mr. Lapshin's comments I would like to add the following
amplification.
UDL files were originally the OLE DB equivalent of an ODBC (.dsn) file. The
only difference was, where as you had to go into the ODBC admin to create a
..dsn (actually you could do it by scratch - but why?), with a .udl the
wizard opened automatically when opening an .udl file - thereby removing the
need for an additional .cpl file in settings.

Such files and the accompanying wizards were helpful to create connection
strings and made it easier for new programmers. They were also handy to pass
around "connection information" in little xcopy'ble files and made it very
easy to modify connection information outside of the application. (It was
not uncommon to have a "testdb.udl" and a "productiondb.udl".) This become
less interesting with the advent of connection.open calls that took full
connection strings and as programmers became more familiar with connection
string syntax.

However, both files are plain accii text with well-documented structures and
in the "clear" so to speak, so they do present a possible security risk. For
this reason mainly, M$ has tended to down-grade the use of these external
files.

UDL, by definition, works with OLE DB, but not the newer ADO.NET specific db
drivers, just as they are inappropriate for use with ODBC providers. (This
last statement gets kind of confusing since you can use OLE DB ODBC
drivers.)

Unless there is no serious security problem having an open file, or a real
need to change out access to multiple databases (on the fly), or no reason
to use the newer ADO.NET providers there is little reason to use UDLs or
DSNs.

The single exception is that they are a create development tool to quickly
create connection strings and 'test' connections.

-ralph
 
Back
Top