Just wondering – what SQL Server version are you using in production?

Hey there everyone – Out of curiosity, can you let me know (via comments to this blog entry) what version you’re using in production? AND – why? I guess I’d like to know some of the many reasons that you are staying with SQL Server 6.x or 7.0, if not SQL Server 2000 or SQL Server 2005. If you’re staying with SQL Server 2000 – let me know when you plan to upgrade?

Just wondering… and thanks for your time!

23 thoughts on “Just wondering – what SQL Server version are you using in production?

  1. All of my customers are at SQL Server 2000 right now. The big trick for me is figuring out an incentive for them to upgrade. Most of my customers are not experiencing issues or limitations that would inspire them to upgrade, especially with the added cost. Moving them to .NET 2.0 is easier, because I control most of the upgrade costs, but the SQL upgrade cost is outside my control. But I expect that it will happen within the next year for at least half my customers.

  2. I’m using SQL 2005 in house and on one of my websites. I have a client still on SQL2000 because of the expense of upgrading. They will eventually do it, but like to space out big cash outflows. I only got them to go from SQL7 to SQL 2000 about two years ago! :-)

  3. I use SQL2000 for my SPSv2 portal. I use SQL2005 for my MOSS2007 infrastructure.

    Why? I’ve found that if you try to use SQL05 with SPSv2, you will run into issues if you dont upgrade EVERY database *first* before you connect to the config db. For MOSS2007, SQL05 is *required*.

  4. Swapped over to SQL 2005 immediately for production. Primary reason was to take advantage of the table partitioning and ETL speed that we could achieve using SSIS.


  5. SQL 2005. Customer had requirements which could not be met in 2000, one or both – a) Significant extra work b) Significant costs for thirdparty tools. SSIS and AS are biggest gains on this project

  6. Same as Raoul. Simply no time to plan an upgrade to 2005 yet. Production box is 2000. I’m using 2005 for development, so before I roll these out I will have to deal with the upgrade.

  7. We’re firmly in the ‘stay with SQL 2000’ camp. Why? It never gives us any problems, and we have no need for the new features of 2005 at the moment. The one thing that might tempt us is the improved Full-Text Index stuff, but the risk outweighs the gain in my view. When we upgraded from SQL 7 to SQL 2000 we had a number of very subtle problems. One was a stored proc that had a syntax error in it but which had passed validation when it was created. For whatever reason, we never noticed that the proc was broken in SQL 7. When we upgraded to 2000, our COM+ application very occasionally started to eat all the memory on the machine. Eventually, we tracked it down to this proc, fixed the syntax error, and the problem went away. It cost a lot of time that gained us not very much. Once bitten, forever shy.

  8. One of our clients is running 2005; rest will probably follow with next major upgrade. Both security and manageability seem reason enough to upgrade.

  9. Currently on SQL Server 2000 Enterprise for main LOB application. Next version will be moving to SQL Server 2005 Enterprise.

    Main reason for staying is changes in our application need to be made for compatibility. Takes a while to roll it out to 150,000 or so customers. We can’t move fast enough for the improved clustering, partial restores, and 64bit support…

  10. We’re on SQL 2000 currently. We need time to really investigate what the impact of upgrading our database to SQL 2005 will be before actually upgrading. While I anticipate minimal impact, that needs to be tested heavily.

    After testing, we’ll probably upgrade in relatively short order. The benefits that SQL 2005 offers are enough to make the upgrade very enticing.

  11. I am running SQL Server 4.2 on our most crucial applications…

    No seriously though.. We have a mix of SQL Server 2000 SP4 (with some rogue RTMs I am still trying to track down and apply Service Packs to) and SQL Server 2005 RTM installations.

    We will be migrating all that we can to SQL Server 2005 as we move forward, but there is so much going on that that may be a slower migration that I would like.

    Now may I ask -you- a question??? What are the plans for "migrating" the High Availability book for a SQL Server 2005-centric edition… I realize you were not the primary author on that book, but it has a wealth of useful information in it and I am hoping to see one updated for SQL Server 2005

  12. We have the following

    140 – SQL 2000
    10 – SQL 2000 x64
    4 – SQL 2005

    The 2005 machines are internal apps that we wrote to manage the rest of the system. The other machines will be some time until we convert.

  13. We have over 120 servers all running SQL Server 2000, we will be begining to migrate to 2005 within the next couple of months.

  14. We have app. 120 2000 SP3a PROD servers (clustered) in two physical locations. Avg server hosts app. 75 DBs. We’re rolling through SP4 now, and expect to begin rolling through 2005 in Aug.

    The biggest drivers are — 1. new Disaster Recovery implementation has a 2005 dependency (for us); 2. 2005 Table Partitioning so that we can gain performance and lower cost by partitioning older data (possibly 80% of file size) onto less expensive disks; 3. recognition that we lower our overall cost to operate when our version levels closely follow our vendors’ latest versions.

    Bigest obstacles are resource constraints on multiple application regression testing and scheduling downtime during very narrow maintenance windows.

  15. We are currently on SQL 2000 in production but are standing up our first SQL 2005 for testing. We’ll probably move everything over within the next 12 months.

  16. A mixture of 7.0 and 2000. Primary OLTP production database is still at 7.0, but we’re planning on migration to 2005 within 3 months. 2000 is currently in place (and will remain so for another 6-12 months) for some specific apps that currently are not certfied for 2005 — this is based on the vendors certifications. A few other servers will remain at 7.0 for legacy applications.

    BTW, awesome breakout sessions and chalk talks last week at TechEd Kimberly!! Thanks so much.

  17. (ISV) We’re shipping MSDE with our application install. Our application supports both SQL 2000 and SQL 2005, but we don’t use any of the SQL 2005-specific features (though there are some that will come in real handy once we do, like built-in sequential GUIDs). We’ll probably change over to ship SQLExpress within the next year, and at that time implement some of the SQL 2005-specific features, but we’re not going to be able to give up SQL 2000 compatibility for a long time to come.

  18. We just completed the migration of our production OLTP applications from SQL Server 7 to SQL Server 2005. This went extremely smoothly, and now we are reaping the benefits of improved performance. We have not yet taken advantage of new features; that’s the next step for this summer/fall.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.