T-SQL Tuesday #105 – Brick Wall

Invitation from Wayne Sheffield.

Brick Wall

Tell me about a time when you ran up against your own brick wall, and how you worked it out or dealt with it. Did you start working on a project only to find a brick wall that had been hidden? Was your brick wall:

  • A technological hurdle to overcome?
  • Brought about by your not having sufficient knowledge of the product?
  • A person?

Whatever you choose, tell us about a brick wall that you ran into and how you dealt with it (did you get help from someone/someplace? Wake up in the middle of the night with the solution?).

Most importantly, publish your post sometime on Tuesday, 2018-08-14 UTC time.

T-SQL Tuesday #099 – Dealer’s Choice

Invitation and roundup from Aaron Bertrand.

Aaron is offering a choice.

Behind door #1:

In the spirit of my revelations about still being a hockey card nerd after all these years, and after seeing Drew Furgiuele’s great post on #sqlibirum, I would love to hear about something you are passionate about, outside of the SQL Server or tech community. Bonus points if it’s a passion that might surprise the rest of us. Play the Zeusaphone? Forge Samurai swords? Coach a chess boxer or extreme ironer? Maybe you dabble in toilet seat art? Tell me about it! Show me proof! If you choose door #1, I hope your post is full of pictures or other media, and not just a wall of text. Let’s keep it PG, though, OK?

Behind door #2:

Since many of you might be uncomfortable talking about your non-technical passions, I’ll give you an escape pod back to the more familiar. I have a long laundry list of T-SQL bad habits (there’s a big index here). What’s your favorite one? Which one do you disagree with most vehemently? What bad habits are missing from my list? This is not entrapment; I promise I’m not going to bait you into writing something just so I can argue with you. I’m really interested in reading your opinions and, also, to have more material I can point to when I talk about bad habits and/or best practices.

T-SQL Tuesday #091 – Databases and DevOps

Invitation  and roundup from Grant Fritchey.

Implementing DevOps with databases presents a unique set of challenges. However, just because something might be hard doesn’t mean that it shouldn’t be done.

I had the opportunity to work with a team of developers, database developers and DBAs under a management team that all agreed on the common goal we had, delivering more, better performing applications, faster. We didn’t know it at the time, but we were doing DevOps.

DevOps gets a bad name because, well, the problems that DevOps sets out to solve, poor communication, bad teamwork, dysfunctional development and badly configured and maintained processes, are  done by the same team that attempts to implement DevOps. However, they look on it as a purely mechanical switch that they throw, assign some poor person to the role of DevOps Coordinator (or something) and then maintain the status quo in regards to their culture and approach to software. Shocking that implementing this doesn’t work.

Then, toss in databases with the whole issues around persistence, and things go nuts.

This then, is my choice for T-SQL Tuesday. How do we approach DevOps as developers, DBAs, report writers, analysts and database developers? How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together? Please, tell me your DevOps stories.

T-SQL Tuesday #090 – Shipping Database Changes

Invitation and wrap up from James Anderson.

I was once asked to add a new feature to an application. It was installed on multiple SQL Server instances across multiple physical sites. The problem was that different instances of the application had different database schemas. New code may work on my local schema, but it could fail on the different schemas in live.

To develop the feature, I knew that I needed one universal version of the database schema.

I merged the schemas into a version that met the requirements of all environments and redeployed. Once in source control, this schema became the single source of truth that all future deployments were built from.

Not only did this solve my problem, it served as the foundation for the automation of builds, tests and deployments.

I’ve been interested in Continuous Integration and Database Lifecycle Management ever since. For more details, check my series of posts that start with SQL Server & Continuous Integration.

For this T-SQL Tuesday, I’d like to hear about your thoughts or experiences with database deployments.

Read the rules below and join in by publishing a short post about database deployments. If you develop or deploy database changes, I want to hear about it.

Your post can cover anything related to database deployments, but if you need inspiration, feel free to cover any of the topics below: