I have a stored procedure (see below) which inserts data into a physical table and then joins information with sys.databases. I was thinking that would it be better to not have a physical table for data insertion? Would it be better to fetch these results into a table variable within this procedure? If so, how to do that?
CREATE PROCEDURE dbo.PROC_getDbInfo
AS
SET NOCOUNT ON
GO
TRUNCATE TABLE dbo.dbinfo
GO
EXECUTE sp_msforeachdb 'insert into dbo.dbinfo
select ''?'' as name,
type_desc,
physical_name,
state_desc,
size * 1.0/128 as size_in_mb,
max_size,
growth * 1.0/128 as growth_in_mb,
is_percent_growth,
is_read_only
from [?].sys.database_files'
GO
SELECT ##SERVERNAME as instance_name,
f.name,
d.create_date,
d.compatibility_level,
d.collation_name,
d.user_access_desc,
d.state_desc,
d.recovery_model_desc,
d.page_verify_option_desc,
d.log_reuse_wait_desc,
f.type_desc,
f.physical_name,
f.state_desc,
f.size_in_mb,
f.max_size,
f.growth_in_mb,
f.is_percent_growth,
f.is_read_only
FROM dbo.dbinfo AS f INNER JOIN
sys.databases AS d
ON f.name = d.name
ORDER BY f.name
GO
You'll have to use a table. Either global temp (##) or a normal table.
A table variable will not be in scope for the sp_msforeachdb call if declared for the stored proc, and not visible to the stored proc if declared in sp_msforeachdb
#table is better -- the table is small and the i/o cost will slow it down.
Table variable usage is explained here:
http://msdn.microsoft.com/en-us/library/ms175010.aspx
It basically behaves like a table when it comes to how your script looks - but has very different behaviour under the hood, and if it's small enough should not result in any disc IO.
Also, if the table is only used and then removed during the course of a procedure, this scope limitation becomes a argument for using it.
Related
I have a script which searches through all the available databases (those I have access to) for a specific text in a procedure.
In my server, there are many databases (in my case about 150 databases), meaning that I get shown the results for all databases eventhough there are no results for most of them (about 90%).
Is there any way to avoid getting these empty result-queries?
You can use below code to check whether stored procedure contains a text in each database. If there are stored procedures in a database only, you will have resultset.
CREATE TABLE ##DatabasesContainingSP(dbname sysname, SPName SYSNAME);
EXECUTE master.sys.sp_MSforeachdb 'USE [?];
INSERT INTO ##DatabasesContainingSP
SELECT DISTINCT
db_name() as dbname, o.name AS Object_Name
FROM sys.sql_modules m
INNER JOIN
sys.objects o
ON m.object_id = o.object_id
WHERE m.definition Like ''%ABC%'';
'
IF EXISTS(SELECT * FROM ##DatabasesContainingSP )
begin
SELECT * FROM ##DatabasesContainingSP
end
GO
IF OBJECT_ID('tempdb..##DatabasesContainingSP' , 'U') IS NOT NULL
drop TABLE ##DatabasesContainingSP;
Thank you for the quick responses.
I managed to solve it by creating a table and adding insert into this table in the beginning of my generated and concatenated code, which solved the problem since when reading the table in the end, it only shows the inserted results.
With kind regards,
Alexander
Is there an easy way in SQL Server (2010) to exec a stored procedure (that returns a table) and sum a column in one (or a few) statements?
eg
SELECT SUM(column) FROM exec proc_GetSomeStuff 'param1', 'param2'
Don't have a server handy to test with, but try this:
declare #temp table(col1 int)
insert into #temp(col1)
exec proc_GetSomeStuff 'param1', 'param2'
select sum(col1) from #temp
Make sure your table variable (or temp table) has the same schema as the results of the stored procedure. If you know that there will be a significant number of rows coming back from the SP, then a temporary table might be a better option. (I'm not sure if table variables can be flushed out to disk if they get too big)
Compare the following stored procedures:
CREATE PROCEDURE testProc1
AS
SELECT * INTO #temp FROM information_schema.tables
SELECT * FROM #temp
GO
CREATE PROCEDURE testProc2
AS
EXEC('SELECT * INTO #temp FROM information_schema.tables')
SELECT * FROM #temp
GO
Now, if I run testProc1, it works, and #temp seems to only exist for the duration of that call. However, testProc2 doesn't seem to work at all, since I get an Invalid object name '#temp' error message instead.
Why the distinction, and how can I use a temp table to SELECT * INTO if the source table name is a parameter to the stored procedure and can have arbitrary structure?
Note that I'm using Microsoft SQL Server 2005.
From BOL:
Local temporary tables are visible
only in the current session... ...
Temporary tables are automatically
dropped when they go out of scope,
unless explicitly dropped using DROP
TABLE
The distinction between your first and second procedures is that in the first, the table is defined in the same scope that it is selected from; in the second, the EXEC() creates the table in its own scope, so the select fails in this case...
However, note that the following works just fine:
CREATE PROCEDURE [dbo].[testProc3]
AS
SELECT * INTO #temp FROM information_schema.tables
EXEC('SELECT * FROM #temp')
GO
And it works because the scope of EXEC is a child of the scope of the stored procedure. When the table is created in the parent scope, it also exists for any of the children.
To give you a good solution, we'd need to know more about the problem that you're trying to solve... but, if you simply need to select from the created table, performing the select in the child scope works just fine:
CREATE PROCEDURE [dbo].[testProc4]
AS
EXEC('SELECT * INTO #temp FROM information_schema.tables; SELECT * FROM #temp')
GO
You could try using a global temp table (named ##temp not #temp). However be aware that other connections can see this table as well.
I have a stored procedure in a test instance of a sql server (named sql2008test\sql2008_test) and it is located in one database. I would like to use this procedure also in production instance (named sql2008prod\sql2008_prod). Should I copy this procedure into this prod instance or can I modify my procedure somehow to query data from prod instance? The procedure is shown below.
CREATE PROCEDURE dbo.PROC_getDbInfo
AS
SET NOCOUNT ON
TRUNCATE TABLE dbo.dbinfo
EXECUTE sp_msforeachdb 'insert into dbo.dbinfo
select ''?'' as name,
type_desc,
physical_name,
state_desc,
size * 1.0/128 as size_in_mb,
max_size,
growth * 1.0/128 as growth_in_mb,
is_percent_growth,
is_read_only
from [?].sys.database_files'
SELECT ##SERVERNAME as instance_name,
f.name,
d.create_date,
d.compatibility_level,
d.collation_name,
d.user_access_desc,
d.state_desc,
d.recovery_model_desc,
d.page_verify_option_desc,
d.log_reuse_wait_desc,
f.type_desc,
f.physical_name,
f.state_desc,
f.size_in_mb,
f.max_size,
f.growth_in_mb,
f.is_percent_growth,
f.is_read_only
FROM dbo.dbinfo AS f INNER JOIN
sys.databases AS d
ON f.name = d.name
ORDER BY f.name
GO
Run the creation script on your production instance (of course, going through any release processes you have). You could set up linked servers, if you can access your production server from your test instance, but I wouldn't head down that route without a good reason.
BTW, you still have the extra GO statements in that script meaning the sproc will ONLY be created with SET NOCOUNT ON in and won't do anything.
Use Server Objects>Linked Servers so you can select between different instances.
Copy your procedure into Production db.
Is there a way to know what are the tables used by one stored procedure by doing an SQL query?
Best regards, and thanks for the help.
P.S.: I'm using SQL Server 2005.
This article on TechRepublic
Finding dependencies in SQL Server 2005
describes a way to do that:
This tutorial will show how you can
write a procedure that will look up
all of the objects that are dependent
upon other objects.
Here is the code to create the system stored procedure for finding object dependencies:
USE master
GO
CREATE PROCEDURE sp_FindDependencies
(
#ObjectName SYSNAME,
#ObjectType VARCHAR(5) = NULL
)
AS
BEGIN
DECLARE #ObjectID AS BIGINT
SELECT TOP(1) #ObjectID = object_id
FROM sys.objects
WHERE name = #ObjectName
AND type = ISNULL(#ObjectType, type)
SET NOCOUNT ON ;
WITH DependentObjectCTE (DependentObjectID, DependentObjectName, ReferencedObjectName, ReferencedObjectID)
AS
(
SELECT DISTINCT
sd.object_id,
OBJECT_NAME(sd.object_id),
ReferencedObject = OBJECT_NAME(sd.referenced_major_id),
ReferencedObjectID = sd.referenced_major_id
FROM
sys.sql_dependencies sd
JOIN sys.objects so ON sd.referenced_major_id = so.object_id
WHERE
sd.referenced_major_id = #ObjectID
UNION ALL
SELECT
sd.object_id,
OBJECT_NAME(sd.object_id),
OBJECT_NAME(referenced_major_id),
object_id
FROM
sys.sql_dependencies sd
JOIN DependentObjectCTE do ON sd.referenced_major_id = do.DependentObjectID
WHERE
sd.referenced_major_id <> sd.object_id
)
SELECT DISTINCT
DependentObjectName
FROM
DependentObjectCTE c
END
This procedure uses a Common Table
Expression (CTE) with recursion to
walk down the dependency chain to get
to all of the objects that are
dependent on the object passed into
the procedure. The main source of data
comes from the system view
sys.sql_dependencies, which contains
dependency information for all of your
objects in the database.
Try sp_depends, although you should probably recompile the stored procedure to update the statistics in the database.
Look up sp_depends system stored proc.
I think that as long as the stored procedure and the tables are all in the same database then you can right click on the procedure in SSMS and click "View Dependencies". I don't know the query behind the dialog though...
As others indicated you can use the Dependancies stored procedures; however, in my experience and this was back on SQL Server 2000, the depandancies were not always reliable. In some cases they weren't being updated. You can always go to the sysComments table assuming your schema is not encrypted.
declare #crlfSearch varchar(max),#objectSearch varchar(max),#escapeSearch varchar(max)
set #crlfSearch=('%bid' + char(13)+'%')
set #objectSearch='%bid %'
set #escapeSearch ='%[[]Bid]%'
select distinct so.name
from syscomments sc
inner join sysobjects so
on sc.id=so.id
where text like #objectSearch or text like #crlfSearch
or text like #escapesearch
This query looks for three common cases you might have to add some but basically we find where the table name has a space after it, (This helps to limit cases where the table name is part of another table name), Has a return at the end of it, or is escaped within brackets.