I'm working with a legacy DB which has 100's of stored procedures, views and materialized views. Now I have to introduce a column in one of the table and want to check everything is working in order as before.
I'm looking for a query which can go and compile all the stored procedures under my schema, run all the views/materialized views by fetching 10 rows from them. Can you please help me with that?
Thanks,
-Mike
Related
I'm in a Data Warehouse environment where tables are generated by stored procedures, the stored procedures reference other tables, and those referenced tables are created by other stored procedures, and so on etc. I'd like to, for a given procedure or table, be able to trace back all the way to the source tables, effectively constructing a dependency chain for the given object.
I can use sys.dm_sql_referenced_entities for procedures and sys.dm_sql_referencing_entities for tables but these only reveal the first link in the chain. Presumably this is some kind of recursive query that stops when it finds no more dependencies? Has anyone done this before and can share how to do it?
Thank you.
We have recently moved our database from Access to SQL Server and I am wanting to recreate an Access query in SQL Server. This query has been design with several sub-queries in it. Here is the access design view for the main query:
Has anyone got any ideas of how to achieve this is SQL Server?
I can create some of the sub-queries as views, as they do not call for any parameters to be passed through to them.
My problem is about how to create Sub-queries B and C. Would I create these as temporary tables or separate stored procedures which I can the call from within the main stored procedure?
Any help or links is greatly appreciated as I am stuck as to where to start.
Hopefully, a simplified version of how the 6 Access queries interact with each other. Query F is the query that is run from an Access report.
Might seem like a strange question but we have a situation where we can't add tables to the local db. So I was wondering, if it's possible to place the tracking table on a different db.
maindb:dbo.staff
main2db:dbostaff_tracking
I don't think you can and haven't found anything to indicate it but hey lets make use of shared knowledge.
you can script out the provisioning of the sync objects. you can manually alter the scripts to change the db for the change tracking tables but you will have to alter the triggers and the other stored procedures to do cross-db queries as well.
I inherited a SQL server database that is not well formatted. ( some consulting company came in to do the project and left without completing it)
the main issues I have with this database are:
Data types: a lot of tinyint and text types.
Tables are not normalized: some of the keys are names instead of seq ids.
A lot of tables that I am not sure are being used
a lot of stored procedures that i am not sure are being used
Badly named tables and stored procs
I also inherited the asp.net application that runs against this database.
I would like to clean this database up. I understand that changing the datatypes will have to happen at each table. for getting rid of all the extra tables and stored procs. what is the easiest way to do so.
any other tips to make it cleaner and smaller is appreciated.
I want to also mention that I have RedGate tools installed.( if that helps).
Thank you
Check out the Sql Server Data Tools they allow to create a project from a live database. Some of the things you can do in there is right click 'Find Usages' for the tables, views and functions.
So long as the previous developer used stored procedures and views rather than querying directly, it should find references to your project that way, without killing your project.
Also, for finding stored procedures that are not used, put in some basic logging at the top of each stored procedure in your application, after X amount of days, those that haven't been logged in your table are likely safe to remove, else a tedious search through your .NET code will find them.
I have a TON of views that are rather long and dependent/depended on other views. I also have some stored procedures that need to be run weekly and these procedures need to use some of the SQL statements in the views so instead of putting the statements in the procedures I was hoping I could just run the view.
Is that possible? I'll be running these from SQL Server 2008 btw
SQL 101:
A Select statement can be run on a table or view.
So, yes, any code that can access at able can also access a view. Given the necessary permissions.
As I said - this is beginner SQL knowledge. I will add it to my list of interiew questions for junior developers.
A stored procedure is, in essence, nothing more than a canned ad-hoc statement. Yes, it offers many other features but the point is anything you can type in an interactive query window can also be run in a stored procedure.
Views are not restricted to being run in a stored procedure.
Yes you can query tables and views inside your stored procedure.