我的客户端已经使用Microsoft Access 2010很长一段时间了，他们收到了一些安全审核要求。他们正在使用链接表方法连接到Microsoft SQL Server 2012 Express。
要求规定必须记录针对数据的所有操作。(INSERT、UPDATE、DELETE和SELECT语句)
对于INSERT、UPDATE、DELETE语句，我可以创建一个触发器来记录更改。
问题是围绕SELECT语句的审计。如果数据是只读的，我可以使用一个存储过程来记录查询。但是执行存储过程会使记录集不可更新。
有人知道如何应对这一挑战吗？
我对很多策略持开放态度。。。(通过web服务连接到SQL的访问，任何…)
需要注意的是，我的客户没有3万美元可以花在SQL Sever的企业版上，因为他们是一家员工少于10人的小企业。
从理论上讲，无论数据是否只读，都可以将所有访问权限限制为仅使用存储过程。编写存储过程，首先将审核信息写入日志，然后执行其他需要执行的操作——SELECT、INSERT等。
实际上，您可能无法做到这一点。这取决于访问数据库的应用程序。将所有访问权限限制为仅使用存储过程可能会破坏预期会发生其他事情的应用程序。(如果您只切换到存储过程，RubyonRails应用程序将如何响应？)
一个让你的数据库无法使用的防弹审计系统不是很好；完全关闭数据库服务器更简单、更便宜。
您可以升级到支持SQL Server探查器的SQL Server版本。另一种选择是让其他工具进行审计，例如sql审计。
您可以打开JET showplan。这将记录Access使用的所有查询。
http://www.techrepublic.com/article/use-microsoft-jets-showplan-to-write-more-efficient-queries/?siu-集装箱
正如我在评论中指出的，除非每个表单都使用where子句打开，该子句将查看该表单中的数据限制为一条记录，否则你真的在欺骗审计要求。如果你不这样做，那么打开到链接表的窗体可能有1000条记录，用户点击ctrl-f找到并跳转到一条记录意味着SELECT语句告诉你用户实际看到的内容为零。因此，当你可以打开放映计划时，除非对应用程序设计进行更改以将表单限制为一条记录，否则审计概念不会告诉您用户实际查看的内容。公平地说，事实上，我99%的应用程序都通过where子句打开并限制主编辑表单为一条记录。
因此，虽然你可以按照上面的技术记录所有SELECT命令，但它并不是真正的日志，因为这样的日志对确定用户查看的实际记录没有任何用处