October 1, 2010 at 1:21 am
Hi I have this t-sql in my stored procedure. He only fires the first insert into statement. Did a lookup in google, but didn't find anyhting about this easy scripting
AS
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
insert into tbl_sepia_stats
select getdate(), 'Sales Line', count([timestamp])
FROM [NAV_SEPIA].[dbo].[OPS Sepia$Sales Line]
go
insert into tbl_sepia_stats
select getdate(), 'Job Ledger Entry', count([timestamp])
FROM [NAV_SEPIA].[dbo].[OPS Sepia$Job Ledger Entry]
go
insert into tbl_sepia_stats
select getdate(), 'Item Ledger Entry', count([timestamp])
FROM [NAV_SEPIA].[dbo].[OPS Sepia$Item Ledger Entry]
go
insert into tbl_sepia_stats
select getdate(), 'Warehouse Entry', count([timestamp])
FROM [NAV_SEPIA].[dbo].[OPS Sepia$Warehouse Entry]
go
what's wrong ?
JV
October 1, 2010 at 1:51 am
GO is a batch separator, so your SP is only executing up to the end of the first INSERT. Remove all but the final GO and you'll be sorted.
Check out GO in BOL.
October 1, 2010 at 2:03 am
hey
Thanx for your reply.
Thought I did it already without the go's and that it didn't work.
Removed them and it works
Feeling like a freshman... damn 🙂
Thx !!!!!!!
JV
October 1, 2010 at 2:10 am
Cath Trimble (10/1/2010)
GO is a batch separator, so your SP is only executing up to the end of the first INSERT. Remove all but the final GO and you'll be sorted.
To be a little more specific, the stored proc will only contain up to the end of the first insert as, when creating the proc, the GO signals the end of the stored proc creation code.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply