February 4, 2004 at 10:30 am
When running profiler I have noticed that the sp_execute statement runs quite often. I think the developers do this on purpose through ADO. What I want to know is what statement or stored procedure is executing this sp_execute statement because after the statement all you have is a number and then parameters. Can someone tell me how this number can be referenced?
Thanks,
Belinda
February 9, 2004 at 8:00 am
This was removed by the editor as SPAM
February 9, 2004 at 1:53 pm
Here's some documentation for you. It's not much. Have you tried DBCC Inputbuffer(nn) where nn is the SPID?
Users running SQL Profiler against ADO, OLE DB, ODBC, and DB-Library applications may notice the use of system stored procedures that are not covered in the Transact-SQL Reference. These stored procedures are used by the Microsoft OLE DB Provider for SQL Server, the SQL Server ODBC driver, and the DB-Library dynamic-link library (DLL) to implement the functionality of a database API. These stored procedures are simply the mechanism the provider or drivers use to communicate user requests to SQL Server. They are intended only for the internal use of the OLE DB Provider for SQL Server, the SQL Server ODBC driver, and the DB-Library DLL. Calling them explicitly from an SQL Server application is not supported.
The complete functionality from these stored procedures is made available to SQL Server applications through the API functions they support. For example, the cursor functionality of the sp_cursor system stored procedures is made available to OLE DB applications through the OLE DB API cursor properties and methods, to ODBC applications through the ODBC cursor attributes and functions, and to DB-Library applications through the DB-Library Cursor Library.
These system stored procedures support the cursor functionality of ADO, OLE DB, ODBC, and the DB-Library Cursor Library:
| sp_cursor | sp_cursorclose | sp_cursorexecute |
| sp_cursorfetch | sp_cursoropen | sp_cursoroption |
| sp_cursorprepare | sp_cursorunprepare |
These system stored procedures support the prepare/execute model of executing Transact-SQL statements in ADO, OLE DB, and ODBC:
| sp_execute | sp_prepare | sp_unprepare |
The sp_createorphan and sp_droporphans stored procedures are used for ODBC ntext, text, and image processing.
The sp_reset_connection stored procedure is used by SQL Server to support remote stored procedure calls in a transaction.
The sp_sdidebug stored procedure is used by SQL Server for debugging Transact-SQL statements.
February 10, 2004 at 12:43 pm
sp_execute is a system stored procedure used with "prepared" statements from a client. The number you see is an internal pointer to the execution plan on the server. The values following that number are the parameters for a particular invocation of the prepared statement. See Prepared Execution in BOL.
--Jonathan
February 11, 2004 at 12:21 pm
Unfortunately, MS has not provided us, the DBA's, a good way of actually seeing what SQL is actually being executed by sp_execute. This makes troubleshooting and optimization very difficult at best and sometimes impossible. This reason alone is enough to tell our developers not to use prepared statements.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
January 5, 2010 at 12:05 am
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply