Featured Article(s)
Understanding the Power of SQL SELECT in Oracle—Part II
Part II of this tutorial on the use of SELECT statements in Oracle Database applications examines some advanced concepts. The next parts of this series will examine how to execute the select statement in code.
Featured White Paper(s)
Protect your SharePoint Content: An Overview of SharePoint 2007 Disaster Recovery
SharePoint Disaster Recovery is more than just backing up your data and building extra hardware. Our new whitepaper "Protect … (read more)
DBASchool – Do You Have Your Reservation In Yet?
Jan 11, 12, 13 – max 15 students, we’ll go through the key things you really need to know for working with SQL Server. Check out the site for the course overview and more information. Would love to see you there!
[More information here, at the site]
SQL Server Versions Reality Feedback
I’ve had several notes from people with some of the experiences behind the slower path to upgrade to SQL Server 2005/8. I posted the overall stats from the survey and the reality behind upgrading (or not) is clearly based heavily in two areas. First, the need to upgrade for a particular feature that exists in the upgrade, and second the applications that support the newer release of the software and their certification on the new platform.
For the first part, if an application is running correctly today, clearly a new feature isn’t *required* but could be nice. In the current economic climate, many companies are in a holding pattern on new updates unless required. This seems to have stopped many from the upgrade process, though the economic issues really should have become more pronounced only in the last few years (not accounting for still using SQL Server 2000) .
The second item, the lack of software support is key to moving forward. We’ve talked about this quite a lot here and it’s clear that the application support for a new release, and a reason to move to the new release, are fundamental to the decision to upgrade. Here’s an example of both of these from David:
"Why are we not using more recent versions of SQL-Server?
(1) The newer features are not needed for our applications, so there is no pressure to upgrade to a newer version.
(2) We have many applications, and our funding model is that maintenance work for each application is paid for by the division of our agency that uses the application. Every time we stop supporting an old version of SQL-Server, we need to modify and test each application to make sure it keeps working as before. The user divisions are not interested in paying for this work, when they don’t see a business need for the change.
Why are we starting to use SQL-Server 2005 a little?
(1) Some purchased applications require SQL-Server 2005, so we have it available for those applications.
(2) Some in-house applications interact with the purchased applications, so we sometimes move them on to SQL-Server 2005 also.
(3) Support for SQL-Server 2000 will change, and we want Microsoft technical support to be available. If we did not need the possibility of support if problems arise, we would have looked at the non-Microsoft SQL-Server clones.
Now that we have SQL-Server 2005, why don’t we just move everything to SQL-Server 2005?
(1) Our funding model does not leave our IT department with resources to do the testing and possible modifications an application might need in order to run on a different version of SQL-Server. Our divisions don’t want to pay for work they haven’t requested."
Featured Script
dba3_prc_IsLeapYear_Article
— Procedure to determine if a given year (Gregorian year) parameter represents a leap year — Modeling Date Logic II: Quer… (read more)