Featured Article(s)
Troubleshooting problems with connection to SQL Server 2005 (Part 2)
In this article, you can find the description of SQL Server 2005 connection bugs and the information on how to resolve or work around these problems.
SQL Server Outreach
(Sounds like a new 12-step program…)
My real question and thought on this is that, collectively, as DBAs and such, we’re not effectively reaching people that are faced with developing for SQL Server or just working with SQL Server on an "as needed to answer emergencies" basis. How do we keep rational good practices in front of people that don’t know there’s an issue? More than a few of you wrote in saying "I don’t NEED all that…" talking about the nitty gritty detail of even things like injection and security. What people need is sort of a "down-to-earth guide" to what needs to be thought about with SQL Server. So, that’s what we’ll be getting together. 😉 And we’ll keep pushing on this – there has to be a way to get the word out in real-world terms and application to get people information they don’t even yet know they need.
In the meantime, here are a few thoughts from other readers. [Send Your Comments Here]
Ralph: "After a recent painful experience regarding a couple of developers, I wound up blogging about this topic in my ITToolbox blog ("SQL is your friend"). I have long been trying to find ways to reach out to Developers in order to help them understand that there is a bit more to writing SQL than "SELECT * FROM TABLE". While I have had some success in this area, I have recently come to the conclusion that there needs to be a new job title associated with the use of databases.
I can remember when the term DBA was invented and those of us who were working in IT, for the most part, wondered at the need for DBA’s (after all, that kind of thing had always been "just part of the job"). Over time, I came to realize that there is, indeed, a need for someone who specializes in and is solely tasked with keeping the database(s) healthy, backed up, tidied up, and tuned up. Well, I am now developing a stronger and stronger belief that there needs to be someone who is specifically tasked with keeping the SQL used to access the database(s) healthy, well crafted, tidy, and tuned. I am coming to the conclusion that, because they are faced with accomplishing a particular task as quickly as possible and "getting the application into production on time", Developers cannot be expected to spend the time looking at their SQL that it will take to determine how best to write the queries.
This is not to say that Developers are evil, unconcerned, or otherwise "Bad People." (I come from a Developer background, so I am not about to denigrate my own history.) All I am saying is that Developers have many things to worry about and their SQL, if it works (no matter how slowly) during the development and testing phase, drops to a low priority as they fight change requests, scope creep, and other development issues. Sometimes, it is only after the product has been in Production for a couple of months and has started being used by more than 50% of the target Users that someone realizes that performance is becoming an issue and that the reason for that is the SQL. Had there been a dedicated SQL Developer, this might not be the case."
…but of course that’s part of the problem. The reality is that *so* many people don’t have dedicated resources. There is a huge number of these people out there that need to know about things, but in bite-size chunks.
Featured White Paper(s)
Text Deliverables for Microsoft Program
In this white paper, you’ll read about Microsoft SQL Server 2005 Enterprise Edition, which incorporates powerful data managem… (read more)
BitLocker: Is It Really Secure?
What is BitLocker? How does it work? Is it a truly safe way to protect your data and applications, hard drive, and operation … (read more)