I have a problem with a JOB execution, the case is the next:
I have a job with category (Uncategorized Local) than have 1 step with "Transact SQL script" type.
The transact code is:
DECLARE #fecha_inicio DATETIME,
#fecha_fin DATETIME,
#fecha_inicio_p VARCHAR(10),
#fecha_fin_p VARCHAR(10),
#vc_mensaje_error AS VARCHAR(255)
BEGIN TRY
SELECT #fecha_inicio_p = par_valor1
FROM parametro
WHERE par_codigo_dominio = '000213' and par_codigo = 'FI'
SELECT #fecha_fin_p = par_valor1
FROM parametro
WHERE par_codigo_dominio = '000213' and par_codigo = 'FF'
SELECT #fecha_inicio = CONVERT(DATETIME, #fecha_inicio_p, 103)
SELECT #fecha_fin = DATEADD(D,+1,CONVERT(DATETIME, #fecha_fin_p, 103))
EXEC usp_p_broad_maestra_docvar #fecha_inicio,#fecha_fin,'E'
END TRY
BEGIN CATCH
select #vc_mensaje_error = ERROR_MESSAGE();
raiserror(#vc_mensaje_error,16,1)
END CATCH
The stored procedure does:
Truncate a table
Insert Into Select... UNION SELECT.... UNION SELECT...
call a job to use ssis to generate a file
Write Log
The problem is than when I execute the job, it never terminates and I have to cancel execution.
But when I don't use a stored procedure and the code put into JOB the job terminates ok.
Please your help maybe there are differences in the execution a stored procedure into job versus execute stored procedure code into job.
Thanks
Related
I have a stored procedure A on server 1 that takes 2 parameters from the user, and then using a linked server (ew), pulls in the results (a table) from server 2.
ALTER PROCEDURE [DW].[StoredProcA]
#InvFromDate date OUTPUT,
#InvToDate date OUTPUT
AS
WITH CTE_Labor AS
(
SELECT blabla
FROM LinkedServer.Database.schema.table
<lots more ctes, etc.>
For performance, I'd like to instead have a stored procedure A still accept the 2 parameters, but then pass them on to stored procedure B that sits on Server 2, and return those results back to the user.
Say - I can put the stored procedure on server 2, and call it from Server 1
DECLARE #return_value int
EXEC #return_value = [LinkedServer].[DB].[Schema].[StoredProcB]
#InvFromDate = '2022-10-01',
#InvToDate = '2022-10-31'
That works.
But I'm not clear on the syntax to do the above, but have those 2 parameters be entered by the user in stored procedure 1.
Clearly this attempt is wrong:
ALTER PROCEDURE dbo.StoredProc1
#InvFromDate DATE,
#InvToDate DATE
AS
BEGIN
DECLARE #return_value int;
EXEC #return_value = [LinkedServer].[DB].[Schema].[StoredProcB]
#InvFromDate = #InvFromDate,
#InvToDate = #InvToDate;
RETURN #return_value;
END
Edit: Maybe this attempt isn't wrong.
It works when I right click and run the stored procedure, returning both the desired table and Return Value = 0. It just doesn't work when I point our front-end GUI at it. But that might not be a question for here.
Since you are already using a linked server you could utilise this openquery approach Insert results of a stored procedure into a temporary table
Noting the following:
OPENQUERY/ linked servers are generally bad but I'm sure you're all over this
parameter string concatenation is bad
Your wrapper proc has output parameters but I don't see any reason for it... so I've removed them. See if it makes a difference.
--
ALTER PROCEDURE [DW].[StoredProcA]
#InvFromDate date,
#InvToDate date
AS
DECLARE #sql VARCHAR(4000)
SET #sql = 'EXEC [DB].[Schema].[StoredProcB] #InvFromDate = ''' + FORMAT(#InvFromDate + 'yyyy-MM-dd') + ''',#InvToDate = ''' + FORMAT(#InvToDate,'yyy-MM-dd') + ''''
PRINT(#sql) -- for degbugging cause this never works first time
SELECT *
INTO #tmpTable
FROM OPENQUERY([LinkedServer], #SQL)
SELECT * FROM #tmpTable
Got it.
1.) For this method, have to go into the Linked Server, and set [Enable Promotion of Distribution Transaction] = FALSE.
2.) Syntax
Alter proc [dbo].[999_Test]
#InvFromDate date
,#InvToDate date
as
IF OBJECT_ID('tempdb..#tmpbus') IS NOT NULL drop table #tmpbus;
CREATE TABLE #tmpBus
(
Column 1 (datatype),
Column 2 (datatype),
etc. )
INSERT INTO #tmpBus
EXEC [LinkedServer].[DB].Schema.[StoredProcInLinkedServerO]
#InvFromDate,
#InvToDate;
select *
from #tmpBus
GO
I have written a stored procedure which executes a stored procedure and the result it gets has to be stored in a local temporary table. The Stored procedure gets created without giving any errors. But when I try to execute stored procedure, it returns the error that the temporary table is invalid object name.
CREATE PROCEDURE .dbo.CalulateETFWeights
-- Add the parameters for the stored procedure here
#CURR_DATE varchar(255),
#ETF_DATE datetime
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
--Select max(ETF_DATE) into #ETF_DATE from .dbo.ETF_LIST_V --where ETF_LOAD_DATE = #CURR_DATE
-- Insert statements for procedure here
SELECT TqaSecCode, GlobalSecurity, Cusip
into #tempetftable
from .map.v_get_tqa_security where cusip in (select distinct ETF_CUSIP from .dbo.ETF_LIST_V where ETF_LOAD_DATE = 'Mon Jun 17 14:15:09 BST 2019')
Insert into #tempPriceTable
exec .tqaif.sp_get_ds_price_usd
#sourceTable = '#tempetftable',
#startDate = '20181219',
#endDate = '20181219',
#frequency = 'D'
Insert into .dbo.ETFComponentWeights
Select
C.ETF_CUSIP as W_CAL_CUSIP,
C.STK_IDX as W_CAL_COMP,
C.STK_QUANT as W_CAL_SHARES,
CP.VALUE as W_CAL_PRICE,
(C.STK_QUANT * CP.VALUE_) as W_CAL_MVAL,
(C.STK_QUANT * CP.VALUE_)/SUM(C.STK_QUANT * CP.VALUE) over (partition by C.ETF_CUSIP) as W_CAL_WEIGHT,
#ETF_DATE as W_CAL_DATE
from .dbo.ETF_COMP_V C
inner join (Select E.CUSIP, P.Value_ from #tempPriceTable P inner join #tempetftable E on P.TqaSecCode = E.TqaSecCode) CP
on C.ETF_CUSIP = CP.CUSIP
So the error I get is
Invalid object name '#tempPriceTable'.
I don't understand why is this not working? Can anyone suggest what am I doing wrong here? and why the #tempetftable works fine. But #tempPriceTable here is not working in this scenario?
Syntax:
SELECT TqaSecCode, GlobalSecurity, Cusip
into #tempetftable
creates a new temp table and then inserts data into this new table.
Syntax:
Insert into #tempPriceTable
exec .tqaif.sp_get_ds_price_usd
is a regular "insert into" statement, which adds rows to existing table.
To use this syntax you need to create an empty temp table with correct schema beforehand.
So you need to do something like:
CREATE TABLE #tempPriceTable (your schema)
Insert into #tempPriceTable
exec .tqaif.sp_get_ds_price_usd
When exactly do we use stored procedures with output parameters and when do we use stored procedures without parameters?
I base my question on an example:
Stored procedure with output parameter
CREATE PROCEDURE uspGetContactsCountByCity
#City nvarchar(60),
#ContactsCount int OUT
AS
BEGIN
SELECT #ContactsCount = COUNT(ContactID)
FROM Contacts
WHERE City = #City
END
Stored procedure executing
DECLARE #ContactsTotal INT
EXEC uspGetContactsCountByCity #ContactsCount = #ContactsTotal OUT, #city = 'Berlin'
SELECT #ContactsTotal
Results: 2
Stored procedure without output parameter
CREATE PROCEDURE uspGetContactsCountByCity2
#City nvarchar(60)
AS
BEGIN
SELECT COUNT(ContactID)
FROM Contacts
WHERE City = #City
END
Stored procedure executing:
EXEC uspGetContactsCountByCity2 #city = 'Berlin'
Results: 2
Both procedures return the same result, in same form, so what's the difference?
Basically, the result you're seeing is actually the result of your SELECT at the end of the procedure, which is doing the same thing.
Please take a look at this documentation:
If you specify the OUTPUT keyword for a parameter in the procedure definition, the stored procedure can return the current value of the parameter to the calling program when the stored procedure exits. To save the value of the parameter in a variable that can be used in the calling program, the calling program must use the OUTPUT keyword when executing the stored procedure.
So basically if you would like your stored procedure to just return just a value instead of a data set, you could use the output parameter. For example, let's take the procedures you have given as an example. They both do the same thing, this is why you got the same result. But what about changing a little bit in the first procedure that has the output parameter.
Here's an example:
create table OutputParameter (
ParaName varchar(100)
)
insert into OutputParameter values ('one'), ('two'),('three'),('one')
CREATE PROCEDURE AllDataAndCountWhereOne
#name nvarchar(60),
#count int OUT
as
Begin
SELECT #count = COUNT(*) from OutputParameter
Where ParaName = #name
select Distinct(ParaName) from OutputParameter
End
Declare #TotalCount int
Exec AllDataAndCountWhereOne #count = #TotalCount OUT, #name = 'One'
Select #TotalCount
With this example, you are getting all the distinct stored data in the table, plus getting the count of a given name.
ParaName
--------------------
one
three
two
(3 row(s) affected)
-----------
2
(1 row(s) affected)
This is one way of using the output parameter. You got both the distinct data and the count you wanted without doing extra query after getting the initial data set.
At the end, to answer your question:
Both procedures gives us the same result, in same form, so what's the difference?
You didn't make a difference in your own results, this is why you didn't really notice the difference.
Other Examples:
You could use the OUT parameter in other kinds of procedures. Let's assume that your stored procedure doesn't return anything, it's more like a command to the DB, but you still want a kind of message back, or more specifically a value. Take these two examples:
CREATE PROCEDURE InsertDbAndGetLastInsertedId
--This procedure will insert your name in the database, and return as output parameter the last inserted ID.
#name nvarchar(60),
#LastId int OUT
as
Begin
insert into OutputParameterWithId values (#name);
SELECT #LastId = SCOPE_IDENTITY()
End
or:
CREATE PROCEDURE InsertIntoDbUnlessSomeLogicFails
--This procedure will only insert into the db if name does exist, but there's no more than 5 of it
#name nvarchar(60),
#ErrorMessage varchar(100) OUT
as
Begin
set #ErrorMessage = ''
if ((select count(*) from OutputParameterWithId) = 0)
begin
set #ErrorMessage = 'Name Does Not Exist'
return
end
if ((select count(*) from OutputParameterWithId) = 5)
begin
set #ErrorMessage = 'Already have five'
return
end
insert into OutputParameterWithId values (#name);
End
These are just dummy examples, but just to make the idea more clear.
An example, based on yours would be if you introduced paging to the query.
So the result set is constrained to 10 items, and you use a total count out parameter to drive paging on a grid on screen.
Answer from ozz regarding paging does not make sense because there is no input param that implements a contraint on the number of records returned.
However, to answer the question... the results returned by these stored procedures are not the same. The first returns the record count of contacts in given city in the out param ContactsCount. While the count may also be recieved in the second implement through examining the reader.Rows.Count, the actual records are also made a available. In the first, no records are returned - only the count.
Here is my procedure:
CREATE PROCEDURE spDelManu(
#manuName VARCHAR
)
AS BEGIN
SELECT * FROM tbProducts WHERE itemManu = #manuName
END
GO
Here I try executing the procedure, but nothing shows up.
EXEC spDelManu #manuName='EVGA'
But, if I run this query it will work and I get results. Why doesn't it work with the variable created in the proc?
SELECT * FROM tbProducts WHERE itemManu = 'EVGA'
sigh, always declare explcitly the length of your varchar:
CREATE PROCEDURE spDelManu(
#manuName VARCHAR(10)
)
AS BEGIN
SELECT * FROM tbProducts WHERE itemManu = #manuName;
END
As it was, it defaulted to a length of 1
You need to set a size for varchar
CREATE PROCEDURE spDelManu(
#manuName VARCHAR
)
AS BEGIN
select #manuName
END
GO
EXEC spDelManu #manuName='EVGA'
returns: E
Bad habits to kick : declaring VARCHAR without (length) - Aaron Bertrand
Be easy on me... still a newbie T-SQL programmer :)
I have a Stored Procedure that is intended to take three input parameters, evaluate them and send back one parameter (#eligible). If I just execute a T-SQL script with variables hard coded in, my ##ROWCOUNT sets #eligible to 1. When I EXECUTE a call to it as a stored procedure, it does not return #eligible correctly. Here is the procedure:
ALTER PROCEDURE [dbo].[proc_Eligible]
(#control AS nvarchar(10),
#checkno AS nvarchar(10),
#event_type AS nvarchar(7),
#eligible AS bit OUTPUT)
AS
BEGIN
SET #eligible = 0
SELECT #control AS Control, #checkno AS CheckNum
-- Is the check drawn on an eligible bank?
SELECT
H.CONTROL,
H.NAME,
H.RECV_DATE,
H.CHECK_NUM,
H.BANK,
SUM(D.RECV_AMOUNT)
FROM
[ZZZ].[dbo].[MRRECVH] H INNER JOIN
[ZZZ].[dbo].[MRRECVD] D ON H.control = D.CONTROL
WHERE
BANK IN (SELECT
RIMAS_Code
FROM
[Custom].[dbo].[Bank_Account])
AND H.CONTROL = #control
AND H.CHECK_NUM = #checkno
GROUP BY
H.CONTROL,
H.BANK,
H.NAME,
H.CHECK_NUM,
H.RECV_DATE
HAVING
SUM(D.RECV_AMOUNT) > 0
IF ##ROWCOUNT > 0
SELECT #eligible = 1
END
(On the next to last line, I have tried 'SET #eligible = 1', but that didn't make any difference).
To call the procedure:
DECLARE
#eligible AS bit
EXECUTE proc_Eligible
#Control = '3034'
,#Checkno = '5011'
,#event_type = 'update'
,#eligible = #eligible
SELECT #eligible
As I mentioned, if I isolate the stored procedure SELECT statement and hard code the variables, it works great, so it's probably my newbie inexperience with passing data.
(#event_type will be used later when I adapt this into a table trigger)
Thank you,
Kevin
It seems that you have to specify OUTPUT keyword as well, when you call your stored proc:
EXECUTE proc_Eligible
#Control = '3034'
,#Checkno = '5011'
,#event_type = 'update'
,#eligible = #eligible OUTPUT -- <--- mark parameter as output