A few years back, Redgate Software released SQL Search. This was an internal project that became a free product we released. Free as in beer, so go get it.
Why use SQL Search?
I’m sure plenty of you are like me. You think you know where most of the objects live in a database. I’ll use the SQLServerCentral database as an example. If I want to look in the forums for how to modify profiles, I know there’s an InstantASP_Users table. I can quickly go to the Object Explorer, hit Databases, go to SQLServerCentral_Forums, hit tables, and pick the table. I can get the designer, a list of columns, etc. This is a familiar way of working with databases.
However, I’d be lying if I said I knew all of the objects that referenced that table. Especially stored procedures. Even if I work with a database every day, and I have a great memory, I don’t always keep every reference in mind.
I still follow that process (too often), but I’ve learned there’s a better way of working with a database.
If I type “asp_user” in the search dialog, I get this:
Now I can see lots of objects, including those in other databases. If I know I want tables, I can easily filter.
However I don’t just get the names, I can get some details:
The more I move to search, the more I start to realize that the Object Explorer is quite slow, and inefficient. I’d be better served by just going to search right away. At least, a search that gives me plenty of useful information,