Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase 12»»

SQL Server Needs Incremental Updates Expand / Collapse
Posted Saturday, April 24, 2004 3:23 PM


Group: Moderators
Last Login: Wednesday, February 10, 2016 12:22 PM
Points: 1,931, Visits: 235
Comments posted to this topic are about the content posted at

Brian Knight
Free SQL Server Training Webinars
Post #112929
Posted Sunday, April 25, 2004 10:21 AM



Group: Administrators
Last Login: Today @ 8:38 AM
Points: 34,366, Visits: 18,586
A good idea, but I'm not sure I agree. Unless there is some pick and choose and a subscription model. Upgrading our DBs is a major challenge, both in time and resources (testing) and politically (money), so having the releases fewer and father between is something i like. If Yukon released in Q3 or 4 of this 2003, there's no way we'd upgrade for a couple years. However with the release next year, it's an easier sell to start testing.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #112953
Posted Thursday, April 29, 2004 1:20 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 3,410, Visits: 3,035

I don't like the idea of a huge and radical change to something as fundamental as the SQL.

Don't get me wrong, I'm enthusiastic about SQL2005 its just that the learning curve, from what has been said so far is going to be pretty steep.

That said a release of a database tends to be pretty major, and therefore it is not something you want to be doing every year.

I like the way that Microsoft have released the Reporting Services as a bolt on to SQL2000.

It would be good if the various components of SQL Server were available as bolt-ons so if a huge upgrade occurs you simply upgrade the bolt-ons as and when is appropriate.

LinkedIn Profile

Newbie on
Post #113585
Posted Thursday, April 29, 2004 3:28 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 27, 2007 12:21 PM
Points: 342, Visits: 1

The learning curve will be steep, but I must admit this is the first time Microsoft has involved developers from ISVs from all over the world in beta testing and design input of any product (so they said !!)

I was on the Ascend Phase 1 training program (Developmentor run) in in Germany in Jan of this year and Yukon will be a mjor change, but it's a major change for the better and I really don't think it could be done in stages. Saying this the new veriosn of Reporting Services was available as a stand alone beta called Rosetta. It's now part of Yukon.

If I was a database developer or DBA I'd spend the next year learning C# and .Net and becoming more familiar with XML. TSQL will still be the language of choice for set based querying but I think C# will become more prevalant as it's a much richer environment to work in.



Post #113606
Posted Thursday, April 29, 2004 4:04 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 12:19 PM
Points: 3,059, Visits: 3,780

I completely agree with Brian.

There are a number of issues here...

1) Comparisom with other vendor's release stategy.

My main experience is with DB2.  When IBM are near to making a new DB2 release RTM (GA in IBM terminology), they will make known to technical conferences the major line items in the subsequent release  (Vnext), and those line items that will not be considered until after Vnext is RTM.  This gives about a 6-year plan for the product's future.  They also have about a 2.5 - 3.5 year release cycle and regular (approx quarterly) service packs.  The shorter release cycle means an easier upgrade path, with the +1 release supporting everything that has not been deprecated in the current release.

All this allows sites to prepare far more for what is coming, and the regular SPs help greatly in budgeting manpower for maintenance.

2) Credibility of vendor

When a vendor makes it known they hope to release a major update in 3 years, and it actually takes 5 (e.g. SQL Server 2005), you start to wonder about their ability to deliver for the future.

If Microsoft continue to deliver major upgrades a year or two after making their initial plans known, it will have a corrosive effect on their market share, regardless of final product quality.

3) Size of feature set

SQL2005 is massive compared to SQL2000, but SQL2000 is not the main competition.  Compared to its main rivals, SQL2005 will deliver VERY little that will not already be in other products.

For SQL2000 people, the feature set size is a problem, especially for DTS.  I think it is a major error on Microsoft's part the SQL2005 DTS does not have source compatibility with SQL2000 DTS.  Run time compatibility only is simply not good enough for adjacent releases.  We will have to re-engineer all our DTS at the time of migrating to SQL2005, to ensure that any further troubleshooting or maintenance of a single DTS package will be compatible wih the other packages it works with.  This will add perhaps UKP 200,000 to our SQL2005 upgrade costs, due to the amount of DTS we have.

