Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

MS SQL

Posted Feb 8, 2001

More DSN Trivia!

By Andy Warren

I've gathered a few more interesting bits of information about DSN's that I'd like to share with you this week:

  • From Swynk reader Rod Burke: Basically, if you set the system dsn (not file dsn, and I haven't tried user dsn) to be non-trusted, this property is ignored when the DSN is used later. Seems to apply only to applications which pop up a login dialog ... i.e. not those which supply a username/password in the connection string or similar. If you expect Access, for example, to present a dialog for username password on a non-trusted connection to SQL Server, it will first complain about the trusted connection attempt failing. It's documented at http://support.microsoft.com/support/kb/articles/Q279/5/26.asp. (Added Feb 15, 2001)
  • From Swynk reader and good friend Matt Owen: You might want to consider specifying a complete path to your file DSN's. By providing the path you don't have to check that someone has changed the default folder. You can just use the application folder where your executable is stored, or keep your DSN's in a file share with a fully qualified UNC.
  • Simon Clark wrote to mention that using a DSN or UDL could possibly degrade performance if you open and close a connection a lot - due to the disk/registry reads involved to get the connection info. I can see in some situations that it would make sense to cache the connection information to save hitting the disk over and over, a perfect use for a dsnless connection where you load the connect string at startup and use it for the entire session. Overall I still prefer UDL's as they are more easily maintained.
  • Did you know that you can have a File DSN that points to a System DSN? Why would you want to? As best I can tell from researching MSDN this was a fix for MS Query, which in it's earlier versions could only see File DSN's. It's pretty simple, just one line: [ODBC]DSN=SystemDSNName. PLEASE try not to find a use for this one!
  • That the version of MS Query shipped as part of Office 2000 supports DSN's, but I can't find a way to get it to use a UDL or a connection string? It does support OLAP cubes, so I guess it's not all bad!
  • I've posted an update to my DSNGen utility. Allan Mitchell reported the first (and only so far!) bug  - while creating a file DSN, if the server name was "(local)" and the user selected the ServerName as Prefix option, the resulting DSN would not show up in the ODBC applet (the DSN would be created as (LOCAL)_dbname.DSN). If you haven't done so already, take a look at it. 

If you're new to DSN's, take a look at my previous articles DSN's - What are they?, DSN, DSN-Less, or UDL?, and DSNGen - Another Tool for the Toolbox. If you've got another tip or comment about DSN's or UDL's, please email me. 



MS SQL Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
MS SQL Forum
Topic By Replies Updated
SQL 2005: SSIS: Error using SQL Server credentials poverty 3 August 17th, 07:43 AM
Need help changing table contents nkawtg 1 August 17th, 03:02 AM
SQL Server Memory confifuration bhosalenarayan 2 August 14th, 05:33 AM
SQL Server Primary Key and a Unique Key katty.jonh 2 July 25th, 10:36 AM