Webcast Available Now:
SQL Server Forensics
Have you ever received a call from one of your users asking why they received an error 3 days ago? Or maybe they want to know when a particular piece of data was deleted and who did it. Troubleshooting past events is difficult in SQL Server, but not always impossible. Learn how to set up a SQL Server to be able to respond these questions and how to use resources within SQL Server and other application logs to track down activity that otherwise might be lost.
Presented by: Sarah Barela
Webcast: Basics of Administering Databases for The Layman – Part 3
Okay, so you’ve gotten your data into your database. Did you do it right? Do you have too much data? Do you have the right data? Can you actually get the data out that you want? Now how do you get it out? This session will take you through some examples of why you want to have less data in a database to be more accurate (normalization), how that’s done, and how it makes the data in your database more accurate. It also explains why, in certain circumstances, it could be beneficial not to do that. Topics included will be indexes: what, why, and how to use them, what the benefits are, what the tradeoffs are. Also, different ways to maintain them and why you want to do that, and why some of Microsoft’s canned maintenance plans can be a problem and where to look for solutions to those problems.
Presented by: Tom Roush
> Register Now
> Live date: 4/21/2010 at 12:00 Pacific
Retrofitting Security On Your Systems – Reader Feedback
Paul wrote in with his perspective from both the developer standpoint and the viewpoint of the DBA – "In response to your April 15th article about SQL Server Security Retrofit I have had similar experiences. What’s even more challenging for me is I am the developer of a lot of these programs but also the database administrator! I’ve been trying to come up with ways to satisfy both sides of the problem while also trying to manage updates to existing software, guidelines for developing new software, and guidelines for our SQL Server security.
The biggest issue we have is that several of our users have direct access to the databases already to do their jobs (either through MS Access [which I really don’t like because any SELECT query can easily be turned into an Insert/Update/Delete one and MS Access often shields the database knowledge of the user] or through Management Studio). I went from SQL authentication to Windows Authentication in order to try to have auditing and connection management in place (at least so I would know who was connected) but then this presents a problem – can I lock down the databases well enough without using a SQL login while still preserving the requirements for knowing who is connecting and what they are doing? We have so many differing requirements for access that managing this with AD groups would be challenging (and the requirements change frequently). On the other hand, putting in a SQL login (and then managing this login information when I develop programs) is challenging. I have software written in VB6, VB.NET, ASP.NET, and C# (I’m trying to upgrade my skills not only as a DBA but also as a developer) and of course over time the methods for storing information such as connection strings changes. How to manage all of that properly in a "small company" when moving legacy code to better patterns seems to be such a challenge?
I face many of the problems you are suggesting and I’d love to have a discussion on options to correct them."
What do YOU suggest? Email me here…