I'm using SQL Server 2008 R2 and I am trying to run a query where a stored procedure will also be executed.
The query is:
select a.custnmbr, a.custname, a.salsterr, b.itemnmbr, b.itemdesc, d.slprsnid ,exec dbo.QtySoldPerMonth a.custnmbr, b.itemnmbr, #year
from rm00101_temp a, iv00101_temp b
inner join sop30300_RPT c on b.itemnmbr = c.itemnmbr
inner join sop30200_RPT d on c.sopnumbe = d.sopnumbe
where
b.itemnmbr like #houseCode + '%' and itmclscd like #classCode + '%'
AND DATEPART(year, d.docdate) = #year
group by a.custnmbr, a.custname, a.salsterr, b.itemnmbr, b.itemdesc, d.slprsnid
order by d.slprsnid, b.itemnmbr
What I'm really asking is how do I go about including the execution of the dbo.QtySoldPerMonth stored procedure in the select query? Also, the parameters for the stored procedures are: #custNo = a.custnmbr, #itemNo = b.itemnmbr and #year = #year.
Any help on how to rewrite the query to execute the sp will be appreciated.
create temp table for sp output
exec stored proc into temp table
join temp table to the rest of your query
create table #temp(yourCol1 int, your Col2 int...);
insert #temp(yourCol1,yourCol1...)
exec dbo.QtySoldPerMonth
select * from blah
join #temp t on (blah.blah=t.id...)
You can't execute a stored procedure as part of another query.
See if you can use a view of UDF to represent the same structure that the SP would return.
Edit
Another option: execute the stored procedure first and use the results in your main query.
You can't incorporate SP results to query, but you can dump SP to a table. Example:
http://blog.sqlauthority.com/2009/09/23/sql-server-insert-values-of-stored-procedure-in-table-use-table-valued-function/
But in your case it's not an option, as you want SP result with different parameters for every row; unless you modify SP so it returns a result set that you can later use after inserting it into table.
Related
I am completely new to SQL Server and a bit lost. When I try the following, it executes the first three lines and ignores the rest, just get
'Command(s) completed successfully.'
USE [RenewalsDb]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[One]
AS
BEGIN
SET NOCOUNT ON;
DROP TABLE [dbo].NewTransTable;
SELECT * INTO [dbo].[NewTransTable] FROM [dbo].aqryTransTable;
DELETE FROM [dbo].[NewTransTable] WHERE (((NewTransTable.CURRENT_LICENSE_SKU_DESC) Like '% partner program %'));
DELETE FROM [dbo].[NewTransTable] WHERE (((NewTransTable.RENEWAL_MAINTAINANCE_SKU_DESC) Like '% partner program %'));
UPDATE NewTransTable SET NewTransTable.[Quote Number] = Null;
UPDATE dbo.TransactionTable SET Concat = dbo.qryNamedAcReseller.LATEST_DISTRIBUTOR_NAME + dbo.qryNamedAcReseller.[Sub Territory FY14 ]
FROM dbo.TransactionTable INNER JOIN
dbo.qryNamedAcReseller ON dbo.TransactionTable.LATEST_INSTANCE_NUMBER = dbo.qryNamedAcReseller.LATEST_INSTANCE_NUMBER;
UPDATE dbo.TransactionTable SET Concat = dbo.qryNamedAcReseller.[Sub Territory FY14 ]
FROM dbo.TransactionTable INNER JOIN
dbo.qryNamedAcReseller ON dbo.TransactionTable.LATEST_INSTANCE_NUMBER = dbo.qryNamedAcReseller.LATEST_INSTANCE_NUMBER
WHERE Concat IS NULL;
UPDATE dbo.NewTransTable SET [Quote Number] = dbo.Autogen.[Quote Number] FROM dbo.Autogen RIGHT OUTER JOIN
dbo.NewTransTable ON dbo.Autogen.[IB Reference Num] = dbo.NewTransTable.LATEST_INSTANCE_NUMBER AND
dbo.Autogen.[Quote Known As] = dbo.NewTransTable.[Quote Known As]
DROP TABLE [dbo].NewTransTable2;
SELECT * INTO [dbo].[NewTransTable2] FROM [dbo].aqryTransTable2;
ALTER TABLE [dbo].NewTransTable2 ADD Named_Account nvarchar(255);
END
GO
Welcome to stackoverflow.
Stored Procedure is like a template which can reused multiple times and it can be made dynamic with the help or parameters. Refer mssqltips.com - SQL Server Stored Procedure Tutorial on guide to Stored Procedures. If you want to execute some commands only once, Stored Procedure is not the right thing.
So when you execute the above script, what SQL Server is doing is creating the template structure i.e. Stored procedure named [One] and not actually running the scripts within the stored procedure.
To execute this stored procedure named [One] you have to call it using EXEC One or just simply One and Execute (F5)
I have a problem with a query to store results from a stored procedure in a temporary table. See below for a simplified version of the query itself:
USE [ADataBaseName]
GO
CREATE TABLE #temp(
SrcUD16 VARCHAR(200))
DECLARE #return_value int
INSERT INTO #temp(
SrcUD16)
EXEC #return_value = [dbo].[AStoredProcedure]
#PartKey = 100,
#Entity_Name = N'SomeEntityName,
#PeriodDesc = N'QA - 2014',
#CategoryKey = 12
SELECT * FROM #temp
GO
The stored procedure creates two other temporary tables to be joined in a Select statement:
SELECT SrcUD16 FROM #temp2 LEFT JOIN #temp3
ON #temp2.MinMaxCIC = #temp3.SrcUD15
Executing the first statement above will give me the following error:
'Invalid column name 'SrcUD16'
However, manually executing the stored procedure does yield the expected results for the field SrcUD16. I can also change the fieldname from SrcUD16 to SrcUD15 which results in a working query albeit incorrect column heading (i.e. ScrUD16 data with 'SrcUD15' as heading).
I strongly suspect this error has something to do with the order in which the temp tables are created and what the query recognizes as allowed field headings. Perhaps someone with better understanding has soem pointers for me?
Thanks in advance
I have a stored procedure that can NOT be modified, the result of this stored procedure is normal select statement as following :
CREATE PROCEDURE LockedProcedure
AS
BEGIN
SELECT * FROM COLORS_TABLE
END
my problem is that I need to get its result as XML result like how the select statement returns when you provide "FOR XML" but without modifying the procedure itself, maybe we can create another stored procedure to call that or user defined function.
This is an example of the procedure that we CAN NOT modify because it is locked.
how to get its result as XML result NOT XML FILE...I don't want any physical file on hard disk.
Thanks.
Solution 1)
Create a temp table matching the output definition of stored procedure.
Use INSERT INTO #Tmp EXEC SPName to insert the stored procedure results into the temp table.
Use FOR XML in combination with SELECT command to fetch the results as xml from temp table.
Solution 2)
Create a CLR User-Defined function to execute the stored procedure and use the BCL facilities to convert the results to xml.
I had a similar problem to this but in my case editing the stored procedure is possible. Even though the OP mentions the stored procedure is locked, I still wanted to post this solution here for others that stumble upon it. This solution assumes the stored procedure uses dynamic SQL to select some data, but could just as easily be adapted to a non-dynamic SQL case.
Add a parameter to the sp such as "#lp_ReturnAsXML BIT = 0". When set to true, you will return the result set as XML using "FOR XML RAW" or some similar command.
Then add this to the end of the stored procedure as an alternative for running the dynamic SQL:
IF #lp_ReturnAsXML = 1
BEGIN
DECLARE #l_XML XML
SET #l_SQL = 'SET #l_XML = (SELECT * FROM ( ' +
#l_SQL + '
) d FOR XML RAW)'
EXEC sp_executesql #l_SQL, N'#l_XML XML OUTPUT', #l_XML = #l_XML OUTPUT
SELECT #l_XML
END
Now something like this should work:
DECLARE #table TABLE
(
Results XML
)
INSERT INTO #table
EXEC p_MyStoredProc ..., #lp_ReturnAsXML = 1
I have the following query:
DECLARE #DaysNotUsed int = 14
DECLARE #DaysNotPhoned int = 7
--Total Unique Students
DECLARE #totalStudents TABLE (SchoolID uniqueidentifier, TotalUniqueStudents int)
INSERT INTO #totalStudents
SELECT
SSGG.School,
COUNT(DISTINCT S.StudentID)
FROM Student S
INNER JOIN StudentStudents_GroupGroups SSGG ON (SSGG.Students = S.StudentID AND SSGG.School = S.School)
INNER JOIN [Group] G ON (G.GroupID = SSGG.Groups AND G.School = SSGG.School)
INNER JOIN SessionHistory SH ON (SH.Student = S.StudentID AND SH.School = S.School AND SH.StartDateTime > GETDATE() - #DaysNotUsed)
WHERE G.IsBuiltIn = 0
AND S.HasStartedProduct = 1
GROUP BY SSGG.School
--Last Used On
DECLARE #lastUsed TABLE (SchoolID uniqueidentifier, LastUsedOn datetime)
INSERT INTO #lastUsed
SELECT
vi.SchoolID,
MAX(sh.StartDateTime)
FROM View_Installation as vi
INNER JOIN SessionHistory as sh on sh.School = vi.SchoolID
GROUP BY vi.SchoolID
SELECT
VI.SchoolID,
INS.DateAdded,
INS.Removed,
INS.DateRemoved,
INS.DateToInclude,
VI.SchoolName AS [School Name],
VI.UsersLicensed AS [Licenses],
ISNULL(TS.TotalUniqueStudents, 0) as [Total Unique Students],
ISNULL(TS.TotalUniqueStudents, 0) * 100 / VI.UsersLicensed as [% of Students Using],
S.State,
LU.LastUsedOn,
DATEDIFF(DAY, LU.LastUsedOn, GETDATE()) AS [Days Not Used],
SI.AreaSalesManager AS [Sales Rep],
SI.CaseNumber AS [Case #],
SI.RenewalDate AS [Renewal Date],
SI.AssignedTo AS [Assigned To],
SI.Notes AS [Notes]
FROM View_Installation VI
INNER JOIN School S ON S.SchoolID = VI.SchoolID
LEFT OUTER JOIN #totalStudents TS on TS.SchoolID = VI.SchoolID
INNER JOIN #lastUsed LU on LU.SchoolID = VI.SchoolID
LEFT OUTER JOIN InactiveReports..SchoolInfo SI ON S.SchoolID = SI.SchoolID
LEFT OUTER JOIN InactiveReports..InactiveSchools INS ON S.SchoolID = INS.SchoolID
WHERE VI.UsersLicensed > 0
AND VI.LastPhoneHome > GETDATE() - #DaysNotPhoned
AND
(
(
SELECT COUNT(DISTINCT S.StudentID)
FROM Student S
INNER JOIN StudentStudents_GroupGroups SSGG ON (SSGG.Students = S.StudentID AND SSGG.School = S.School)
INNER JOIN [Group] G ON (G.GroupID = SSGG.Groups AND G.School = SSGG.School)
WHERE G.IsBuiltIn = 0
AND S.School = VI.SchoolID
) * 100 / VI.UsersLicensed < 50
OR
VI.SchoolID NOT IN
(
SELECT DISTINCT SH1.School
FROM SessionHistory SH1
WHERE SH1.StartDateTime > GETDATE() - #DaysNotUsed
)
)
ORDER BY [Days Not Used] DESC
Running just plain sql like this in SSMS take about 10 seconds to run. When I created a stored procedure with exactly the same code, the query takes 50 seconds instead. The only difference in the actual code of the proc is a SET NOCOUNT ON that the IDE put in by default, but adding that line to the query doesn't have any impact. Any idea what would cause such a dramatic slow down like this?
EDIT I neglected the declare statements at the beginning. These are not in the proc, but are parameters to it. Could this be the difference?
I agree about the potential parameter sniffing issue, but I would also check these settings.
For the procedure:
SELECT uses_ansi_nulls, uses_quoted_identifier
FROM sys.sql_modules
WHERE [object_id] = OBJECT_ID('dbo.procedure_name');
For the SSMS query window where the query is running fast:
SELECT [ansi_nulls], [quoted_identifier]
FROM sys.dm_exec_sessions
WHERE session_id = ##SPID;
If either of these don't match, you might consider dropping the stored procedure and re-creating it with those two settings matching. For example, if the procedure has uses_quoted_identifier = 0 and the session has quoted_identifier = 1, you could try:
DROP PROCEDURE dbo.procedure_name;
GO
SET QUOTED_IDENTIFIER ON;
GO
CREATE PROCEDURE dbo.procedure_name
AS
BEGIN
SET NOCOUNT ON;
...
END
GO
Ideally all of your modules will be created with the exact same QUOTED_IDENTIFIER and ANSI_NULLS settings. It's possible the procedure was created when the settings were off (the default is on for both), or it's possible that where you are executing the query, one or both options are off (you can change this behavior in SSMS under Tools/Options/Query Execution/SQL Server/ANSI).
I'm not going to make any disclaimers about the behavior of the stored procedure with the different settings (for example you may have wanted ANSI_NULLS off so you could compare NULL = NULL), that you'll have to test, but at least you'll be comparing queries that are being run with the same options, and it will help narrow down potential parameter sniffing issues. If you're intentionally using SET ANSI_NULLS OFF, however, I caution you to find other approaches as that behavior will eventually be unsupported.
Other ways around parameter sniffing:
make sure you don't inadvertently compile the procedure with atypical parameters
use the recompile option either on the procedure or on the statement that seems to be the victim (I'm not sure if all of these are valid, because I can only tell that you are using SQL Server 2005 or greater, and some of these were introduced in 2008)
declare local variables similar to your input parameters, and pass the input parameter values to them, using the local variables later in the prodedure and ignoring the input parameters
The last option is my least favorite, but it's the quickest / easiest fix in the midst of troubleshooting and when users are complaining.
Also, in addition to everything else mentioned, if you are on SQL Server 2008 and up, have a look at OPTIMIZE FOR UNKNOWN http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature.aspx
I would recommend recompiling the execution plan for the stored procedure.
usage: sp_recompile '[target]'
example: sp_recompile 'dbo.GetObject'
When you execute a query from SSMS the query plan is automatically redone every time its executed. However with stored procs, sql server caches execution plans for stored procedures, and its this execution plan that gets used everytime the stored proc is called.
Link for sp_recompile.
You can also change the proc to use with WITH RECOMPILE clause within the stored proc.
Example:
CREATE PROCEDURE dbo.GetObject
(
#parm1 VARCHAR(20)
)
WITH RECOMPILE
AS
BEGIN
-- Queries/work here.
END
However this will force the execution plan to be recompiled every time the stored proc is called. This is good for dev/testing where the proc and/or data changes quite frequently. Make sure you remove it when you deploy it to production, as this can have a performance hit.
sp_recompile only recompiles the execution plan once. If you need to do it again at a later date, you will need to make the call again.
Good luck!
OK, thank you all for your help. Turns out it was a terribly stupid rookie mistake. The first time I created the proc, it created it under my user's schema instead of the dbo schema. When I called the proc I was simply doing 'exec proc_name', which I'm realizing now was using the version of the proc under my user's schema. Running 'exec dbo.proc_name' ran as expected.
Is there a way to cause the result set of a SQL Server stored procedure (or any result set, after the fact) to be encoded in XML format?
I want the result set to be encoded in XML as if the FOR XML RAW clause was used during selection.
However the complex stored procedure logic and its internal SELECT statements should not be modified to return XML because the procedure is used for its standard/non-XML result set most of the time.
Update: Emphasis on the fact I'm looking for an answer in the SQL Server environment - the
results should be returned as if SQL Server has directly encoded them itself, as XML, just like it does when using the built-in XML features like the FOR XML clause.
You would insert the data from the SP into a temp table, then select from that FOR XML
This won't work if the SP itself already does a INSERT .. EXEC SPROC because you cannot nest them
Working examples
use tempdb;
create proc giveme
as
select a = 1, b = GETDATE()
union all
select 2, b = '20100101'
Using INSERT.. EXEC
declare #t table (a int, b datetime)
insert #t
exec giveme
select * from #t for xml raw
Using OPENQUERY
exec sp_addlinkedserver 'localhost'
exec sp_serveroption #server = 'localhost'
,#optname = 'DATA ACCESS'
,#optvalue = 'TRUE'
select *
from openquery(localhost, 'exec tempdb..giveme')
for xml raw
You could try using OPENROWSET in cooperation with FOR XML to do the transformation.
By 'after the fact', do you mean still within the SQL Server environment? Or are you talking about a client program?
Within SQL, you could probably write a sproc that acts as a wrapper for your other sprocs, along these lines. The wrapper sproc would handle the FOR XML work.
In .NET, there are a number of ways to do this.
You can try inserting the result set from the stored procedure into a table variable( or temporary table) and selecting the table rows with the FOR XML clause.
Here is an example:
DECLARE #MyDataTable AS TABLE ( col1 int,...., colN int)
Make sure that the #MyDataTable has the same columns as the stored procedure result set(s).
INSERT INTO #MyDataTable
EXECUTE mysp_GetData #param1=value,....,#paramN;
SELECT * FROM #MyDataTable
FOR XML AUTO