I teach an Intro to SQL class (okay, I gave the class ONCE...then I changed jobs and after I settle down the new boss wants me to offer the class again). After class, the one thing I learned as an instructor, was that I need a How to Troubleshoot SQL section. Common errors in code and what the message means. I learned this because my student keeps sending me his code (I also now serve as his mentor) to help him debug. My fault...I didn't introduce him to what those red squiggly lines mean and how to understand the text that appears when you hover over the line. Simple things like leaving the comma when removing/commenting out the last line in a select statement (and the reason why I suggest the comma goes at the BEGINNING of a line and not at the end!). As this is an introduction class, I don't want to get too deep into all the things that can go wrong with coding, just the things that happen to most coders (that means the beginners and the experienced SQL writers, too). Just to have a basis of what do you do. FIRST...Read the error! Either the pop-up when you go to run it, or what you see with the red line. Then, decide what to do about the message. Simple, right?

I would suggest a couple of things: - a stored procedure that is just a collection of these wonderful SQL statements that is commented well and set up to NOT be runnable (comment out the whole thing between /* and */, probably) - set up a comment area above each piece of code with keywords or details about what the code does and what it would be useful for - using a search (CTRL-F) on the stored procedure you called GreatCodeToMaybeReuseSomeday (or whatever) to find the SQL of interest. - Copy and paste the code you found. Probably the closest to "think it and it will appear"

I have you beat....they hired a 64 year old to replace the 65 year old who is retiring at the end of September (that is, 4 more of his working days as I type this; he takes Fridays off)! The good news is that I LOVE this new job and my new boss is terrific! I used to be in IT and he was one of my users I supported. He rose up the ranks the old way...he earned it! He knows what it's like to be a developer. I also am now a database developer (VBA in Access) and I wasn't before I transferred departments (I was a Cache ObjectScript/MUMPS programmer for the IDX/GE Healthcare system we have/had (it was replaced with Epic which does not encourage programmers to muck with their system, so I morphed into a SQL writer...I MISS being a Cache ObjectScript/MUMPS programmer). Oh, he just logged on...time to go drain his brain and document his extensive processes so I can support them all.

I listen to Spotify (free version, I have almost 1000 songs and I add on average, 2 or so a month) playing through an iPad to a Bluetooth speaker I can move around (it lasts almost 2 working days, about 20 hours, and is easy to recharge). I'm currently working from home, but I used it while in the office (and will again, if we ever have to go back). I don't mind the ads, strange as that seems. My collection is a mix of hits that I like: music from the 50s (a few), 60s (more), 70s (majority), 80s (less than or tied with the 70s, I think), 90s (less than the 80s), and so on by decade, diminishing to a few current hits. My collection of artists are all over the place: Barry Manilow, Beach Boys, Monkees, Four Seasons, Queen, Led Zeppelin, Frank Sinatra, Muppets (I like "Rainbow Collection" from Kermit the Frog), and a couple of songs I have a history with that bring back memories ("Don't It Make My Brown Eyes Blue" was the song I used to audition as a DJ for a local radio station, which helped start my part-time-while-attending-college job, "Wake Me Up Before You Go-Go" was the last song I played every Saturday night at midnight when I logged off the local radio station and shut down the transmitter for the night). Music is a background killing "noise" that I've used all through the school years to concentrate. It's served me well and I hope it continues to do the job!