I am trying to get everything
find all the tables, views, stored procedures, scalar functions, table functions, schema using sql query of a specific database
I actually wanted to create a autocomplete option but as of now my first step is to get everything in a list but not sure how i will get all of the above of a specific database
This is a bit long for a comment.
You need to look into the system tables. Personally, I prefer the standard INFORMATION_SCHEMA views, but the information you want is spread out.
In SQL Server, you can use sys.objects, paying attention to the object type. The place to start learning about it is in the documentation.
Related
I have some code like this
select *
FROM [ServerName].[theserver].[dbo].[OrderWrappers]
My server name changed so now the above doesn't work and instead it would be
select *
FROM [NEWServerName].[theserver].[dbo].[OrderWrappers]
I access that table across lots of different places and many different jobs and stored procedures.
Is there anything I can do besides going into each stored procedure one my one and changing the code?
Well, yes and no.
You will need to go through the code to change the code. However, you can change the code to use synonyms instead of hard-coded references. Then, the next time you change the server, it will be pretty easy to update the code.
Or instead of synonyms, you could create a separate project with views to the tables on the remove server and use those views. Those would also be simple to update.
Both of these methods, though, require modifying the existing code. But they will help you write code for the future so you don't have this problem in the future.
While most SQL Databases allow you to create a view, Microsoft Access has saved queries. I have read that Access Queries are not the same thing as SQL views, but that’s a sweeping statement.
I am aware that they have some differences in detail. For example Access saves SELECT * as is, while most saved views spell out the field list.
Aside from details such as these, is there a fundamental difference between the two?
Thanks
An Access "saved query" is more than a view in SQL Server (where "more" doesn't mean that it is better or not). In SQL Server you have the SQL text and the execution plan which defines a view. You can also add additional informations like description text or user defined variables with user defined values which have no influence on the view itself.
In Access you work with QueryDef objects, which are in fact the "saved queries", they contain a lot more than only the SQL text which is only one property of the QueryDef object. For example, you can define parameters with the PARAMETERS clause which can be used similar to #-variables in SQL Server stored procedures/functions. That's something which doesn't exist for SQL Server views. Of course a QueryDef object has also a saved exection plan, that's why Microsoft also recommends to use a QueryDef as i.e. form RecordSource instead of a dynamic SQL command at the same place. The JET/ACE query optimizer's result can also made visible with some registry tricks, it's only not part of the Access GUI so most people don't know that it also has an execution plan.
QueryDef objects contains also formatting properties, captions to be displayed in Datasheet view, definition of lookups for comboboxes, ODBC connection strings and a lot more, you can find them all in the Access help.
So Access QueryDefs contains a lot which only affects the display of the result which makes sense for a frontend which you can develop with Access, but they do not have very much advantages in comparison with SQL Server views. One simple difference is the SQL language: Independent of the backend you use you are working with Access SQL and this SQL is really a very basic SQL. T-SQL on SQL Server for example is a very powerful SQL language where you can do a lot more with - for example, you can query a hierarchical structure like a BOM (Bill Of Material) with one SQL statement which you can't with Access SQL as T-SQL can use recursive SQL. In Access it would only be able by using VBA functions in Access SQL which slows down the complete query a lot.
Of course a QueryDef object in Access can also use so called "Pass-Through-Queries" which executes i.e. T-SQL directly without using Access SQL. But as the SQL text is saved locally in Access it is handled as dynamical SQL in SQL Server because the text is sent each time it is executed and SQL Server has no saved view for that, so all the advantages of a saved view are lost. It's better to avoid them or use them only to execute saved views, functions or stored procedures on SQL Server.
A QueryDef object is moreover a DAO object and that means that you are working with DAO datatypes always. So even in case of a Pass-Through-Query the data is always converted from SQL Server (or of course other database) datatypes to DAO datatypes.
Easier deployment like mentioned above: Here's no big difference in using a view or a QueryDef in Access if both are used for frontend purposes like a form's RecordSource property. The reason is that a QueryDef and a view would both need to be implemented in the frontend, the QueryDef need to be changed locally, the view can be changed in the backend, but as it is in most cases linked to the frontend as linked table you need to delete this link in the frontend and recreate it in case of changes of the view so you also need to redeploy the frontend again (that's why I personally prefer ADPs instead of ACCDBs because in ADPs I work in Access directly with the view and not with any QueryDef so here a change in the backend is enough to reflect it in the frontend).
Independent of that you would also need to redeploy the frontend if you change a fieldname in the view you use in the frontend.
It is another thing if you use the view only in the backend to assemble data for other backend purposes like using it in a stored procedure or another view. If they are not linked to the frontend you don't need to redeploy the frontend. So as with stored procedures and functions it is also true for views that you can quickly change something in the backend if you need to fix something which doesn't affect the frontend directly. I.e., if you concatenate two text fields with a "." with an alias name and someone tells you that it now must be a "-" instead you can simply change the view and it's done, nothing to change in the frontend (if you have no further logic in the frontend which needs to check for the dot).
SELECT *
"spells out the field list" is indeed what a SQL Server view does, the problem is: It saves a list of fields of the table object you use in the SELECT at the time you save the view. But it doesn't save this field list visibly. If you open the view's SQL text you will always only see the "*", not the field list the view has saved. This is a big problem in SQL Server as you would expect that it lists all fields that the table has at all times (that's what Access does in a QueryDef object with SELECT *). So even if you use a tool like RedGate's free SQL Search you would not find that view as you have not the field list in the SQL text so the field name of a changed table field cannot be found.
In general avoid the "SELECT *" whereever possible as it produces more problems than that it has any advantage. Always use the list of fields you really want as result. In Access those field names will automatically be changed if you change the field name in a table (if you have AutoRename on in Access options), in SQL Server you can search for all objects using a specific field and change it.
One exception would be if you use a CTE in SQL Server where the last SELECT selects all fields of previous SELECTs in the CTE. Here it is no problem to use the asterisk as the field names are (should) be listed in the previous SELECTs of the same query. But in general it's better to more often avoid using it as using it for production purposes.
These are only examples of differences between both, there are a lot more like mentioned above (indexed views, security model) or something like schema names but this should give you a picture.
Very broadly speaking Views offer:
Performance
Benefit from Execution Plans which in the case of non-index Views will analyse the query using the View and the queries that make up the View definition. These plans are then stored so that repeated and/or similar queries can retrieve data faster. For reference: View Resolution
Indexed Views for situations such as when the underlying tables are not hugely transactional (OLTP) and dataset is large and requires aggregation such as in OLAP sources. For reference: Improving Performance with SQL Server 2008 Indexed Views
Security
Allows you to present a subset of data without granting access to the base Views or Tables that make up the View.
Easier Deployment
With Access, you make a change to your saved query, you would most likely have to roll-out that Access database to all users. With a View, you make a change and that'll affect all users.
Regarding the last point, that assumes you aren't changing identifiers in the View that are referenced elsewhere. A simple example would be changing a column name in the View. This would most likely require name changes in other dependent database objects or external tools that access it.
I am aware that they have some differences in detail. For example Access saves SELECT * as is, while most saved views spell out the field list.
That's not strictly true. It's generally preferred to identify columns by name in a View since they represent a subset of data and it restricts what data is seen by the end-user. That said, in general, any SQL query you can obviously restrict columns that are included, whether it's an Access Query or not. But you'll still come across Views with SELECT * so it's not a difference per se.
If all SQL is doing is SELECT, is there an advantage to using a view vs a SPROC.
From my point of view, it's purely organizational, but I am wondering if there is a good reason for using views when all a SPROC is doing is SELECTs and has no writes to the DB.
I'm on Sql Server 2008 but this can probably apply to other SQL server products
Views are meant to abstract out the details of the underlying table and provide a window to the data, the way you want it to appear.
Stored procedures achieve a specific task and optionally take parameters that would be used during the task execution.
If you would like to run a specific task by taking arguments from the users, then you can create a stored procedure.
If you just want to expose data in a given way and leave further filtering, if required, to the users, you can create a view.
Other than the security advantage of encapsulating specific data for specific roles, there's also the advantage of being able to create an index on the view.
Here are some specific performance advantages, from the MSDN link:
Aggregations can be precomputed and stored in the index to minimize expensive computations during query execution.
Tables can be prejoined and the resulting data set stored.
Combinations of joins or aggregations can be stored.
These days I am importing quite a lot of databases from my server and working on them locally. In the process, I am making a number of changes to the table structure and in the process using some complex SQL statements to add the table columns.
Keeping track of everything in a separate file is beginning to be a pain and am wondering if there is a way to do this directly in the SSMS so that I can store the instructions along with the database. Is there any way this can be done or do I have to resort to writing documentation outside SQL Server?
Of course, I can always create a stub table called comments and put everything there but I was looking for a way to associate comments with a particular database or tables. Any suggestions would be greatly appreciated.
SQL-Server handles commenting on database objects through Extended Properties:
http://msdn.microsoft.com/en-us/library/ms190243.aspx
Is there a way to make a schema diagram from an SQL Server database using the stored procedures of this database?
I don't mind if I must use an external software.
You could try playing around with CodeSmith Generator. It's SchemaExplorer Schema Discovery API allows you to programmatically access database elements for a given database and do something creative with it. However, it will still be logically hard to reverse-engineer a schema/diagram this way.
You can build a SQLCLR procedure which uses the Scripter Class from the SMO library.
update: more info on the question reveals the idea is to generate a table schema with dependencies based on the content of the stored procedures.
The approach would be to generate the table structure from the information_schema views and then parse the contents of the syscomments table to figure out the relations. This will always be approximate as it is very hard to establish the one-to-many relationships purely from the SQL Statements. I think you can make a guess based on the field which is referenced more.
If you can't see the tables then you can not generate the schema.
That is, you can't if you have permissions on stored procedures only.
At least two reasons:
the stored proc may JOIN and use several tables
you can't see constraints, indexes, keys etc even if you had table names
Basically, you can only:
see what you have permissions on in SSMS etc
see the internals if you have VEIW DEFINITION rights
Edit, after clarification
There is no way to script implied aspects (such as missing foreign keys) of the schema from code