Site sponsored by: Idera Try Idera’s new SQL admin toolset
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


Article Topics

All Articles
Peformance Tuning
Audit
Business Intelligence
Clustering
Reporting Services
Developer
General DBA
ASP.NET / ADO.NET

SQL Server 2008 - Worth the Wait

SQL Server’s first significant upgrade in three years features a number of envelope-pushing enhancements and improvements. Which will have the greatest impact on SQL administration and development? More...
Latest Articles

Slowly Changing Dimensions in SQL Server 2005
Audit Data Modifications
SQL Server 2008’s Management Data Warehouse
Same Report but Different Methods in SQL Server Reporting Services ...

More     
 
Latest FAQ's

SSIS Lookups are Case Sensitive
Convert Number to Words in SSRS
After installing SP2 on SQL Server 2005 x64, when trying to ...
Remote Name Could not be Resolved in SQL Server Reporting Services ...

More     
   
Latest Software Reviews

SQL Server DBA Dashboard
SwisSQL DBChangeManager
SQLMesh - SQL Server Search Tool
SoftTreeTech SQL Assistant

More     

articles >> general dba >> How to Find a SQL Server Database ...

How to Find a SQL Server Database Object

By : Ashish Kaushal
Jan 09, 2004
Printer friendly

How many times, we as a SQL developer or DBA, find ourselves shuffling through objects in Enterprise Manager, or expanding the left pane of Query Analyzer, trying to find a table or view for which we have no clue, except a nearly correct name, and the only way we would know that it is the right object is looking at its meta data or text. Well, it might not be an every day kind of thing, but it does happen from time to time (or perhaps not in an idealistic situation where all databases are well documented and all names follow a well defined naming convention with no exceptions, and most of all, the employees never quit).

A better why to find a SQL Server object, such as a table, a procedure, or a trigger, would be to query the sysobjects system table in the local database (of course, one has to be certain about which database that object is supposed be in).

For example:

Select * From sysobjects Where name like ‘ClientInvoice%’

(Script I)

Executing the above query displays all the objects in current database whose name starts with "ClientInvoice". If the type of the object to be searched is known, then the query can be changed to provide only that type of object whose name start with "ClientInvoice". This might return a much smaller and more readable resultset.

For example:

Select * From sysobjects Where xtype = ‘U’ And name like ‘ClientInvoice%’

-- ‘U’ for user table

(Script II)

The main shortcoming of above methods is that the sysobjects table is database specific. If one does not know which database contains the object, then the above query has to be run in all the databases to find the object.

Is there an easier way to write a query which searches all the databases in a single step to locate a specific object and/or of a specific object type? The answer is yes, by using the handy sp_MSforeachdb procedure.

For example:

Exec sp_MSforeachdb 'Select * From ?..sysobjects where xtype= ''U'' And name like ''ClientInvoice% '''

(Script III)

Sp_MSforeachdb is an undocumented (also means unsupported) procedure available in both SQL Server 7 and SQL Server 2000. It takes one string argument, which in our case is same as Script II, but there is one important difference, if we look carefully at Script III, it has “From ?..sysobjects” instead of simply “From sysobjects” as in Script II.

Why ? This is important, because sp_MSforeachdb uses dynamic SQL internally, and “?” is the placeholder for the name of the database, it keep substituting “?” with the name of each database as it loops through all the database names, thereby accessing the sysobjects table in each database in a cycle, in sequence. Suppose if there are n databases, if we do not supply “?” than sp_MSforeachdb of-course loop through the n databases but keep accessing sysobjects table of the current database (that is the database we are running this query in) n-times.

Now that we know “?” is, the placeholder for the name of database, why not try to write a script which could provide a result set with name of database, name of object, and type of object.

-- Part 1
Declare @sqlstr nvarchar(200)

-- Part 2
/* drop the temporary table if already exists */
If Object_Id(‘tempdb..#tblDBObjects') is Not Null
Drop table# tblDBObjects
/* create temporary table */
Create TABLE #tblDBObjects (
dbName sysname,
objName varchar(200),
objtype char(2)
)


-- Part 3
/*assign string value to variable */
Select @sqlstr = 'sp_msforeachdb ''Insert tblDBObjects select ''''?'''' as DBName, name, xtype From ?..sysobjects'''
/* execute SQL string */
Exec sp_executesql @sqlstr


-- Part 4
/* select from temp table */
Select * From #tblDBObjects Where name like ‘ClientInvoice%’
RETURN


(Script IV)

 

Explanation of the Above Script

Part 1 of the script simply declares variable with the nvarchar datatype. This is because the string, which is to be executed with the sp_executeSQL procedure, must be of nvarchar type.

Part 2 checks to see if the temporary table with the name tblDBObjects already exits. If temporary table tblDBObjects exits, it drops it. Then it creates a temporary table with the name #tblDBObjects. ‘#’ tells that the table should be temporary, so is created in the tempdb database. A temporary table is automatically dropped once the script completes execution successfully.

Part 3 create a SQL string which inserts the values in #tblDBObjects as it loops through databases and select values from the sysobjects table. The reason for using this string and sp_ExecuteSQL is, that it could enable us to provide object type as an input in case we want to write a stored procedure and pass the object name, as well as object type, as input parameters. Providing object types would extract smaller result set and might also speed up operation where there are too many enormous databases. This has been explained in Script V.

Part 4: Once the temp table has been populated, records can be pulled out as needed.


    Next Page>>    








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views