What makes SQLFacts different (and awesome)?

SQLFacts was created to solve a large (and rapidly growing) problem. It was designed from the start as a standard set of tools for several database job roles. There are tools for database development, database administration, and performance tuning. They are much more than slapped together, piecemeal, blog post scripts.

There are roughly a bazillion blog posts about SQL Server on the WWW. There used to be several independent websites
(not owned by a tool vendor) publishing reviewed material written by many different authors. There are now half a bazillion different authors publishing unreviewed material on personal websites. We have more material, but it's more variable and it's much more scattered. It's very hard for new things to get noticed.

Many of the bazillion blog posts contain useful information for dealing with various needs and issues. The information has guided countless SQL Server professionals over the years, me included. These articles definitely should be noticed, read (sometimes repeatedly), absorbed, and understood. They are a treasure to the SQL Server community.

Many of the bazillion blog posts also contain SQL scripts related to the content. Nearly all of the SQL scripts are short and
to the point. Some of them are simply to illustrate a very particular concept. Some of them are simply to satisfy a very particular need. Some of them were written as part of the author's employment, so technically they should not be publishing the code without permission.

The problem is trying to gather these SQL scripts from all the blog posts and use them for daily work. The SQL scripts are hosted on half a bazillion different websites. The SQL scripts were written by half a bazillion different authors, each with their own style and conventions. The SQL scripts were written for various purposes in various environments. They may not suit your purposes or fit your environment. It's a daunting task to find the most appropriate SQL code in a massive library
of blog post scripts, grasp the author's style and conventions, and then modify the SQL code for your needs.

I saw a good example of the problem recently. It was a blog post promoted in a popular SQL Server newsletter. The blog post contains a very simple query to return database sizes. What if you need to know how much of the size is available? What if you need to know how much space is available for file growth? What if you need to know if/how the files will grow? What if you need the size information by filegroup? What if you need the size information by file? What if you need other details about your databases? You would have to add a lot of new functionality to the simple query, or find several other blog post scripts and manually assemble the outputs.

SQLFacts provides the functionality of almost all the blog post scripts combined. The functionality is neatly organized into tools for various tasks. The tools are available from one website. The SQL code was written by one author, using a single style and consistent conventions. The author (me) has more than 20 years of SQL Server experience in different database job roles. The tools are FREE! It's my way to "pay it forward" to the SQL Server community.

Copyright 2021 Wingenious