views:

91

answers:

2

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

+2  A: 

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.

PurpleFlux
The output is complex and is in XML (or maybe a variant call will return XML?) This should work, but it'd probably be a lot of work.
Philip Kelley
Ah this is excellent, it's all there. From my first look I just need to parse the DefinedValues column in the result and parse out the columns involved in the query using the comma seaprator. And also I need to use the Type column which tells me the operation such as SELECT or DELETE.Thanks a lot
Gaz Newt
+1  A: 

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.

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.

Roland Bouman
You are absolutely right and I wish it was already like this. There is only one SQL login in the application I inherited, and the application manages users itself in the same database so it can apply application level permissions. Before I go with the SHOWPLAN solution I will look into whether I can assign roles to the sql user on the fly at application login (this is a web app). I can't get rid of the application level user system, so I might have to tether SQL logins to an application login. Thanks a lot Roland
Gaz Newt
Marked SHOWPLAN as solution for now, this may change
Gaz Newt
Fair enough Gaz Newt. I hope you manage to do what you need to do with the SHOWPLAN solution.
Roland Bouman