如何让 ms-access 以其他用户身份连接到 ms-sql?

发布于 2024-07-05 17:12:47 字数 298 浏览 4 评论 0原文

如何让 ms-access 以与其 Active Directory ID 不同的用户身份连接(通过 ODBC)到 ms-sql 数据库?

我不想在 ODBC 连接中指定帐户,我想在 ms-access 端执行此操作以对用户隐藏它。 在 ODBC 连接中执行此操作将使我立即回到我试图避免的原始情况。

是的,这与之前的问题有关:http://www.stackoverflow.com/questions/50164/

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 the ODBC connection, I want to do it on the ms-access side to hide it from my users. Doing it in the ODBC connection would put me right back in to the original situation I'm trying to avoid.

Yes, this relates to a previous question: http://www.stackoverflow.com/questions/50164/

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

蝶…霜飞 2024-07-12 17:12:47

我认为如果您使用 " ,您可以让它按照您想要的方式工作ODBC DSN-LESS 连接”

如果需要,请使用 Windows 身份验证将 ODBC DSN 保留在用户的计算机上。 授予您的用户对数据库的只读访问权限。 (如果他们创建一个新的 mdb 文件并链接表,他们将只能读取数据。)

创建一个对数据库具有读/写权限的 SQL 登录名。

编写一个 VBA 例程,循环遍历链接表并重置连接以使用 SQL 登录,但请务必使用“DSN-Less”语法。

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

将此例程作为启动代码的一部分调用。

关于此方法的一些注意事项:

  • 一旦您从读/写更改为只读,并尝试返回读/写而不关闭并重新启动,Access 似乎存在连接信息问题。 -打开数据库(mde/mdb)文件。 如果您可以在启动时将其更改为读/写,并且在会话期间不更改它,则此解决方案应该有效。

  • 通过使用 DSN - Less 连接,您可以在代码中向用户隐藏凭据(假设您向他们提供 mde 文件,应该没问题)。 通常,硬编码连接字符串不是一个好主意,但由于您正在处理内部应用程序,因此您应该可以接受这种方法。

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.

暮倦 2024-07-12 17:12:47

我认为您必须在要用于连接的帐户下启动 MS Access 进程。 有多种工具可以让您执行此操作,例如 CPAU。 该工具还可以让您加密密码。

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.

若能看破又如何 2024-07-12 17:12:47

我们在这里承认您正在使用 ODBC 连接到数据库并启用集成安全性,因此您没有/不想在连接字符串中写入用户名/密码值(根据我的说法,这是正确的选择)。

在这种情况下,幸运的是,在连接数据时无法“模拟”另一个用户。 跟我一起承认,能够做出这样的事情将是集成安全方面的巨大突破!

我从您之前的帖子中了解到,您希望用户能够更新或不更新数据,具体取决于他们使用的客户端界面。 据我所知,这个想法是为每个表创建一个链接的“不可更新”视图。 假设为每个名为 Table_Blablabla 的表创建一个名为 View_Table_Blablabla ...)的视图(=Access 中的查询)。

使用 Access 时,您可以在运行时决定是要打开可更新表还是只读视图。 例如,可以在运行时在 form_Open 事件中通过将表单记录源设置为表或视图来完成。

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.

凉墨 2024-07-12 17:12:47

@菲利普
我假设您使用的“承认”一词大致相当于“理解”或“同意”; 与拒绝相反。

我理解让所有用户使用一个 ID 和密码登录数据库(并将它们存储在应用程序中)的含义。 对我来说,这比我现在面临的问题风险更小。
@off

这个问题的更多背景:
我使用 Windwos NT 身份验证在每个用户工作站上设置了 ODBC 连接。 大多数时候,用户使用 MDE 设置进行连接以使用 ODBC 连接 - 在这种情况下,他们始终能够添加/更新/删除数据。

问题是,一些用户接受了足够的 MS-Access 教育,可以创建新的 mdb 并将其链接到 MS-SQL 服务器。 然后,他们可以直接在表中编辑数据,而不是通过执行一定量的验证和手动操作的应用程序。 他们喜欢这样做,但有时会把事情搞砸并给我带来麻烦。

@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.

倥絔 2024-07-12 17:12:47

我希望做的(我刚刚尝试过的)是为每个表刷新到数据库的链接,就像这样(注意:在本实验中,我已将 ODCB 连接切换到 SQL Server 身份验证,并将帐户添加到SQL 服务器也是如此:只读 - 不能进行任何更新,读写 - 对表具有完全权限)。

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

这阻止了他们编辑,但我无法让以后的读写工作

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

似乎无论我首先连接哪个权限,都会永久保留。 如果我开始读写然后转到只读,则该表仍具有读写权限

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

海风掠过北极光 2024-07-12 17:12:47

为什么不使用集成/Windows 安全性。 您可以向 Active Directory 组授予您想要的用户权限,然后将用户帐户添加到该组。 我相信除此之外,您还可以使用 sql server 的角色功能来根据所使用的客户端应用程序来限制功能。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文