To answer this question in the comments:
I can create methods with the correct parameters, but I'm struggling
to find where the objects are in the model are that represent the
content of a stored procedure. I need to know the columns returned by
a SELECT statement in order to generate the return objects. Any ideas?
The referenced objects are provided by the TSqlProcedure.BodyDependencies relationship. That will return objects referenced in the stored proc body, but won't tell you how they are used. The relational model doesn't try to embed this info as it doesn't help in deployment, but you can get it by querying the SQLDOM AST for the procedure.
The AST is a syntax tree defining the actual structure of the Procedure statement, including the structure of the procedur body. What you need to do is:
- Create a Visitor that visits SelectStatement nodes (or their children)
- Find the column names used in the select
- Map these names to names of objects returned by TSqlProcedure.BodyDependencies. Now you have a rich object that can state the table the column is contained in, the column's data type, etc.
- Do whatever you need to based on this (for example define a return type with the correct properties matching the column data types?)
A few notes / resources:
- Ed's DacpacExplorer will help you view and understand the code.
- Dave Ballantyne just added SQLDOM support to DacpacExplorer. Not only will this help you see what statements you need to match in the visitor, you should also look at how they use loadAsScriptBackedModel (see this commit) to ensure you have the full AST for the procedure body. Without this you would just get the body as one SqlScript object which isn't much use to you.
- Further examples of the visitor pattern are Dave's TSqlSmells and the DacExtensions project
- Twitter is an easy way to contact Ed, Dave and me if you are blocked :-)