The 'SP_' prefix by convention suggests a system stored procedure. But nowhere in my SQL Server instance could I find the sp_executesql stored procedure.
I know it is there because it is used by one of my workplace's legacy code. But where is it? Where can I find it using MS SQL Server Management Studio?
Where can I find it using MS SQL Server Management Studio?
It is an extended stored procedure and you can't do anything useful with it having found it though (apart from managing permissions).
master --> Programmability --> Extended Stored Procedures --> System Extended Stored Procedures
It is present there , if you execute this query
`sp_helptext sp_executesql
you will get (Server Internal) because "sp_helptext" is a extended stored procedures so you cannot see it. They are processed in a dll rather than TSQL..
Refer this link
https://technet.microsoft.com/en-us/library/ms175200%28v=sql.105%29.aspx
Related
I noticed that all examples (that I've seen) of natively compiled stored procedures (in SQL Server) are defined using EXECUTE AS OWNER.
For example:
CREATE PROCEDURE [dbo].[InsertOrderXTP]
#id INT,
#date DATETIME2,
#status TINYINT
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS...
We started getting the following error while trying to execute natively compiled stored procedures we created with EXECUTE AS OWNER:
Could not obtain information about Windows NT group/user ...
This make sense because we had other un-related technical issue with the user that created those procedures.
Since we never used EXECUTE AS .. in regular ("interpreted") procedures, I tried removing it from the natively compiled stored procedure and it seems to to be working just fine.
But as I mentioned, it contrast from all the examples I've seen, and I couldn't find any relevant documentation that elaborates on this issue.
Must a natively compiled stored procedures be created with EXECUTE AS OWNER..."?
Is there a benefit to creating natively compiled stored procedures with EXECUTE AS OWNER... that doesn't exist in regular (interpreted) stored procedures?
Where can I find explicit documentation about this issue?
This appears to be a historical limitation that is no longer required as of SQL Server 2016.
In the documentation for CREATE PROCEDURE, we have this note:
For natively compiled stored procedures, starting SQL Server 2016 (13.x) and in Azure SQL Database, there are no limitations on the EXECUTE AS clause. In SQL Server 2014 (12.x) the SELF, OWNER, and 'user_name' clauses are supported with natively compiled stored procedures.
Then on the separate page about EXECUTE AS there is this:
CALLER is the default for all modules except queues, and is the same as SQL Server 2005 (9.x) behavior.
Put those two things together, and we find that omitting the EXECUTE AS clause on a natively compiled stored procedure in SQL Server 2014 would have defaulted to an unsupported option. So all examples of natively compiled stored procedures which predate SQL Server 2016 would have needed an explicit EXECUTE AS clause to compile successfully.
I recently used [sp_xml_preparedocument] to parse an XML file to analyze the parameter data.
What is interesting to me is that when I drill into my SQLServer 2k8r2 instance I cannot seem to actually find a procedure named [sp_xml_preparedocument].
I've been looking in System Databases/Mater and the Db I created for the analysis and it does not appear.
However [EXEC sp_xml_preparedocument #hdoc OUTPUT, #x] executes just fine.
I'd like to deepen my understanding of what is occurring and review the actual procedure.
Where should this stored procedure actually appear?
sp_xml_preparedocument is a system extended stored procedure. From SSMS Object Explorer, you'll find it under Databases-->System Databases-->Programmability-->System Extended Stored Procedures.
Since it's an unmanaged extended proc written in C++, not T-SQL, so you won't be able to review the source code. It used to just wrap the msxml COM API but I'm not sure if that's still the case nowadays since it's internal SQL Server code.
I'm a student and the SQL Server 2016 documentation that I'm going through is not very clear. And the online help that I saw I think it refers to SQL Server 2017 https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-dropextendedproc-transact-sql
Regards
The article says
In SQL Server 2017, sp_dropextendedproc does not drop system
extended stored procedures. Instead, the system administrator should deny
EXECUTE permission on the extended stored procedure to the public role.
Which is true, but seems to suggest this is something new in SQL Server 2017. This is not the case; it's an inappropriate search-replace based on the current version. The Books Online help for SQL Server 2005 (since removed online, I think) says this (emphasis mine):
In SQL Server 2005, sp_dropextendedproc does not drop system extended
stored procedures. Instead, the system administrator should deny
EXECUTE permission on the extended stored procedure to the public
role. In SQL Server 2000, sp_dropextendedproc could be used to drop
any extended stored procedure.
And this, unlike the current version, makes it clear what's going on. Sometimes Microsoft's obsession with removing documentation for products that are no longer supported goes a little too far.
I am currently using USE [databaseName] in my stored procedures. However, is there a way that I can point this at the current local database and not give a database name? I know this may sound a bit obscure but its highly likely that I will be using these Stored Procedures in many different databases.
remove the USE [databaseName] from your stored procedure.
By default, the stored procedure will run on the current database (in which SP is created)
Is it possible to see the CODE for sp_executesql?
I would like to see the actual code.
I could not find it in sql server management studio.
sp_executesql is an extended stored procedure. It's binary in a DLL.