March 3, 2009 at 3:11 pm
unless you're using Access 2000 or earlier - you really should be using OLEDB and not ODBC. In addition, you should probably look at your OLE DB connection string and ensure that it's using the currently logged in user (through Trused Connection=True in the config file.)
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 3, 2009 at 3:19 pm
Continuing along this line, you might want to look at Access Data Projects.
This is how you can effectively use OLE DB on a SQL Server Database. This is only available in Access 2000 and higher.
Nelson
March 4, 2009 at 12:32 pm
Ok...I did some reading last night, and since I didn't know anything about Access Data Projects, I figured I better find out. (Boy was I embarrassed when I discovered that it has been under my nose all these years)
Anyway...I blew away all the permissions on the Sql Server....and connected to the table in Access Data Project using NT Authentication and did the standard hookup to the sql server.
Unfortunately, a user, who wasn't even in the users list, was able to modify the data.
So, I started over, created a blank Project, connected to the sql database via OLE DB for Sql Server......and had the same user try to modify the data.
When he opened the project, he got a warning that the database was Read-Only....But he STILL was allowed to modify all the data in the table!
I looked for the connection string, but really don't know where to look....not to mention that the linked table wizard creates a query...not a table.
Feeling a little defeated this afternoon. But thanks to all of you for your help.
March 5, 2009 at 8:41 am
Aha!!! It seems that I have located the problem.
Years ago, we had an outside consultant design a Laboratory Management System. (A web app that ran on the sql server.)
When he was developing it, he created a Group that had full System Administration server role rights, and put a handful of users in that group. This was so he could troubleshoot in the early stages of development.
Anyway...it looks like he didn't delete the Group....so no matter what I did....the select users that I was using as a test group, were able to alter data without permissions.
(It was pure coincidence that the users I chose...were also within that special group from years ago)
I deleted the group out of the server role...and Viola!! I have control of the fields. Whew!
Thanks again for all your help. It was not a total loss, as my education has increased dramatically due to this exercise.
Thanks again
John
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply