To find out how often SQL Server users use certain objects (mostly views), I would like to log who queried the object when. If possible, I would also like to indicate in the log whether the object was called directly or if the query was part of a chain. I suspect that policies can be of use here, but did not find an example.
The answer is "Audits" in the server and database security sections in Management Studio. We are using Enterprise Edition, so "Fine Grained Auditing" is available to us. It covers the requirements in question, even including the sql statement used to query the object.
Other editions offer "Basic Auditing", not sure how much that will give you.
Related
I'm interested in the existence of any tools which can perform static analysis against a SQL Server database. In essence, I'm looking for the DB equivalent of FxCop or NDepend; something which can inspect the data layer and come back with recommendations around metrics such as design, naming and any other measurable attributes relating to quality.
Has anyone used a tool in the past that can provide some design feedback? Thanks.
If you use SQL 2008, or have an instance of SQL 2008 anywhere, you can use policy based management. This will do what you want. Check Here This will work for naming and other standards, but might not work on data metrics.
You can alway use the Microsoft Best Practices analyzer for SQL
DataCleaner http://datacleaner.eobjects.org/
SQL Enlight is a dedicated static analysis tool for SQL Server, working in SSMS as well as part of Continuous Integration. There is a review on Simple Talk by Grant Fritchey. There are numerous built-in tests as well as a capability (albeit complicated looked) to author one's own checks.
SQL Cop is another option. It's not as sophisticated as SQL Enlight, and can't be automated as part of a build process, but is free.
I've just migrated from Access where I would "write" SQL constantly and quickly using their GUI layout. I'm very new to SQL Server and am puzzled why is there no query GUI in SQL Server. Is it just that much more powerful that a GUI wouldn't be able to address the majority of queries? Or is it like a purist thing where once one is no longer in watered down databases like Access that he or she should just know SQL well enough to write it on the fly. Or am wrong altogether, and there IS a graphical way that most programmers compose SQL?
Sorry for the umbrella question, but I think some theory here would help me understand the big picture better.
I think there is a Query Designer as part of Sql Server Management Studio: see for example SQL Server 2005 Management Studio Query Designer.
The SQL Server is a database server. That it self does not have any editor text or GUI. You can mange it from the console, or any dedicated software that might have or not a query designer.
The main difference between Access and SQL Server or any other database, is that the MS Access is application that store the data in a file, when You close "Access" anything can happen inside the database by it self, while you are using SQL Server it is alway on You only connect to it. That why access have build nice query, report form designers. The SQL Server has totally different job to do and does not need this. With SQL Server we have Sql Server Management Studio, whit serve to global management not only for table creation and query design, there is a lot of background staff going on right there for example user management, rights jobs.
So it is not that SQL Server does not have a query designer, You just don't use proper software to work with it. A power full application is SSMS that ChrisW presented.
Actually there is a GUI-Designer for Views and Queries. Just use the SQL Server Management Studio.
For Example on the "Views" right-click and choose "Add View...". The view GUI is looking very similar to the one in access.
AFAIK about MySQL. Earlier there was the MySQL suite of tools and now there is the MySQL Workbench.
Say what you may, but it's definitely a timesaver.
First off, I believe the query designer in SQL Server Management Studio is probably the equivalent of what you've used in Access. I'm not terribly well-versed in using Access except through code, but I think you can do what you want there (in query designer). I've never found it to be very flexible, so I always end up back in the code itself, but there you go.
My other answer is a little bit off topic (and posted at this point mostly for googlers), but if you're a developer (especially using SQL Server), it probably still applies: Linq to SQL in Visual Studio.
I've been developing against SQL Server databases for about 7 years now, and most of that time has been spent writing the SQL statements out by hand. Last year, I changed jobs and finally had an environment where the databases my programs used were local and didn't change structure. I finally had a good opportunity to begin using Linq!
Linq is an amazingly useful tool!!! I now use it for almost (not quite) all of my database interactions from code.
The basic gist is that you create a graphical database layout in a dbml file. This layout includes tables (or views) as objects and association (PK/FK relationships) as links between the objects. How you set up the associations determines whether that property is a single object or an entity set of that object. Imagine you've got the following:
TABLE (ORDERS) TABLE (CUSTOMERS)
-------------- ----------------
PrimKey
CustomerID --(FK)--> PrimKey
OrderDate CompanyName
Using Linq to SQL, when you run something like the following:
Using db as new DataBaseContext
Dim orders = (From iOrder In db.ORDERS Order By iOrder.Customer.CompanyName).ToList
End Using
You end up with a list of Order objects that each own its corresponding Customer object. You can set this up to have object hierarchies and it pretty much works like you'd expect.
Anyway, it's a fairly big topic and more to get into than is appropriate here, but suffice to say that I think it's a great technology to bridge graphical interaction with true, nitty-gritty code.
What are Dynamic Management Functions (DMF) and Views (DMV) in SQL Server 2005/2008 ?
Dynamic Management Views and Functions (Transact-SQL) documentation:
Dynamic management views and functions return server state information that can be used to monitor the health of a server instance, diagnose problems, and tune performance.
Dynamic management views and functions return internal, implementation-specific state data. Their schemas and the data they return may change in future releases of SQL Server. Therefore, dynamic management views and functions in future releases may not be compatible with the dynamic management views and functions in this release. For example, in future releases of SQL Server, Microsoft may augment the definition of any dynamic management view by adding columns to the end of the column list. We recommend against using the syntax SELECT * FROM dynamic_management_view_name in production code because the number of columns returned might change and break your application.
The link includes more information, including a breakdown of the views & functions along with more specific information...
Introduced in SQL Server 2005 they provide a consistent way to look at the internals of SQL Server instances which previously required a fair bit of hacks. They provide the administrator about the various state of the SQL Server instances - for example sessions, memory etc.
This is the quote Ian W. Stirk
As queries run on a SQLServer database, SQLServer automatically records informa-tion
about the activity that’s taking place, internally into structures in memory;
you can access this information via DMVs.
DMVs are basically SQLviews on some pretty important internal memory structures.
For more knowlage see this link and read this ebook : SQL Server DMVs in Action
Our centralized IT department has suggested two primary ad hoc query tools for our general user base of approximately 200 staff members:
Microsoft SQL Server Management Studio 2008 (SSMS)
Microsoft Access 2003
Environment
The backend database is a read-only Microsoft SQL Server 2005 database.
The schema is 400+ tables; allowing access to the raw data for our general staff would be a disaster.
We will be building an "abstraction layer" over the raw data for our general staff to run ad hoc queries against.
The abstraction layer will most likely contain a number of views.
A number of users have basic knowledge in Microsoft Access; none have used SSMS.
Which of the above tools (or alternative) would be best for a decidedly non-techie user base of approximately 200 people? What are the pros and cons of each?
Also, the IT department has suggested teaching people T-SQL so they may use SSMS. Is this reasonable?
How about this one? i-net Clear Reports (used to be called i-net Crystal-Clear) has a powerful ad-hoc reporting component that is made to be an easy-to-use thing for non-technical users. Your users won't have to know anything about reporting at all. They simply select the kind of report, the data et voila there is a report suiting the needs.
The data abstraction can be done easily by creating so called data-views which can be designed by e.g. your administration. There are various ways to access the ad hoc reporting GUI. We have a web GUI, a Java Applet or a standalone Java program.
The end users will not need any training since the GUI is highly intuitive.
The views can easily be build by drag and drop in addition to setting datatypes, formats and so on.
All reports (depending on security settings) can be accessed via DAV our a report repository gui.
The server supports different security settings on a per user or per group basis.
The standalone report designer is free and fully functional.
Disclosure: Yep. I work for the company who built this.
Your "abstraction layer" is the right approach to take with Access. Create an MDB with the basic views required linked into it and distribute to the users. Allow them to create new queries and reports in their own MDB as required.
Now how you are going to stop them from running a Cartesian join on tables with a million records or more I'm not quite sure.
Microsoft have a free tool for business and end users which called "Report Builder". It supports the full capabilities of SQL Server Reporting Services. The good thing it is provides a Microsoft Office look-like user interface.
You can download latest version "Report Builder 3.0" from here
http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=6116
And for more information about MS Report Builder check this link
http://technet.microsoft.com/en-us/library/dd207008.aspx
Attempting to teach "non-techie" people T-SQL to query a schema with 400+ tables probably isn't going to do well, unless they are limited to querying the views only, and the views hide all the ugly complexities of various joins, grouping etc.
Our company was in a similar situation where Access was used early on, and then we switched everyone over to use T-SQL and SSMS. IMO, this is the approach you'd want to take.
Again though, the success of this will depend on the quality of your views, or better yet, reports you provide your end-users.
Randy
I would look more into something like Stonefieldquery.com that is designed for non developers to build reports. Not that the report writer or query builder in Access is bad, but may be too much. I think they also provide a way to centralize reports and queries where they can be shared. Multiple people are not going to be able to open a single access file and create a report (I think query building is OK.).
Most will use the drag and drop capability, but about 5-10%will come thing a need for SQL and then you can take advantage of the "teachable moment" and get them some training.
Cons for Access certainly would be cost; SSMS should be free assuming you're properly licensed for the SQL server.
Depending on the actual needs, some users might actually be better off with Crystal Reports (never thought I'd say that), or Reporting Services.
you could create a series of sql server analysis cubes and have the users conenct to those using excel so that they can use excel's pivot tables.
Being a newbie at ad hoc reporting and doing the work myself, I used Izenda.com ad hoc reporting. It was very straight forward, and I could do it myself versus outsourcing.
Check SQLS*Plus - http://www.sqlsplus.com
I found SQLS*Plus to be a very effective command line SQL server reporting tool - this is a free tool (for personal use) and allows me to generate reports with the titles, headers, in HTML and CSV formats, format columns in custom masks, set report length, pagesize, etc. As I understand it is very similar to very well known Oracle SQL*Plus reporting tool
I m using Access 97 database.It has lots of forms. Data bulked. I have to upgrade it quickly. I bought SQL Server 2005 enterprise edition.
I want to use SQL Server for data holder. I m going to use Access forms regularly. I just want to export data to the sql server.
Is it possible to use "Linked" data storing?
While I agree with HLGEMs first paragraph I respectfully disagree with HLGEMs second paragraph. There are quirks you need to know about of which I'm somewhat ignorant. Such as changing boolean fields to LittleInt. But otherwise it's a lot of tedious work to recreate the database schema. And it'll be error prone such as missing indexes or relationships.
There is a tool from the SQL Server group which is a lot better than the Upsizing Wizard especially the Access 97 version.
SQL Server Migration Assistant for Access (SSMA Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx
As you discover these quirks you can change the scripts to recreate the database with the appropriate changes.
I concur with Tony Toews (and you should trust him on this, he's an Access guru): use SSMA to help you move data to SQL Server, it does a more complete job than the upsizing Wizard integrated in Access (which doesn't work for upsizing to SQL Server 2008 anyway).
You have to be wary of a few caveat though; I've made a blog post about some of the things you should check out.
The point is that if the original Access database was designed without relying too much on the liberties that Access allows (strange characters in table and column names for instance), then the process will be much easier.
Pay special attention to all the warning and errors reported by SSMA, they are really useful in helping you focus on the issues you must solve.
With regards to performance, moving to SQL Server isn't necessarily going to make things faster.
In some areas it will actually be slower, sometimes much much slower:
Access is pretty good at optimizing certain forms of data access but once the database moves outside of its reach, it doesn't have as much control.
Most things will work fine though.
You will probably have to rewrite a few queries, maybe move them as views on SQL Server instead of keeping them in your Access application.
Little things such as using % instead of * as wildchars in queries using LIKE in their WHERE clause can also cause strange issues like queries not returning any records.
By the way, I'll post a very good resource Tony has on his own website regarding SQL upsizing: My random thoughts on SQL Server Upsizing from Microsoft Access.
There is also a good and detailed read about things to consider when using SQL Server from Access: Optimizing Microsoft Office Access Applications Linked to SQL Server
YOu can add the SQL Server tables to access as linked tables. Then you will want to start looking at your slowest queries and convert them to stored procs.
Do not use the upgrade wizard in Access to create the SQl Server tables becasue it will make poor choices for datatypes. Do the work yourself to create the scripts, choosing the best datatypes. It takes longer this way, but your database will perform better and you will gain a better understanding of how to do things in SQL Server. You should start right now, learning to do everything through a script and never from the GUI. Best to learn good habits in SQL Server from the start.