I have a table with a bunch of queries.
What I have to do is selecting records which has query using SQL Server system function.
It would be the best to select all system function names so that I can get it done with the subquery within a where clause.
The advice would be great.
We recommended that you use the system functions, Information Schema Views, or the system stored procedures to obtain system information without directly querying the system tables.
Source:
http://msdn.microsoft.com/en-us/library/ms191238%28v=sql.90%29.aspx
Related
I've seen something like this in SQL Server (running this query against the master database):
select * from tempdb..sysobjects
which seems to return exactly the same results as:
select * from tempdb.sys.objects
I've seen that the double dot can be used as a way to omit the schema name but I don't see anything omitted here, going by that logic then tempdb..objects would be valid which is not).
tempdb..objects will be interpretted as tempdb.dbo.objects
Both are two different system views
sys.objects
Contains a row for each user-defined, schema-scoped object that is
created within a database, including natively compiled scalar
user-defined function.
sys.sysobjects
Contains one row for each object that is created within a database,
such as a constraint, default, log, rule, and stored procedure
Note : This SQL Server 2000 system table is included as a view for backward compatibility. We recommend that you use the current SQL Server system views instead. To find the equivalent system view or views, see Mapping System Tables to System Views (Transact-SQL). This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
I would like to do the following in SQL Server (2008 + ):
Define a view, let's call it [MySchema].[MyTableInfo], that queries the SQL Server catalog views, e.g., [sys].[tables], to obtain a customized presentation of the underlying catalog metadata.
Install this view somewhere (in master?) so that it can be called from the context of any database on the server and return the metadata appropriate for that context, just as the catalog views do.
I have seen reference to techniques to do something similar with utility stored procedures, but this is a little different. Is what I'm wanting to do possible? If so, how?
Update:
I found an article that described how to do almost exactly what I want but with stored procedures. The routines are stored in the master database and marked as system objects. When they return metadata from the catalog views/information schema, the do so in the context of the current database.
Using stored procedures to execute these queries would be extremely inconvenient for my use case; is there not a way to mark views and/or table-valued functions as system objects and have them execute in the context of the calling database? I have hacked on this without success...
I have an user defined table function in SQL Server that aggregate data from several tables including a couple of tables of another database. That is done hardcoding the name of the database in the queries, but we want to make the database name configurable (because our databases usually share the server with the databases of other applications).
I tried to construct a dynamic query string inside the function using the database name that is stored in a configuration table, but:
When I tried exec(#sqlStatement) SQL Server said that execute string is not allowed inside a function.
Then I tried exec sp_executesql #sqlStatement and the function was created, but when you execute it SQL Server says that inside a function you can only run extended functions and procedures.
So the question is: is possible create a function or stored procedure that access a table in another database without having to recreate the function when the database name is different?
TIA.
I would really recommend that you settle on fixed database names, so you can avoid this entire problem of using dynamic sql. Can't you come up with unique database names like: your_company_name_XYZ and your_company_name_ABC? if that is not an option you will be doing lots of dynamic SQL, you should read The Curse and Blessings of Dynamic SQL by Erland Sommarskog
All of the restrictions you mention in the question are a limit of SQL Server functions. You can generate and execute dynamic SQL within a stored procedure with no problems.
I have a couple of questions.
1) Why cannot we see system tables (like sysobjects) under Master/Model/MSBD etc.? But we
can query. Are we basically querying the views, because as they are the main tables that
holds a value able informations?
Like "SELECT * FROM sysobjects". are we basically querying some views?
2) Why cannot we add triggers to system tables?
Thanks in advance
SQL Server 2008 system tables (http://msdn.microsoft.com/en-us/library/ms179932.aspx) have been implemented as read-only views. One cannot directly work with the data in these system tables. You can access SQL Server metadata using catalog views. Do check this link http://msdn.microsoft.com/en-us/library/ms174365.aspx
It is possible to create triggers on system tables but it is generally not recommended. Please check this http://www.sql-server-performance.com/faq/trigger_system_table_p1.aspx
cheers
Since SQL 2005 the catalog views are implemented as views declared in the Resource Database (mssqlsystemresource). Due to some special magic they appear to exist in every database.
You can always use the execution plan to see from what actual tables do these views fetch data from. The underlying tables can be accessed when you are connected with a DAC connection. Modifying the system tables in any way will mark the database and an message will be logged every time the database starts up. Modified databases are not supported by MS, so if something goes wrong you cannot ask for support.
SQL Server 2005. Is there a sql query that will return a text field containing the same type of schema info as you would find in doing a right click table -> Script Table As -> Create To (or Alter To) from SQL Server Management Studio ?
I'm looking for a single/flat format that describes the entire table, including constraints, indices, etc.
I am aware of:
sp_help table_name
but that doesn't provide the single flat format I'm looking for. Ideally it would be in a scriptable format, such as the AlterTo result that could be executed against the server.
This is for a scheduled process that documents table schemas on a nightly basis for checking in to version control (SVN).
Not really. A table def is a collection of columns, constraints etc.
There is an SVN plugin that may help called ScriptDB4SVN. I've not used it personally, I'm going on hearsay.
Was searching the 'net again for an answer to this, and came across this SO question. It doesn't accurately capture all the same data as SQL Management Studios Create-to, but enough for my purposes (scripting the database structure for version control purposes).
There is no such command in SQL Server. This is primarily because the Scripting facilitiy is actually in SMO and not in SQL Server itself. There are a number of free console command-line tools that can do it that you could call via xp_CmdShell.
However, if you really want to do this from T-SQL, then you will need a script or stored procedure that enumerates all of the tables attributes, columns, column datatypes, defaults, nullabilty, etc. etc. and then reassembles it into a CREATE TABLE script. This is a Huge task. That's the bad news. The good news is that someone (Lowell Izaguirre) has already done this and posted it in this article (http://www.sqlservercentral.com/scripts/Miscellaneous/30730/) at SQLServerCentral.Com.
Enjoy.
Not really - you can either use C# (or VB.NET) and SMO (SQL Management Objects) to script out your database objects (tables and all), or you can use SQL to get the list of columns for a table:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Your Table Name here'
But I don't know of any easy way in SQL itself to create Create/Alter scripts for database objects, sorry.
Marc