We are using one shared data source ds1 that connects to a server main_server which holds all the stored procedures to generate our reports.
One of the stored procedures usp1 simply executes another stored procedure on another server another_server:
exec another_server.another_database.dbo.usp1
When I execute usp1 on main_server, everything works fine. It runs at almost the same speed as if I had just gone to another_server and executed from there.... Which is what I expected...
However, when I try to run the report from our report server, it fails. When I watch it run, it almost immediately goes into suspended mode and stays there.
We have all of our timeouts set to 40 minutes, so that shouldn't be our issue, since the report runs in 15. Any thoughts?
Thanks...
Maybe the account reporting services uses to run the report doesnt have the correct access or rights to run an sp on another server?
With linked servers your stored procedure may copy ALL the data it needs before doing any joins.
Check out:
http://blogs.msdn.com/b/dataaccesstechnologies/archive/2010/06/30/linked-server-performance-heterogeneous-databases.aspx
Related
I'm running a stored procedure right now that will likely take 12 hours to complete, however the exact actual time is unknown. I have another stored procedure that I need to run once the currently running one is finished. Is it possible in SQL Server to schedule something to run, one time, e.g. "after dbo.storedProcedureName completes execution"?
Yesterday I tried the schedule option in SQL Server Agent called "Start whenever the CPU's become idle" but this did not work.
This may be possible with some add-in, or with a loop monitoring running processes, but it isn't really the best way. Instead, you should set up an SQL Script to run the two in sequence, e.g.:
EXEC dbo.MyLongRunningProc;
EXEC dbo.MyOtherProc;
These are guaranteed to run in sequence, one right after the other, when run from inside SSMS or a similar tool.
You can create and execute (or schedule) a procedure that runs both
create procedure runBothInOrder
as
begin tran
exec procedure1
exec procedure2
commit
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
I know it is not good way and may have many issues. But can anyone tell what are the problems in executing the SP which has while loop.
CREATE PROC udpParseData
BEGIN
WHILE(true)
BEGIN
--logic goes here
END
END
EXEC udpParseData
I want to run it like a service. Instead of running a service which check the DB continuously using SQL Dependancy. Any problem with this and also i have a main concern that how to stop the running SP udpParseData. One more option i have is run the same SP in Scheduler JOB. I wanted to know the restrictions and disadvantages of using this.
You don't want to do this - even a Windows service doesn't work like that. A Windows service would leverage a Timer that wakes up on an interval and starts the message pump.
Write the work you want to execute in a stored procedure and then create a Job on the SQL Server that executes that stored procedure, and setup the times you want it to run. The Job takes the place of the Timer in the Windows service.
I have a weird problem here.
In short to the environment we have:
There is a (newly set up) Win2003 Server with a SQL Server 2005 Express database. I connect to it via a MS Access application.
Since I switched to the new server (restored a backup from the former server on it) all SPROCs (only in Access) have a ;1 after their name, hence cannot be found.
If I try to open a SPROC in Access (dbl click in overview), it asks for the parameter, then says cannot be found.
If I try to open, say, a report based on it, same result. If I change the name of the SPROC the report is based on to the name shown in the overview ( [sprocnam];1 ) it says "cannot be found" (of course, because the names did not change as one can see in Management Studio).
?!?
keep in mind that the Access-application worked fine with the database that I backed up on another server and restored to the newly set up server ...
Your help is greatly appreciated!
edit: I found a thread on SAP.com with someone experiencing the same problem, but without a solution: https://forums.sdn.sap.com/message.jspa?messageID=7947957
I can't tell why you have got this issue, but in In SQL Server you have the ability to create Numbered stored procedures. The procedures have the same name but may contain completely different code, look at this:
CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT ##MICROSOFTVERSION
END
GO
CREATE PROCEDURE [dbo].[spTest];2
AS
SELECT ##version
GO
EXEC spTest;1
EXEC spTest;2
I resolved the issue with an update of the clients office-installation to the latest service pack.
The one employee that notified me of the problem and me got new computers last week, and thus did not have the latest updates.