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...
Related
I need to share a few stored procedures into a single logic subset. In Oracle, I can create a "package" or class.
Is there a way do something similar in SQL Server 2012?
I don't want stay this procedures in main storage, I already have some hundreds of it.
Consider using different database schema (create your own) to logically separate your database objects (stored procedures). Packages don't exist in MS SQL.
I'm working on a desktop application that must support (currently) MS Access and SQL Server back ends. The application is under constant development and changes are frequently being made to the database, mostly the addition of tables and views to support new features (but also some DROPs and ALTER TABLEs to add new columns).
I have a system that compiles the DDL into the executable, checks the database to see if the executable has any new DDL that has to be executed, and executes it. This works fine for a single database.
My immediate problem is that SQL Server and Access support wildly different names for data types so a CREATE TABLE statement that executes against Access will not execute against SQL Server (or worse, will execute but create a table with different datatypes).
Is there a method that can be used to create DDL (especially CREATE TABLE commands) that can be executed through ADO against both of these databases without having to craft separate DDL for each provider?
Since you are already using ADO, you should look into Microsoft ADOX
This allows you to manipulate structures in a data source using an ADO object model that is independent of the underlying data source type. i.e. without resorting to explicit DDL
Support for ADOX is not guaranteed by any given ADO Provider, and the level of ADOX support may vary even when it is available. But for MS Access and MS SQL Server I think you will find all the capability you require (and quite possibly more!)
This can be done using DBX in Delphi.
The following is links to sample code showing how this can be done.
http://cc.embarcadero.com/item/26210
I had the same problem.
I resolved it applying a C preproccessor to the SQL before executing it.
The preprocessor includes macros in order to handle the different dbs.
Stefano
Did you check
http://db.apache.org/ddlutils/
or
http://publib.boulder.ibm.com/infocenter/wtelecom/v6r1/index.jsp?topic=%2Fcom.ibm.twss.plan.doc%2Fdb_scripts.html
Due to an employee quitting, I've been given a project that is outside my area of expertise.
I have a product where each customer will have their own copy of a database. The UI for creating the database (licensing, basic info collection, etc) is being outsourced, so I was hoping to just have a single stored procedure they can call, providing a few parameters, and have the SP create the database. I have a script for creating the database, but I'm not sure the best way to actually execute the script.
From what I've found, this seems to be outside the scope of what a SP easily can do. Is there any sort of "best practice" for handling this sort of program flow?
Generally speaking, SQL scripts - both DML and DDL - are what you use for database creation and population. SQL Server has a command line interface called SQLCMD that these scripts can be run through - here's a link to the MSDN tutorial.
Assuming there's no customization to the tables or columns involved, you could get away with using either attach/reattach or backup/restore. These would require that a baseline database exist - no customer data. Then you use either of the methods mentioned to capture the database as-is. Backup/restore is preferrable because attach/reattach requires the database to be offline. But users need to be sync'd before they can access the database.
If you got the script to create database, it is easy for them to use it within their program. Do you have any specific pre-requisite to create the database & set permissions accordingly, you can wrap up all the scripts within 1 script file to execute.
I'd like to add the "msdb.dbo.sp_help_job" system stored procedure to a LINQ to SQL object, but I can't figure out how to specify it. If I create a new Data Connection in Server Explorer and specify the "msdb" database of the server I want, and navigate to "Stored Procedures", that procedure is not listed. Am I looking in the wrong place?
I've added regular (user defined) stored procedures in the past with no problem. I know I could get there by executing it via "ExecuteCommand" on the data context, and I could also create a "wrapper" stored procedure that did nothing but call "sp_help_job", but I'd like to know how to hook it up directly to LINQ, or if it's even possible.
The System Stored Procedures are not actually sitting inside your database, but rather the Read-Only Resource database.
http://msdn.microsoft.com/en-us/library/ms190940.aspx
However, here's how you can make it possible to find them:
Accessing System Databases/Tables using LINQ to SQL?
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.