4) The SQL2005 legacy

The frightening aspect of a 5 year wait for SQL2005 is the prospect of a further 5 year gap for the next release. 

In a number of areas, SQL2005 technology will be inferior(*), and while its rivals move further ahead with their 3-year release cycles we will be stuck with what we have until maybe 2010.  By then, we will either have a release that makes SQL2005 seem minor, or SQL Server will remain permanently and visibly many years behind the times.

(*) Areas where SQL2005 is inferior include continued index locking for insert/delete activity, single dimension only index clustering, slow adoption of SQL standards changes, etc.

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2016, 2014, 2012, 2008 R2, 2008 and 2005. 29 Aug 2016: now over 38,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Quote: "When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist." - Archbishop Hélder Câmara
Post #113612
Posted Thursday, April 29, 2004 6:56 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, April 15, 2010 9:02 AM
Points: 85, Visits: 33

I believe that part of the situation MS has faced is that SQL Server has been playing catch up for a long time. Even though I use SQL Server 2000 extensively now in my day-to-day development, its weaknesses have been very evident. Some might have been addressed in service releases, while others were of a nature that would have made that difficult.

Looking at the feature set of SQL Server 2005 suggests that with a few notable exceptions they have caught up to the marketplace, and I suspect that after this release, we will see more of the missing elements provided via service releases on a tighter schedule. I am only guessing, but I believe that what took so long with this release was that some fundamental changes had to be made to the core of the server to open that option.

It is also important to remember, though, that they did release some major feature extensions during the wait (such as Reporting Services and the XML Services packages). What has been lacking has been an integrated release that made some of these disparate parts accessible.

Let's hope that with this coming release it is done right.

Post #113649
Posted Thursday, April 29, 2004 6:57 AM
SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: Moderators
Last Login: Monday, May 16, 2016 7:45 AM
Points: 8,376, Visits: 780
Personally I think they should put the beta out for the public to download, or request since there are some many new features. The only people who will be ready are those lucky enough to be on the beta. I agree too much to absorb in one go and even when released it will be a year before most actively consider. A public available beta will allow many to adopt faster with more confidence.

Post #113651
Posted Thursday, April 29, 2004 9:55 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 27, 2007 12:21 PM
Points: 342, Visits: 1


Although i WAS on the beta and am now not. I've moved companies.

Ironically the company i worked for were really lucky to be on the ascend program and they're not interested in yukon at all. they'll probably deploy it but are 'too busy' to follow the beta process though, which is a shame when there are companies out there that that would be interested.

Rant over. My boss was a nice guy. Really he was.


Post #113706
Posted Thursday, April 29, 2004 12:27 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 26, 2005 9:54 AM
Points: 2, Visits: 1

I think Brian has the right approach, but for a different reason.  Part of the process of an upgrade is the testing that MUST occur for all of your applications that use the database.  Testing against the huge set of features in the SQL Server 2005 release is going to be a mammoth task that, frankly, most companies are going to gloss over or skip altogther.  Having a smaller feature set allows that testing to be much more concise and manageable by an already downsized and overworked database admin and development staff.


Post #113745
Posted Thursday, April 29, 2004 5:01 PM



Group: General Forum Members
Last Login: Monday, September 26, 2016 8:32 AM
Points: 1,655, Visits: 285

I agree with Brian.  In my case, it will take at least 6 months to test, wait for a service pack, test again and then get management buy in.  By that time, it will end up being more of a 2006 implementation. 

We were able to upgrade from SQL 7 to 2000 in a very shore time frame due to the smaller amount of changes.  I just don't see how that would be possible here, unless this is one of the few times when Microsoft get's it right the first time.  Their track record on first releases is not good.

As Steve Brett said: rant over

Post #113773
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse