Closing on One Year

  • griffin43 wrote: "The one glaring problem I see is that the Database Design GUI does not work...This change is no problem in SQL2000..."

    Not meaning to hijack the topic, but like griffin43, I'd be interested to learn from others about how well Management Studio functions.  I expect a learning curve, but my main concern is whether it's buggy?  The answer to this question will be a factor in our determination of when to upgrade.  If Management Studio is, in reality, still under development, then we may decide to wait for the next SP...or the one after that???

  • My approach, as dba & data architect for a small paper mill, is to build a whole new SQL2005 box as soon as possible; there are a lot of features that I'm wanting, from XML, messaging, db mirroring, name aliases, et cetera.  My designs have been waiting on these new features, so many of these improvements will be a great benefit.

    That said, we have very little budget for any new servers & software; we replace servers when they are 5 to 7 years old.  I expect that our 4 SQL2000 servers will be phased out over the next 5 years, by which time we'll have about the same number of SQL2005 servers in place (and maybe a SQL2010 box).

    New versions of SQL Server (we are all SQL, no Oracle) will be adopted within a few years.  If Microsoft's release cycle is every 3 years, we will skip every other one.  If their release cycle is 5 years, we will hit every one.

    Jonathon Storm

  • Its not about:

    • the marketing 'hype' - which has died down.
    • the 'new' features - there are many, but the value provided for us is truly nothing since we will not make use of the majority of them.
    • the money - we have an enterprise license agreement and software assurance from MS.
    • the time - when projects come up they are staffed and completed.

    Its all about the "business need" <period>.

    We have 19 SQL2K servers and 35+ applications, all stable,  in production today.

    We have no compelling reason, nor plans at the present time, to upgrade them. We'll wait to be driven by other vendor software upgrades or when all support for SQL2K ends.

    However we are not in the 'dark ages', we do have 2 SQL2K5 servers in testing for a couple of projects. We will also be implementing an MSX/TSX setup for SQL2K5 as well.

    So, whether the cycle is 2-3 years or 5-6 years really makes no difference - everything is based on "business need". If the business needs it and gets a good ROI, then it will implement the technology no matter what the cycle length.

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • We are a very small shop and SQL Server 2000 is very stable.  There is no compelling reason to convert.  At this point - no plans - no budget.  I am running Management Studio instead of Enterprise Manager on my desktop.  My colleague runs Enterprise Manager.  We have the DTS problem. There are just too many to convert in a small amount of time and do I know the code and methods as well as DTS - no.  Perhaps MS would be more successful in getting shops to convert if they provided SQL Server 2000 DTS as an option on 2005. The DTS add-on that allows "Legacy" DTS to be edited is very buggy.  It seems to shutdown copy and paste and most other functions within the Query editor (What used to query analyzer).  I wish MS would fix that.

  • We're starting to plan our upgrades and will probably start upgrading to SQL2005 in the next 6 months or so.  We've already gotten budget approval for new license purchases and we're getting questions from developers about some of the new features - particularly Reporting Services and CLR.

    I'm not looking forward to converting DTS to SSIS.  We have a ton of DTS packages that use ActiveX and the DTS Object Model and we also have transactional replication that has DTS transformations that we'll have to remove.

    I am optimistic about database snapshots, SSIS capabilities, and such.  Also, because two-node clustering is available in Standard Edition, we're able to convert a couple of our licenses from Enterprise to Standard.

    Greg

    Greg

  • I agree with this post.  We have a couple of 2005 servers which were created for new projects or new installations.  The only server we are actually migrating is our reporting server, primarily just to play with SQL2005.

  • Were just upgrading the rest of our regular NT servers to W2K even now as we move to W23K. When something is working well, don't dink with it. But we have been on SQL2K since early 2002.

    We only have one primary application that uses SQL and the vendor has not updated the software version we use to take any of the perceived advantages of SQL 2005. I doubt there are any that will be truly useful in this case. I don't think the application itself takes full advantage of SQL2K. Even the much ballyhooed upgrade we did from betrive to SQL only made some performance increases in a couple of areas, most notably in searches. That was an expensive upgrade in preparation of "future offerings" that never came to be.

    I suspect others are in the same boat. Why upgrade when the application doesn't warrant it?

    So put as down as a no plan in the near future to upgrade. In fact, no plans at all until this version of software we use is no longer supported or used here.

     

  • I work for a manufacturing/distribution company with 2 different systems for our ERP and WMS applications.  Both use SQL server and we won't be upgrading until both of these software vendors support it and we can afford (time & money) to upgrade the ERP/WMS systems.  Probably won't be until 2008.  For those of us with multiple applications like this, every 5 years is plenty often.

  • Lock Contention - what a pain in 2K!  Thank goodness for the Oracle-like scheme.  The design I inherited used DIRTY READS EVERYWHERE to get around lock contention - stunning!  For real-time web-commerce where the cart can get quite large, the transaction is somewhat long and that's where we get contention issues, especially when handling inventory updates - a primitive scheme it is, but time doesn't permit me to rearchitect ('nuf said).

    Learning Management Studio was a case of persistence over impatience and the tendency to go back to Enterprise manager and Query Analyzer.  It's been rock solid so far (1 month for development and management of local, development, staging and Production).  I like the right-click to change the connection and run the script in the Query Editor on the new connection.  I'd like more options on the right-click to script an object, especially to include/exclude a drop and some control over the [] and formatting, but that's niceties.

    DB copy from 2K to 2K5 IGNORES DEPENDENCIES!!!  Could hardly believe it, but there it is.  UDF's don't go before objects that consume them - how elementary Microsoft...  SMO - Fails!  Detach-Attach - Fails!  DB Restore - works!  333 batting average isn't bad

    Report Builder: PLEASE!  Not yet 2K5 on the Report Server but that's the first one targetted.

    Side-by-side 2K + 2K5 install corrupted the 2K ReportServer encryption - HUH?  Thanks MS

    Dear Microsoft: Kindly make is as easy to Export to Excel by a right-click option as it was with Enterprise Manager.  Has anyone else run the gauntlet of doing this SIMPLE THING with SSIS?  Pain, Pain, Pain, FAILURE!  The DUMB Jet engine barfs at varchar over 255 (or 256 - don't recall exactly), and despite telling it explicitly what every field's data type (DT_xxx) is, it still won't do what DTS did so easily.  Oh, try reading/passing text fields around SSIS flows - what a joke!  I thought SSIS would be a great platform but so far it's saved NO time, it's harder to do simple things and doesn't do what DTS did - REJECTED (for now)!

    Are we really QA testing 9 months into "commercial"?  Guess so...

  • Well, I'm just glad to know that some of you use Management Studio, even for your SQL2000 databases.    I know I like it a LOT better, especially for query design.  Of course, I had to painfully learn all the features to write the dang book.    Is SSIS really the only good feature to 2005?

  • Thanks SA_from_CA.  Your experience is my fear come true.  Think I'll wait and see if MS makes any progress with the next SP before making the switch.

  • Did I mention the MRU File List IS NOT KEPT CURRENT   Couldn't count the number of times I've dropped a script file, edited it, saved it and run it, then (stupidly?) closed it but within the hour need it again, only to find that (mis)Management Studio has lost track - DUH!

    Whose bright idea in MS was it to deploy SSIS Packages with TWO Tools?  BIDS knows where it put the file, doesn't it?  Why can't you fire off the install leg from BIDS?  Please, if you know the rationale, do share... (If it's "ran out of time to do it properly" fair do's - expected...)

    Cynical - yep!  It's MS after all.  But it is better than Oracle in MANY ways, especially (on the whole) interfacing via a no-extra-cost decent GUI - try SQLPlus for 6 years and you'll know what I mean

     

  • A little late to the party I realize, but we're in a similar boat to everyone else. We don't have a driving business need to move to 2005. 2000 is just to stable & performant. We are trying to move our new development to '05, but we're meeting resistance there due to the risk, migration time (near zero, but not absolutely zero) and learning curve. The one thing that might push us from a business standpoint is the mirroring. If we can make Australia & Hong Kong run just as fast as Europe & NA, but still keep the data in sync with corporate, it'd be worth it.

    We have already implemented SSIS and are doing all new ETL development there and starting to migrate our old DTS packages. '05 database servers are on order so we can start developing in it, but we're still in the early stages of the move, despite it being almost a year old.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • The company I work for upgraded to 2005 in February before I started here. I'm very pleased as they are one of the few companies around that have adopted it as a standard for all development and all production clients. Best bits off the top of my head are being able to rebuild indexes online (and very quickly too), and the try catch method, which makes our programmers lives so much easier.

Viewing 14 posts - 16 through 28 (of 28 total)

You must be logged in to reply to this topic. Login to reply