Go-to scripts

Actual John McCormack (@actualjohn) asks about our go-to handy short scripts. It's a nice question, because some of the first programs I ever wrote were short and featured the GOTO command.

10 PRINT "Rob was here"
20 GOTO 10
RUN

It was a Commodore machine in a department store. I don't remember if it was a Vic20 or a Commodore 64 – I think it was probably the former, because we got a Commodore 64 at some point later. I had seen another kid do similar, and I guess I learned three commands that day and the principle of line numbers. It wasn't until years later that I understood what Edsger Djikstra meant.

Of course, this isn't the GOTO script that John was asking about. He wants to know about the tools we use, the ones that are scripts that we turn to regularly. I had to think about this, to think about what I find myself typing at client sites, and when, and why.

As a consultant, the kind of work that I do from customer to customer can change a bit. Sometimes I'm reviewing people's environments; sometimes I'm performance tuning; sometimes I'm developing code or reports or cubes; sometimes I'm writing T-SQL, but it's often DAX or PowerShell.

But often, I simply need to figure out where things are being referenced. The "View Dependencies" can be handy, and gives me a pretty tree with branches that I can expand, but just isn't as useful as running:

select 
    object_schema_name(object_id)
  , object_name(object_id)
from sys.all_sql_modules
where definition like '%TheThing%'
;

, because this lets me see the definition if I choose to show it, or do something with the results. Plus if I run it in Azure Data Studio rather than SSMS, I can easily save the results to a file, even in Excel.

And yet this still isn't my ideal.

My ideal scenario for this kind of situation is to look through the source control repository, where it'll list the files, show me how often TheThing is mentioned, show me where it is, still be easily selectable, and I don't even have to connect to a database to do it.

And maybe that's the thing… many of my useful scripts get replaced by other systems which are more useful. The ones that don't tend to be about data rather than the database, and then it's less about having a go-to script, but about being fluent in the languages, having a good speed for typing, and getting used to the business logic at my customers.

@rob_farley