[AccessD] Linked to SQL Server in a domain

Jim,

Thanks for that info.  This is a small enough office that I (and the owner) does not think that the 
employees are a worry.  If they end up doing stuff outside of the application we can deal with that.

John W. Colby
www.ColbyConsulting.com


Jim Dettman wrote:
>   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.
>