Is there a view or internal sp to do this?
For example, I have a sp spGoesOnForSomeTime.
If I kicked this off then some individual closes my computer down, how can I see whether this is still running or not?
I realise I can use SQL Profiler and ActivityMonitor but I ultimately want to relay this information back through a web app.
EDIT: Apologies, it is not a local connection.
If it's run under your local connection, then it will stop and roll back, so you can be confident that it is not running.
If it's running under the context of another connection, you can use the sp_who stored procedure to see all of the activity (and active connections) on the server, and the cmd column should provide you with the command. If any of the records have your procedure name in their cmd column, then that will tell you that it's executing.
You may, however, want to take a more intentional approach and set a flag of some kind (a value in a row in another table, an extended property on the database or procedure, etc.) when the procedure starts, then reset it when the procedure finishes. This would also account for scenarios where your procedure gets called from within another procedure.
If running it from your local Management Studio, the connection will be broken (closed) when SSMS closes.
Any transactions will rollback, all locks will be released. If you're in the middle of some huge data changes, your proc stops running and the connection is still closed, but the rollback will continue anyway
So no need to check based on the facts given...
Depends whether you're running it using SqlServerAgent or just via Mgmt Studio.
As #gbn said, once you disconnect then any work using that connection will stop too.
I'd say create a scheduled Job and then it's independent of your connection.
If this is part of an application requirement then I would log the start and finish of all of the calls to this stored procedure then have a view against that to show which instances of the stored procedure are currently running.
If this is for maintenance of the database then I would use sp_who or sp_who2.
EDIT:
Actually, sp_who and sp_who2 will likely show you the currently running command, not necessarily the stored procedure name itself. You can try using the system dynamic view sys.dm_exec_sql_text, but that isn't always going to be accurate either.
Related
I use SAS EG 8.2.
And I know there is stop buttons on menu bar.
But sometimes when the requesting result of my proc sql program is little(??) bit large,
that stop buttons doesn't work.
It always goes where it hopes to go.
From time to time, it takes over 1 hour(. And now I'm waiting and asking for)...
So I hope to know how to terminate a running proc sql program at once.
There's a bunch of different possible issues here.
When you say proc sql, if you mean a job that is submitting code to a SQL database, you probably cannot force that job to quit. Your database administrator would have to do that, on the SQL database end - SAS usually cannot do anything about it.
If it's a SAS job only in PROC SQL, then often the stop button will be fine. But if not, and if it's not a local job, you may be able to use PROC IOMOPERATE to quit the job, depending on your permissions on the server. You may not be able to, as it's generally restricted to administrators, but again your SAS Admin may be able to. See Chris Hemedinger's post on the subject; he also developed an EG add-in that will allow that to work.
It is harder to control what SAS is doing when you use a front-end like Enterprise Guide to submit your SAS code instead of running SAS directly.
You could try disconnecting from the SAS Server and starting a new session.
I have a stored procedure that takes 1 parameter. When I run the stored procedure from SQL Server Management Studio, it runs in 2-4 seconds. When I call it with a console application, it takes 30+ seconds. The SQL Server is remote and both SSMS and my application are being run from my local machine so I don't think it's a networking issue.
I've ran the SQL Server Profiler to try to track down the issue and one thing I'm seeing is that when it's run from SSMS it starts the statement, recompiles it, then starts it over again, then completes it, like this:
SP:StmtStarting
SP:Recompile
SQL:StmtRecompile
SP:StmtStarting
SP:StmtCompleted
The 2 recompile entries have an EventSubClass of "2 - Statistics changed"
From the app I only see entries for SP:StmtStarting & SP:StmtCompleted, no recompile entries.
I'm calling exactly the same stored procedure with the same parameter value. Why does SSMS recompile based on statistics but my console app does not?
After researching and troubleshooting it appears to be entirely due to SET_ARITHABORT_ON. SSMS defaults this to 'ON' while the .net sql client defaults it to 'OFF' so it was going with 2 different execution plans, although I'm not entirely sure why the two plans are so drastically different.
I overrode the OpenConnection() method to open the connection set it to ON and my application then had the same performance as SSMS. I hope this helps anyone else who stumbles upon this.
I am using SQL server 2014 management studio.
I am working on a windows form application (vb.net).
I am facing a problem. (I am not sure if it works this way)
I wrote some Database insertion inline queries.
While I Debug my code, SQL transaction is open and inserting the data,
My question here is that if a transaction is opened from back-end, why can I not execute any query from management studio?
As soon as transaction is committed or rolled back, management studio works fine with even big queries too.
Thanks in advance.
When you run a transaction, the objects used in the transaction are locked and no other connection is allowed to access the object. In your case when you run the transaction within the application the transaction locks the objects being used (like table) and simultaneously when you fire query from management studio it waits for the lock to be released. As soon as the transaction in the application completes lock is released and the query in the management studio executes.
Try to use with nolock in Your query.
It will allow you to acces the data from object included in transaction.
Even though you are using different IDEs, the Sql server instance you are using is the same. You are accessing the same Database no matter from which IDE you are accessing.
I have a SQL Server 2005 procedure that needs to be modified to call a procedure that's on a linked server. My local procedure is called by several other procedures, always within a transaction.
If I add the call to the linked server, then at run time I get a message saying that the OLE DB provider was unable to begin a distributed transaction.
That's fine with me: as far as I know, the remote procedure doesn't do any database changes. I don't need it to be inside the transaction and therefore don't need a distributed transaction.
But I suspect that I don't have that option, that there's no way to turn off the extension of the transaction to the linked server. Is this correct?
(I could get around the problem by refactoring these procedures so that the call to the linked server takes place in a parent procedure, outside all transactions. But logically it belongs within this child procedure, so I'd like to keep it there.)
Thanks, all.
It turns out that, if you are on SQL Server 2008 or above, you have a server option that controls this:
EXEC sp_serveroption 'servername', 'remote proc transaction promotion', 'false'
(See sp_serveroption (Transact-SQL)).
But I was on SQL Server 2005, which doesn't have that option. So I investigated further and discovered that MSDTC had network transactions disabled on the machine I was using, which was why the remote transaction was failing. I was able to get this enabled by a DBA.
Background:
I have a site built in ASP.NET with Sql Server 2005 as it's database. The site is the only site on a Windows Server 2003 box sitting in my clients server room. The client is a local school district, so for data security reasons there is no remote desktop access and no remote Sql Server connection, so if I have to service the database I have to be at the terminal. I do have FTP access to update ASP code.
Problem:
I was contacted yesterday about an issue with the system. When I looked in to it, it seems a bug that I had solved nearly a year ago had returned. I have a stored procedure that used to take an int as a parameter but a year ago we changed the structure of the system and updated the stored procedure to take an nvarchar(10). The stored procedure somehow changed back to taking an int instead of an nvarchar.
There is an external hard drive connected to the server that copies data periodically and has the ability to restore the server in case of failure. I would have assumed that somehow an older version of the database had been restored, but data that I know was inserted 7 days and 1 day before the bug occurred is still in the database.
Question:
Is there anyway that the structure of a Sql Server 2005 database can revert to a previous version or be restored to a previous version without touching the actual data? No one else should have access to the server so I'm going a little insane trying to figure out how this even happened.
Any ideas?
Using SQL Server's built-in backup and restore mechanism, there is no means to pick only certain objects to restore. With transaction log backups, you can restore to a point in time which might be before a certain transaction or ALTER statement was made but that's the closest you get. There are tool's which will let you pick certain objects to restore however they work by either restoring the database to a copy and copying over the objects you want or reading the backup directly and copying out those objects. In other words, this is not something could have happened using the built-in tools accidentally. My guess is that someone accidentally ran an old script of the stored proc(s) that reverted it.
It would be trivial to change a stored procedure without touching any data, or any other stored procedure. How who why when, that's the problem.
One suggestion, run
select * from sys.procedures
and check the create_date and modify_date columns, for both your problem procedure and all other procedures in the database.
I've witnessed similar things happening with an app I have installed at one client location. Every so often the s'procs revert to an older version.
It's just one client, the app is installed at several others which have never had this issue, and they happen to be a school district as well. It happens about once every 3 months or so, and no one should be touching that machine. I'm not even sure they have anyone in house that would know how to open enterprise manager.
Out of curiousity, what backup software is your client using? and, after checking the creation / modify dates on the procedures, did a server reboot occur around that time?
The reason I ask is that my client has backup software that does some really weird things on that server. For example, on reboot it has to "play back" changes, including file operations, since the last successful backup. Also, is it installed in a VM?
Through Data Transformation Services (DTS) ? or if the scripts that set up the database are available someplace..