Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.
.net android asp.net asp.net mvc azure backup bigdata book c# community continuous delivery database denali gotcha how to indexing java linq mongodb nancy nhibernate nosql performance powershell restore ruby security silverlight sql sql advent 2012 sql friday sql server sql server 2000 sql server 2005 sql server 2008 sql server 2008 r2 sql server 2012 sql server denali sqlcop ssis ssms ssrs structuremap t-sql tip training unit testing vb.net visual studio 2010 windows 7
- SQLDenis (577)
- Christiaan Baes (chrissie1) (527)
- Ted Krueger (onpnt) (332)
- Jes Schultz Borland (grrlgeek) (139)
- Eli Weinstock-Herman (tarwn) (116)
- Alex Ullrich (51)
- George Mastros (gmmastros) (46)
- Naomi Nosonovsky (27)
- Axel Achten (axel8s) (23)
- David Forck (thirster42) (22)
- Koen Verbeeck (20)
- Kevin Conan (18)
- chopstik (18)
- Rob Earl (14)
- thatrickguy (12)
Recently, while working on a personal project, I found myself needing a lightweight way to deploy database changes to multiple environments. In the past I have used a wide range of methods, ranging from applying the changes manually to applying changes via a diff tool (SQL Compare), to automatically applying manually created change scripts, to automatically applying diff scripts that were automatically generated, to working directly in production..er, pretend you didn't see that one.
A while back I ran into an issue where a user was complaining about @@IDENTITY not always returning the value they expected.
If ever a DBA walked up a mountain and came back down with two stones that had 10 commandments written on them, “thou shalt not use SELECT *” would be one of them. However, that same DBA would turn around and within 5 minutes use it themselves!
When creating reports, I try to keep them simple, clean and with as little information as possible.
This is day four of the SQL Advent 2012 series of blog posts. Today we are going to look at triggers. Triggers are a great way to keep your database in a consistent state. There are two types of triggers, DML triggers and DLL triggers. DML triggers res…
This is day three of the SQL Advent 2012 series of blog posts. Today we are going to look at sargable queries. You might ask yourself, what is this weird term sargable. Sargable comes from searchable argument, sometimes also referred as Search ARGument…
As you might imagine, I rely on Idera's Diagnostic Manager quite a bit. Diagnostic Manager monitors many different things within each SQL Instance will alert to them when they met the thresholds you configure. Now if you only a few SQL Instances monit…
Where I work, we like to buy Diagnostic Manager Licenses in batches. So every quarter or so I add in a bunch of new instances. When you start getting over 25 instances being monitored, it gets tricky to remember which 5 instances you just added into t…
A great use of Idera's Diagnostic Manager is to manage your SQL Job's and knowing which jobs have failed, which ones are running long and which ones have been running for the last 10 hours. You even get to adjust the thresholds for each all of those me…
One of the great things about Diagnostic Manager is the ability to create custom alerts. This is something I believe needs a bit more work, but even in its current state, it is really useful.
:: Next >>