I just came across the system view sys.sql_modules today. What is a module versus a DB object? The view returns, most prominently, a column containing the definition text, as returned by sys.syscomments.
A module, in SQL-Server-speak is a stand-alone object that contains sql batches, such as a view, table valued function, stored procedure, trigger or scalar function. A SQL object is a more all-encompassing term that includes some that contain SQL Expressions, such as check or default constraints. A module used to be referred to as a 'routine' before SQL Server 2005, but I think the two terms are used interchangeably.
The table build script is not stored in SQL Server because of the ease with which components of a table can be altered separately. Therefore it is treated as an object but not a module.
Typical objects that aren't also considered to be modules are system tables, default constraints, foreign key constraints, service queues, check constraints, user tables, primary key constraints, internal tables and unique constraints.
Columns aren't considered to be objects. Neither are indexes.
Yes, it is all more complex than one might first think.
It's the blocks of T-SQL statements that make up a stored procedure, a stored function, a trigger or a view definition.
From "Books Online" in the "CREATE PROCEDURE" section:
Getting Information About Stored
Procedures To display the definition
of a Transact-SQL stored procedure,
use the sys.sql_modules catalog view
in the database in which the procedure
exists.
In sys.sql_modules, you'll find the actual T-SQL code.
Marc
A modules are functions, procedures, queues, and triggers. These Modules call Objects. That's what I understood from this article which describes "EXECUTE AS":
EXECUTE AS
I came across to this question when I wanted to get detailed explanation of EXECUTE command. I wanted to have deep understanding how to read t-sql help of command and realized that I haven't known what module means.
I just want to add these these to the list of sql modules:
system stored procedure,
user-defined stored procedure,
CLR stored procedure,
scalar-valued user-defined function,
or extended stored procedure.
Executes a command string or character string within a Transact-SQL batch, or one of the following modules: system stored procedure, user-defined stored procedure, CLR stored procedure, scalar-valued user-defined function, or extended stored procedure. The EXECUTE statement can be used to send pass-through commands to linked servers. Additionally, the context in which a string or command is executed can be explicitly set. Metadata for the result set can be defined by using the WITH RESULT SETS options.
https://learn.microsoft.com/en-us/sql/t-sql/language-elements/execute-transact-sql?view=sql-server-2017
Related
I want to get list of Objects referenced in Snowflake Procedure , let us say It is using Tables, Views Inside it , I want to find those items from Procedure definition , as currently there is no function in Snowflake that can provide this information.
GET_OBJECT_REFERENCES https://docs.snowflake.com/en/sql-reference/functions/get_object_references.html is function now only available for Views and not for Procedure.
Any pointers in scanning the definition of Procedure and figure out objects in it.
As Felipe pointed out, you can pass the name of a table or view as a parameter into the stored procedure. In that case there's no way to know what objects the SP will reference.
If your organization tends not to do that; if your SQL in stored procedures tends to be more along the lines of "select * from my_table" you can simply search for those references in the stored procedure code.
The following statement is crude, but effective. It could be developed and polished a lot, and it could miss references. It also only finds the first match, while a more useful query would return all and flatten out the array. I may have time to work on that a bit. It did find a lot in my test. It simply looks for the following pattern:
SQL Command ... Matching Clause for that Command ... Semicolon
The reason this works is that even if you don't terminate the SQL in the stored procedure, the JavaScript line should be terminated with a semicolon. JavaScript is comparatively forgiving of missing semicolons, but it should hit one eventually and match the SQL statement.
select PROCEDURE_CATALOG
,PROCEDURE_SCHEMA
,PROCEDURE_NAME
,ARGUMENT_SIGNATURE
,regexp_substr(PROCEDURE_DEFINITION, 'SELECT\\s.*FROM.*;|INSERT\\s.*INTO.*;|UPDATE\\s.*SET.*;|MERGE\\s.*INTO.*;|DELETE\\s.*FROM.*;|MERGE\\s.*USING.*;',1, 1, 'ims') STATEMENT
from MY_DATABASE.INFORMATION_SCHEMA.PROCEDURES
where STATEMENT is not null;
I write a lot of stored procedures, and to Felipe's point this returns a lot of rows like this for me:
select ${params.leftColumnList} from ${params.leftObject} order by ${leftTimestamp};`);
In those cases, you'd need to have someone who can read code figure out what it's referencing. In this case, the SP accepts parameters for those fields, so they could be any tables.
Why script generated by SSMS shown in red is different from script stored in system tables. Please notice stored procedure names in query, query result and Object explorer.
i.e.
All these methods are giving me same script
sql_module
object_definition
sp_helptext
However when generated from SSMS, right click -> script as Create or Modify is giving a different script.
How is it possible and generating different scripts.
The answer can be confusing.
The Stored procedure getBudgets4programManager2 was renamed (very likely using sp_rename https://msdn.microsoft.com/en-us/library/ms188351.aspx), so the original definition does not match the new name. BTW. Notice that the definition stored in metadata will always change the DDL command to CREATE in case of issuing an ALTER PROCEDURE statement.
At the same time, SSMS scripting features will not simply get the definition from metadata as it has an object representation of the stored procedure, it will normalize the schema name & object name, and it may also normalize the DDL command accordingly (CREATE/ALTER). Notice that the schema is showing it is normalized (i.e. [dbo]), and that the current name is also normalized.
As for why the metadata definition is not renamed at the same time you rename the object. The answer is not 100% clear, but such change would affect any features in the SQL Server engine that relies on the definition, including using the WITH ENCRYPTION option on ALTER/CREATE PROCEDURE as well as the verification of digital signatures.
As far as I know, other elements in both versions of the scripts should remain intact (comments, blank spaces, etc.).
I hope this information helps.
Is there a way to list in Sql Server all the jobs which operate on a mentioned Sql Server object, for example a certain table (directly or indirectly through a stored procedure for example)?
An example: I am interested in a certain table or view, so if there is a job which invokes (in any step) a procedure, which in its turn does any operation on that table/view (like insert or select or update etc), I'd like to see it listed.
Side note: sp_depends seems to list only the procedures and functions, but not the jobs.
There is no built-in way to find indirect dependencies. You can check which jobs directly call a certain stored procedure, but no way to see which tables or other objects get used by that stored procedure unless you check the direct dependencies of that stored procedure.
So if you are looking for a specific table, you can find objects that reference it directly, but not objects that reference THOSE objects (indirect dependency).
You would either have to write your own script or search around and see if someone else has written one.
I use SQL Server and Linq-to-SQL in my application.
I have to do a lot of database stuff and after a few hours work I have a stored procedure ready to run.
Sadly I use temporary tables in it (#TempTable) so Linq-to-SQL will give me an error for my return type (read about this e.g. here: LINQ "The return types for the following stored procedures could not be detected" (NOT temp tables)).
The only working solution for me is to switch to a table variable (DECLARE #temptable table) - but for this I found out it is not possible to use dynamic queries (which I do around 60% of my whole stored procedure).
Any ideas?
i found a solution to my problem: I simply wrap my first Stored Procedure with temporary tables in a second Stored Procedure with a single select.
This is automaticly recognized with an auto genereated object in LinQ and I'm happy :)
what is the difference between the table names "#mytable" and "mytable" in TSQL? I see table names start with "#" in a lot of custom procedures.
These are local temporary tables which are private to the process that created them.
#mytable is a temporary table where as mytable is a concrete table.
You can read more about Temporary Tables in SQL Server.
They are used most often to provide workspace for the intermediate results when processing data within a batch or procedure. They are
also used to pass a table from a table-valued function, to pass
table-based data between stored procedures or, more recently in the
form of Table-valued parameters, to send whole read-only tables from
applications to SQL Server routines, or pass read-only temporary
tables as parameters. Once finished with their use, they are discarded
automatically.
Temporary tables come in different flavours including, amongst others,
local temporary tables (starting with #), global temporary tables
(starting with ##), persistent temporary tables (prefixed by
TempDB..), and table variables.(starting with (#)