I am stuck on the following problem. Starting a new transaction after calling a stored procedure gives me "SQL Server Native Client 11.0][SQL Server]New transaction is not allowed because there are other threads running in the session." If I remove the call of that procedure all work out just fine.
The procedure does not start any transaction only reads data.
Some people suggest enabling MultipleActiveResultSets http://php.net/manual/de/ref.pdo-sqlsrv.connection.php but that does not solve the problem.
So the question is how calling a stored procedure may affect starting new transaction in my case.
There is the proc http://pastie.org/9718368
Related
Cannot successfully execute an SSIS package with BEGIN TRAN functionality.
I'm at a loss with an SSIS package I inherited. It contains:
1 Script Task
3 Execute SQL tasks
5 Data flow tasks (each contains a number of merges, lookups, data inserts and other transformations)
1 file system task of the package.
All of these are encapsulated in a Foreach loop container. I've been tasked with modifying the package so that if any of the steps within the control/data flow fails, the entire thing is rolled back. Now I've tried two different approaches to accomplish this:
I. Using Distributed Transactions.
I ensured that:
MSDTC was running on target server and executing client (screenshot enclosed)
msdtc.exe was added as an exception to server and client firewall
Inbound and outbound rules were set for both server and client to allow DTC connections.
ForeachLoop Container TrasanctionLevel: Required
All other tasks TransactionLevel: Supported
My OLEDB Connection has RetainSameConnection set to TRUE and I'm using SQL Server Authentication with Save Password checked
When I execute the package, it fails right after the script task (first step).
After spending an entire week trying to figure out a workaround, I decided to try SQL Tasks to try to accomplish my goal using 3 Execute SQL Tasks:
BEGIN TRAN before the ForeachLoop Container
COMMIT TRAN after the ForeachLoop Container with a Success Constraint
ROLLBACK TRAN after the ForeachLoop Container with a Failure constraint
In this case, the ForeachLoop container and all other tasks have TransactionLevel property set to Supported. Now here, the problem is that the package executes up to the fourth data flow task and hangs there forever. After logging into SQL Server and verifying the running sessions, I noticed sys.sp_describe_first_result_set;1 as a headblocker session.
Doing some research, I found it could be related to a few TRUNCATE statements in some of my Data flow tasks which could cause a schema lock. I went ahead and changed the ValidateExternalMetaData property to False for all tasks within my data flow and changed my truncate statements to DELETE statements instead. Re-ran package and still hangs in the same spot with the same headblocker. As an alternative, I tried creating a second OLEDB connection to the same database, assigned that new OLEDB Connection to my BEGIN, ROLLBACK and COMMIT SQL tasks with RetainSameConnectionProperty set to TRUE and changed the RetainSameConnectionProperty to FALSE (and tried it with TRUE as well) in the original OLEDB connection (the one used by the data flow tasks). This worked in the sense that the package appeared to execute (It ran and Commit Tran executed fine) and then I ran it again with a forced error to cause it to fail and the Rollback TRAN task executed successfully, however, when I queried the affected tables, the transaction hadn't rolled back, all new records were inserted and old ones were updated (the begin tran was clearly started in a different connection and hence didn't affect the package's workflow). I'm not sure what else to try at this point. Any help would be truly appreciated, I’m about to go nuts with this!
P.S. additionally, all objects have "DelayValidation" set to true on everything and SQL Server version is 2012.
From a (classic ASP on IIS) web-page a stored procedure is called in SQL Server. The program waits till the stored procedure returns a result but this is not at all necessary. Is there a way to just start the stored procedure and go on?
Mabel
I suggest you to put this SP into the job. Then launch job from IIS. Also you can use asynchronous SP launch (you can read here about it).
I am using asp.net (version 4) and am trying to run a stored procedure which I have created
ALTER PROCEDURE [dbo].[some_proc]
AS
BEGIN
INSERT INTO [dbo].[some_proc](Creation_Date)
VALUES (getDate());
select SCOPE_IDENTITY();
END
The procedure runs fine when called from within server management studio (runs in less than a second) and also runs fine from my web app UNTIL the afternoon (about 3pm), at which point I get a timeout error, as below:
The request channel timed out while waiting for a reply after 00:00:29.9969982. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
Other stored procedures that I try and run and return expected results. All the stored procedures query the same database.
I have reviewed several other answers on similar questions but they haven't helped me regarding this situation.
I realise this issue may be very specific to my situation, and if it is then my question would be how do I start to debug this issue (any tools or techniques would be really helpful)
You could run a SQL Server Profiler session recording database activity between 2.30 and 3.30
also check SQL Server Agent for any jobs that start around that time
Ok, so I am trying to create a procedure that call an extended procedure. I am getting the following error:
Msg 121, Level 20, State 0, Line 0
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
Even with the simplest test I get that error:
CREATE PROCEDURE Test
AS
BEGIN
EXEC xp_cmdshell 'dir *.exe'
END
However if I just run xp_cmdshell 'dir *.exe' by itself it works.
This is running on a clustered SQL 2005 server. Any help is appreciated.
Are you getting the error when you CREATE the procedure or when you EXECUTE it?
If you get it when you execute it, then there could be some issue with permissions. Since in later versions of sql server calling xp_cmdshell is tightly locked down and by default not enabled in the surface area configuration, I could see a potential for this.
How are you calling the SP? If you're using dynamic SQL, then know that it executes with the privileges of the caller, not the SP creator.
Do you need to prefix the SP with master as in master.dbo.xp_cmdshell?
Have you tried EXECUTE AS either in the SP creation or in the SP execution?
Also, in my experience, transport-level errors are sometimes not due to a problem with the server but a problem with the client caching its connection object past the time when the server has dropped it (thus invalidating the connection object). Given that you're presumably running this within just a short time of initially connecting, it doesn't sound like that is the exact problem, but could you be having some kind of proxy/firewall/net filter issue that is dropping packets because of detecting certain keywords in the packets? I know this is a long shot but I had to ask...
This question already has answers here:
What does sp_reset_connection do?
(2 answers)
Closed 4 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Trying to understand what Sql Profiler means by emitting "sp_reset_connection".
I have the following, "exec sp_reset_connection" line followed by BatchStarting and Completed,
RPC:Completed exec sp_reset_connection
SQL:BatchStarting SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
SQL:BatchCompleted SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
Basically does first line "exec sp_reset_connection" mean the whole process (my connection was opened, the select stmt is run, then the connection is closed and released back to pool) just take place? Or my connection is still in open stage.
And, why does the sp_reset_connection executed before my own select statement, shouldn't it the reset come after user's sql?
I'm trying to know is there a way to know in more detail when a connection is opened and closed?
By seeing "exec sp_reset_connection", does that mean my connection is closed?
Like the other answers said, sp_reset_connection indicates that connection pool is being reused. Be aware of one particular consequence!
Jimmy Mays' MSDN Blog said:
sp_reset_connection does NOT reset the
transaction isolation level to the
server default from the previous
connection's setting.
UPDATE: Starting with SQL 2014, for client drivers with TDS version 7.3 or higher, the transaction isolation levels will be reset back to the default.
ref: SQL Server: Isolation level leaks across pooled connections
Here is some additional information:
What does sp_reset_connection do?
Data access API's layers like ODBC,
OLE-DB and System.Data.SqlClient all
call the (internal) stored procedure
sp_reset_connection when re-using a
connection from a connection pool. It
does this to reset the state of the
connection before it gets re-used,
however nowhere is documented what
things get reset. This article tries
to document the parts of the
connection that get reset.
sp_reset_connection resets the
following aspects of a connection:
All error states and numbers
(like ##error)
Stops all EC's (execution contexts)
that are child threads of a parent EC
executing a parallel query
Waits for any outstanding I/O
operations that is outstanding
Frees any held buffers on the
server by the connection
Unlocks any buffer resources
that are used by the connection
Releases all allocated memory
owned by the connection
Clears any work or temporary
tables that are created by the
connection
Kills all global cursors owned by the
connection
Closes any open SQL-XML handles that are open
Deletes any open SQL-XML related work tables
Closes all system tables
Closes all user tables
Drops all temporary objects
Aborts open transactions
Defects from a distributed transaction when enlisted
Decrements the reference count
for users in current database which
releases shared database locks
Frees acquired locks
Releases any acquired handles
Resets all SET options to the default values
Resets the ##rowcount value
Resets the ##identity value
Resets any session level trace
options using dbcc traceon()
Resets CONTEXT_INFO to NULL in SQL Server 2005 and newer [ not part of the original article ]
sp_reset_connection will NOT reset:
Security context, which is why
connection pooling matches connections
based on the exact connection string
Application roles entered using sp_setapprole, since application roles could not be reverted at all prior to SQL Server 2005. Starting in SQL Server 2005, app roles can be reverted, but only with additional information that is not part of the session. Before closing the connection, application roles need to be manually reverted via sp_unsetapprole using a "cookie" value that is captured when sp_setapprole is executed.
Note: I am including the list here as I do not want it to be lost in the ever transient web.
It's an indication that connection pooling is being used (which is a good thing).
Note however:
If you issue SET TRANSACTION ISOLATION LEVEL in a stored procedure or trigger, when the object returns control the isolation level is reset to the level in effect when the object was invoked. For example, if you set REPEATABLE READ in a batch, and the batch then calls a stored procedure that sets the isolation level to SERIALIZABLE, the isolation level setting reverts to REPEATABLE READ when the stored procedure returns control to the batch.
http://msdn.microsoft.com/en-us/library/ms173763.aspx