Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Differences between SQL Server 200 and 7

Options
  • 11-03-2003 3:58pm
    #1
    yop
    Moderators, Home & Garden Moderators, Regional Midwest Moderators, Regional West Moderators Posts: 16,724 Mod ✭✭✭✭


    Move if in wrong section

    Lads

    If you have used both can u please tell me the difference between the 2 versions.

    Thanks


Comments

  • Options
    #2
    Typedef
    Closed Accounts Posts: 5,564 ✭✭✭Typedef


    Big difference is that strings in version seven can be specified like this "a string", but in version eight/2000 must be 'a string', I'm sure you can see how that is a big improvement and is a really good reason to spend €2000 on SQLServer 2000*

    Plus some of the under the hood stuff, like, srv_paramdata while still on the face of it being the same functions as in version 7 and still being supposedly supported, do really stupid things like return 8000 characters in version 7, but only 256 characters in version 8, which may be a bit of useful knowledge for you if you are rolling your own extended stored procedures.

    grr.

    *no really.


  • Options
    #3
    Talliesin
    Closed Accounts Posts: 9,314 ✭✭✭Talliesin


    Didn't know that you could use " for strings with SQL7. Can't see why you would.

    You're not quite correct in saying that srv_paramdata is "still being supposedly supported". It's deprecated and only supported at all as a backwards compatibility measure.

    While it is indeed a nuisance I think coding an extended procedure from scratch is nicer with 2000.

    XML support was SQL2000's big selling point when it was launched. While it can be very userful indeed there is often something to be said in dealing with such data at a different level (especially with a SAX-based system). From a security perspective I'm not overjoyed at some of the (disabled by default) options with XML.

    User-defined functions are extremely useful. Indexing of views is a good performance boost, and can be done in a way that allows one to isolate the non-standard code well. The addition of new trigger-types, and more flexible integrity constraints can be very handy.

    These mostly do things that can be done with SQL7 though, if perhaps with a bit more work. The big decision makers are the improved clustering, 64-GB memory support, Kerberos support, and improved scalability (in particular with regard to the number of processors). Each of those are things that most of the time are neither here nor there, but if you need them you really need them.


Advertisement