Microsoft Access ODBC连接：连接字符串差异

Question

Using the following:

• MS Access 2016, Office 365
• SQL Server 2012

I have 100+ SQL Server tables and views linked into an Access database via ODBC connection. All of these SQL Server objects are from two SQL Server databases that reside on the same server. All of these connections have been set up using the Access user interface and re-linked via the Linked Table Manager.

I've been experiencing a number of Access database issues lately, so I'm combing through everything with a fine-tooth comb. I noticed that the connection strings for all my SQL Server objects have a number of inconsistencies (see below). There does not seem to be any pattern in terms of when these objects where created and the format of the connection string either.

ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;  
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1  
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2  
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2  

Is it problematic that there are so many variations of the connection string? I've done some research (ie, Googling), but I don't much experience in this area of databases. Some connections have a "Network" specified, but others don't. Per connectionstrings.com ( https://www.connectionstrings.com/define-sql-server-network-protocol/ ), “Network=DBMSSOC” specifies a Winsock TCP/IP connection, which I believe is the appropriate choice for my network setup. Is it problematic that this parameter is excluded from several of the connection strings?

Answer 1

I would most certainly “harmonize” all of the linked tables to the same connection.

You can use the linked table manager to do this, but likely code is better.

You need to select all tables in the linked table manager, and MAKE sure you click on prompt for new location. This will force you to create (or select) an existing DSN. In fact, I would select all tables from the “one” given database, and then click on the “always” prompt for new location. When you do this, then all will posies the SAME link and connection string.

There are good number of reasons, one good reason is Access will cache the connection for you. So if you have “different” connections for the same database, you will have multiple caches of those connections. This likely will not affect performance “much”, but it still a good idea.

And if you are NOT using a trusted connection, then your connection strings in fact do NOT need to include the uid/password. (However, the cache of the uid/password requires exact string matches (minus the uid/password). In this approach, you can execute a “one time” logon on application start up, and then all linked tables (without the uid/password) will now work. However, you using trusted connections here, so this tip + issue don't matter.

In your example, you using trusted connections, so issues are “much” less of a worry or problem.

I also STRONG suggest that when you launch the ODBC manager from Access, that you ALWAYS but ALWAYS use a FILE dsn. The reason for this is that then Access will convert the connections to DSN-less for you.

This means that you can now deploy the front end application to any workstation, and you don't need to setup or have any DSN connection copied, or even setup on the workstation.

So I would in fact select all of the tables for one given database, (check the prompt for new location), and then create a FILE dsn (they are the default anyway). Once you link, then do the same for all the other tables that point to the other database. Again re-link.

The result will be a dsn-less connection, and thus your application will work on any workstation on the network, and do so without having to setup a dsn of any kind on each workstation.

So yes, you don't have to, but it seems over time, some tables were linked using a different DSN, they should be harmonized. And if you ever introduce some automatic linking code, you want to be able to distinguish between the two databases, and you code will have a rather difficult time doing this with a “hodge” podge of differing connections.

So you can use the linked table manger to harmonizing the connections – just ensure you select all tables from a single given database, and then re-link with a FILE dsn, the result will be a DSN less connection (access will ONLY use the DSN during the linking process – after that, access don't care, nor does it use or even look at the DSN, or even if it exists.

Having said all of the above, it not clear if this issue is related to your errors, or instabilities in your application. (a good idea is to always distribute a compiled version of your application - (a accDE as opposed to accDB).