How do I get ms-access to connect to ms-sql as a different user?

Question

How do I get ms-access to connect (through ODBC) to an ms-sql database as a different user than their Active Directory ID?

I don\'t want to specify an account in th

Answer 1

@Philippe
I assume that you are using the word admit as being roughly equivalent to understand or perhaps agree; as opposed to the opposite of deny.

I understand the implications of having all the users login to the database using one ID and password (and having them stored in the application). That to me is a smaller risk than the problem I'm facing right now.
@off

Some more background to the problem: I have ODBC connections set up on each of the users workstations using Windwos NT authentication. Most of the time the users connect using an MDE setup to use that ODBC connection - in this case they ALWAYS have the ability to add/update/delete data.

The problem comes that some of the users are educated enough about MS-Access to create a new mdb and link it to the MS-SQL server. They can then edit the data right within the tables rather than going through the application which does a certain amount of validation and hand holding. And they like doing this, but sometimes the mess it up and cause me problems.

Answer 2

I think you can get this to work the way you want it to if you use an "ODBC DSN-LESS connection"

If you need to, keep your ODBC DSN's on your users' machines using windows authentication. Give your users read-only access to your database. (If they create a new mdb file and link the tables they'll only be able to read the data.)

Create a SQL Login which has read/write permission to your database.

Write a VBA routine which loops over your linked tables and resets the connection to use you SQL Login but be sure to use the "DSN-Less" syntax.

"ODBC;Driver={SQL Native Client};" &
       "Server=MyServerName;" & _
       "Database=myDatabaseName;" & _
       "Uid=myUsername;" & _
       "Pwd=myPassword"

Call this routine as part of your startup code.

A couple of notes about this approach:

• Access seems to have an issue with the connection info once you change from Read/Write to Read Only and try going back to Read/Write without closing and re-opening the database (mde/mdb) file. If you can change this once at startup to Read/Write and not change it during the session this solution should work.

• By using a DSN - Less connection you are able to hide the credentials from the user in code (assuming you're giving them an mde file you should be ok). Normally hard-coding connection strings isn't a good idea, but since you're dealing with an in-house app you should be ok with this approach.

Answer 3

What I was hoping to do (which I just experimented with) was to refresh the links to the database something like this for each table (Note: I've switched the ODCB connection to SQL Server authentication for this experiment, and added the accounts to the SQL server as well: readonly - which can't to any updates, and readwrite - which has full privileges on the table).

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readonly;" & _
                "PWD=readonly_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

this stops them from editing, but I can't get a later readwrite to work

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readwrite;" & _
                "PWD=readwrite_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

It seems that whichever permission I connect with first, sticks permenantly. If I started readwrite and then go to readonly, the table remains with the readwrite privileges

Answer 4

I think you'd have to launch the MS Access process under the account you want to use to connect. There are various tools that let you do this, such as CPAU. This tool will let you encrypt the password as well.

Answer 5

Why not use integrated/windows security. You can grant an active directory group the rights you want the users and then add the users accounts to that group. I believe you can also use sql server's roles feature in addition to this to limit functionality based on the client application being used.

Answer 6

We admit here that you are using an ODBC connexion to your database with Integrated Security on, so that you do not have/do not want to write a username/pasword value in the connexion string (which is according to me the right choice).

In this case, there is fortunately no way to "simulate" another user when connecting to the data. Admit with me that being able to make such a thing would be a huge break in integrated security!

I understood from your previous post that you wanted users to be able to update the data or not depending on the client interface they use. According to me, the idea would be to create for each table a linked 'not updatable' view. Let's say that for each table called Table_Blablabla you create a view (=query in Access) called View_Table_Blablabla ...).

When using Access, you can then decide at runtime wether you want to open the updatable table or the read-only view. This can be done for example at runtime, in the form_Open event, by setting the form recordsource either to the table or the view.