在运行之前列出sql语句涉及的表？
在.NET中是否可以将一条sql语句传递给SQL Server进行解析并返回该语句涉及的表以及操作的类型。因此，对于这样的语句：
select * from Table1
left outer join Table2 on Table1.id=Table2.foreignid;
delete from Table2 where date < 2009/12/12
SQL Server 可能会像这样返回涉及的表：
Table1 Read
Table2 Read
Table2 Delete
因此该语句不会被执行，它只是返回涉及的表。
我问的原因是我正在处理的应用程序具有应用程序级别的表权限，我想逐个表地应用这些权限。当前解析语句中涉及的表的方法使用正则表达式，除了简单语句之外，其他任何方法都会失败。显然你不能真正使用正则表达式来完成这种工作
Is it possible, in .NET, to pass a sql statement to SQL server for parsing and return the tables involved in the statement and the type of operation. So for a statement like this :
select * from Table1
left outer join Table2 on Table1.id=Table2.foreignid;
delete from Table2 where date < 2009/12/12
SQL Server might return the tables involved like this :
Table1 Read
Table2 Read
Table2 Delete
So the statement isn't executed, it just returns the tables involved.
The reason I ask is that the application I am working on has application level table permissions that I want to apply on a table by table basis. The current method of parsing out the tables involved in a statement uses a regular expression and fails in anything other than simple statements. Obviously you can't really be using a regular expression for this kind of job
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SET SHOWPLAN_ALL 会帮您完成吗？它模拟服务器上的调用查询，您也许能够解析结果。
编辑：看起来 SET SHOWPLAN_TEXT 会更容易解析。
Would SET SHOWPLAN_ALL do it for you? It simulates the call query on the server and you may be able to parse the results.
Edit: It looks like SET SHOWPLAN_TEXT would be easier to parse.
在我看来，您应该创建一个数据库级别角色来捕获这些权限，并将它们应用到该级别。您为数据库管理系统付费 - 不要花时间编码现有解决方案可以最好地完成的工作。
应用程序级别权限可能在行级别有意义，甚至可以在数据库中实现。但如果它们是在桌面级别，我看不出有任何借口可以证明您自己执行编码是合理的。使用您的数据库，您已付费。
It seems to me you should create a database level role to capture those permissions, and apply them on that level. You paid for your database management system - don't spend your time coding what is best done by a solution that's already in place.
Application level permissions may make sense on the row level, and even those can be implemented at the database. But if they are on the table level, I don't see any excuse that justifies coding enforcement yourself. Use your database, you paid for it.