T-SQL Tuesday #35 – Soylent Green
This month’s host is Nick Haslam (b | t) and he bases his question on the movie Soylent Green, which I haven’t seen. This month he asks what the most horrifying thing you’ve seen in SQL Server. It’s been a long few weeks for me, so I‘ll keep this short.
As an FYI, if you want to host or participate, contact Adam Machanic.
The thing that first comes to mind for me is my first job in Denver. I had interviewed with a small financial services firm looking for a DBA. We thought it was a good fit and I came out to start work in early 1999. Fortunately my wife stayed back in Virginia to sell our house and I was alone since I ended up working a lot.
The first surprise I had when I arrived for work was that not only was I responsible for the databases (v6.5), but that I was also going to manage the network administrator. He wasn’t that experienced and needed some guidance because we were experiencing daily problems.
The second surprise was that all of our applications used the sa account. We had 3 or 4 standalone workstations devoted to loading pricing and position information every morning from clients, all using SA. We also had a web application and a thick client application (VB6) that allowed clients to authenticate with a name and password (stored in plain text) in the database, but the connection to SQL Server as with sa.
However the most horrifying thing was that all developers used the “sa” account to connect to our database servers, in development, QA, and production, with the same password.
A scary situation.
The daily issues actually helped here. I started to tackle our problems, requiring the developers to fix the applications one by one, using a normal user account. It required months just to convince our management that stability was compromised by developers making changes in production, but we were able to change the sa password in all environments and make it different. We then started to require applications to use difference accounts, and a year later, we had ad least provided more stability by removing the “quick fixes” made in production.
All sorts of poor practices at that job, and when I left after almost two years, there were still numerous issues.