Jim Dettman
jimdettman at verizon.net
Fri May 22 08:49:18 CDT 2009
Just one drawback to creating a DSN; once on the machine, users find out that they can then use it to access the data form Excel, etc. Opens things up a bit, which you might not want. And like you, I find that ODBC works perfectly fine. Once again, it's a matter of understanding what the product is doing. In most cases, I find poor ODBC performance is related to using JET specific expressions in queries, which then causes most of the processing to be carried out client side. Last, for John, with ODBC, when you attempt a connection, ODBC is only worried about the connection string. A DSN is nothing more then a shortcut way of providing that. You don't need a DSN if you supply all the required information. Anything that is not supplied when you attempt a connect is prompted for. A DSN can be user specific, system based (applies to the entire PC), or file based. As the others have said, lots of code floating around to create them if you want to use them. Just be aware that once defined, the end use can then use that to connect to the DB outside of your app. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, May 22, 2009 4:31 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Linked to SQL Server in a domain Hi John A DSN can be created either as an Registry entry (which may be duplicated in the ODBC.INI file for the benefit of 16-bit apps, but let's forget that) or as a DSN file - in both cases either for the User or the System. The DSN file is nothing more than a text file given the extension .dsn and can easily be moved. However, on another machine you still need to create a DSN for the database but, by referring to the file, no parameters need to be typed. If no DSN file is available, a new DSN must be created from scratch. Alternatively, a DSN can be created by code. This is probably not worth the efforts for a single user, but if you prefer this method I have extensive code for the purpose. Finally, a DNS-less connection can be made as explained in the article. I find this method a bit over-hyped, one reason could be that many can't find out how to create a DSN. It is not the answer to everything but is well suited in some situations - as always, it depends. As you can see in the code in the article, it is just another method to pass the same information as contained in a DSN. /gustav >>> jwcolby at colbyconsulting.com 22-05-2009 00:47 >>> Guys, I am a tad out of my comfort zone here. I am working on a database that links to a SQL Server using ODBC. The database was "upgraded" by another company which is in the process of being fired. The links work but I do not know where the DSN file resides. I created a new database and a DSN for new tables that I created in that database and it works just fine for me, logged on to the server (which is where I work - remote desktop), but it does not work for another user that I have helping me test. Those new links to the new table gives an ODBC error when she just tries to open the tables directly in the table tab of the db window. I am assuming that is because the DSN file I used to do the link is not on her computer? Is that the way this works? How do I discover where the DSN file is for the database that existed already when I first got in? I tried looking at the TDF cnn data and it isn't referenced in there. I found this: http://support.microsoft.com/kb/892490 Which looks like the magic key. Does anyone use this code or something similar? Any comments, warnings? Unfortunately at this point I am not able to log in to any other workstation there to test this code from another workstation. I will have to get that figured out as well. Any help appreciated. -- John W. Colby www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com