• Ed (unregistered)

    We used to do a lot of web work for one of the big four record companies and they had similar tests in place for software upgrades on their webservers. i think it was like 6months of testing on development servers before being rolled out onto the live ones. (not that it helped, at least three times in a row when updating they forgot to compile php with any extensions so all the live websites broke and it took them at least a week to rectify it)

    One day we came into work with emails waiting for us complaining that some sites were broken. Suspecting another upgrade we had a look at the phpinfo() output. This time they had gone from being several versions behind on the 4.x branch to a release candidate for version 5.1. Not only had they done a major version upgrade without warning anyone, they had upgraded to a release candidate... so much for 6months of testing. And it just so happened that this release candidate had a pretty serious bug in it. The sites remained broken for well over a month.

    Perfectly illustrates that industry's opinion of the internet and technology in general.

  • Ed (unregistered)

    We used to do a lot of web work for one of the big four record companies and they had similar tests in place for software upgrades on their webservers. i think it was like 6months of testing on development servers before being rolled out onto the live ones. (not that it helped, at least three times in a row when updating they forgot to compile php with any extensions so all the live websites broke and it took them at least a week to rectify it)

    One day we came into work with emails waiting for us complaining that some sites were broken. Suspecting another upgrade we had a look at the phpinfo() output. This time they had gone from being several versions behind on the 4.x branch to a release candidate for version 5.1. Not only had they done a major version upgrade without warning anyone, they had upgraded to a release candidate... so much for 6months of testing. And it just so happened that this release candidate had a pretty serious bug in it. The sites remained broken for well over a month.

    Perfectly illustrates that industry's opinion of the internet and technology in general.

  • just testing the captcha (unregistered)

    monkey

  • (unregistered) in reply to Anonymouse
    Anonymouse:
    That should (and usually will) happen to anyone in any enterprise who goes on vacation for a month at a time. If they can do without you for a month, they can do without you forever, even if you didn't bork anything up before you left.

    In many countries, 5 week of vacation a year is the norm. The real WTF is that people in the US are convinced that 2 weeks is "normal".

  • We Get It (unregistered) in reply to just testing the captcha

    Ok, we get it. The Captcha is broken.

  • waefafw (unregistered)

    Old style outer joins are deprecated in SQL Server 2005 (the old, ambiguious =, = syntax). That's the biggest change.

    And by deprecated, I mean that a query containing old style joins throws an error.

    Unless, of course, you run the database in SQL Server 2000 compatibility mode.

  • Pool's Closed (unregistered)

    One image per post? Ridiculous. Go back to the digest format.

  • Jeff (unregistered)

    We discovered a bug once when upgrading our DB Server. Certain queries used to return the results in a particular order, even though no ORDER BY clause was being used in the underlying SQL. Certain programs were relying on these queries returning results in a particular order.

    After upgrading, a couple of queries were returning records in a slightly different order. Once it was noticed, it is easy to fix by adding an ORDER BY.

    Of course, if you're expecting the results of a query to be in a certain order, you should have had an ORDER BY clause to begin with :)

  • gram (unregistered)

    just another 2 cents from me. If you don't want your things to be broken, just MOVE OUT our logic from database, FORGET about stored procedures, and you'll be happy. Things can be easily done inside your code and with O/R mapping software on the market. Let SP handle only for really hard stuff, but that's a rare case for well designed app.

  • nobody (unregistered) in reply to gram
    gram:
    just another 2 cents from me. If you don't want your things to be broken, just MOVE OUT our logic from database, FORGET about stored procedures, and you'll be happy. Things can be easily done inside your code and with O/R mapping software on the market. Let SP handle only for really hard stuff, but that's a rare case for well designed app.

    Actually, stored procedures are an extra protection against SQL injection, just in case one of your code paths or pages doesn't properly validate input. (And sometimes, this happens - especially with pages that aren't supposed to be used by the public, but are available for hackers to find)

  • waefafw (unregistered) in reply to gram
    gram:
    just another 2 cents from me. If you don't want your things to be broken, just MOVE OUT our logic from database, FORGET about stored procedures, and you'll be happy. Things can be easily done inside your code and with O/R mapping software on the market. Let SP handle only for really hard stuff, but that's a rare case for well designed app.
    So "MOVING OUT our logic from database" to a bunch of strings inside my code" will magically make it so that *= works in SQL Server 2005?

    Huh, learn something new everyday.

  • Trix (unregistered) in reply to
    :
    Anonymouse:
    That should (and usually will) happen to anyone in any enterprise who goes on vacation for a month at a time. If they can do without you for a month, they can do without you forever, even if you didn't bork anything up before you left.

    In many countries, 5 week of vacation a year is the norm. The real WTF is that people in the US are convinced that 2 weeks is "normal".

    Word. Only four weeks by default in Oz and the UK, but 2 weeks is ratshit.

    The OP spoke like a true "fiddler" who has to constantly "tweak" every configuration ever invented, with the result that nothing works unless he (and it's always a he) is there to massage it into working. If someone can't manage their work in such a way that it doesn't need to be fixed every few days, more fool them. Disasters are different, but disasters are different.

  • Trix (unregistered) in reply to
    :
    Anonymouse:
    That should (and usually will) happen to anyone in any enterprise who goes on vacation for a month at a time. If they can do without you for a month, they can do without you forever, even if you didn't bork anything up before you left.

    In many countries, 5 week of vacation a year is the norm. The real WTF is that people in the US are convinced that 2 weeks is "normal".

    Word. Only four weeks by default in Oz and the UK, but 2 weeks is ratshit.

    The OP spoke like a true "fiddler" who has to constantly "tweak" every configuration ever invented, with the result that nothing works unless he (and it's always a he) is there to massage it into working. If someone can't manage their work in such a way that it doesn't need to be fixed every few days, more fool them. Disasters are different, but disasters are different.

  • Trix (unregistered) in reply to Trix

    Buggery. Don't hit F5 after doing a form post, kids.

  • Barney Fife (unregistered)

    PHB with admin rights is scary, use VMWare to give those busybodies a sandbox to play in.

  • some1 (unregistered) in reply to Trix
    Trix:
    Word.

    Now thats a WTF!

  • broooken (unregistered)

    yep, broken

  • Saki (unregistered)

    It may have been a different database that was involved in the actual story.

  • Anon (unregistered)

    OMG, i am dealing with the same issue at work ATM.

    IT decided to upgrade our VSS database during the Christmas holiday without telling anyone (even though there are KNOWN BUGS in the version they upgraded to). We didnt notice anything was wrong until mid-january, so they claim "it couldn't have been us! We upgraded the DB in December and it broke in January!"

  • imMute (unregistered)

    I thought we agreed that the db upgrade was changed to protect the innocent... It might as well have been upgrading MySQL to SQL Server

    captcha: howdy

  • imMute (unregistered) in reply to Anon
    Anon:
    OMG, i am dealing with the same issue at work ATM.

    IT decided to upgrade our VSS database during the Christmas holiday without telling anyone (even though there are KNOWN BUGS in the version they upgraded to). We didnt notice anything was wrong until mid-january, so they claim "it couldn't have been us! We upgraded the DB in December and it broke in January!"

    umm, ANY version of VSS is broke for gods sakes theres a start menu option to scan and fix the db

    captcha: ewww

  • (cs)

    So they had a two months period of impeded revenue performance by their flagship web application because of this ....

    And a six month project with several people went down the drain.

    Man, I really, really hope that this guy was fired. Or that he is the CEO's son ....

    If the manager was not supposed to have admin access to the database servers then the sysadmins (and/or security guys) responsible for the database servers should also be fired for not guarding admin access to their production servers.

    If the manager had access then the CTO/CIO needs to go.

  • (cs) in reply to Alex Ibrahim
    Alex Ibrahim:
    My guess is that there are several factors. The most probable being that the application was developed for an even earlier version of SQL Server. I am not intimately familiar with MS SQL Server (read: only test and student deployments) but it is easy to imagine an application developed for v6.0 which may have been supported by deprecated functions in SQL 2000, but those functions are gone in 2005.

    Also, you may also be failing to consider the impact of moving from 32 to 64 bit. There are all sorts of data problems that can occur in any database undergoing such a change. Again an application coded for SQL 2000 32 bit shouldn't have many problems, but if the application is older... well.

    Finally, the fact that it is MS SQL Server may itself be an obfuscation by this sites author to "protect the innocent." They could have been moving from MySQL to Oracle on Red Hat for all we know.

    I am sure that:

    1.) IMHO, MS SQL Server is a WTF in itself.

    2.) Alex does not obfuscate products.

  • (cs) in reply to Mattg
    Mattg:
    Hmm.... 25 paid vacation days per year is pretty standard in Sweden. So it's perfectly okay for an employee to disappear for five weeks. Four is more usual, though, the last week usually goes around Christmas.

    Of course, it takes some careful planning to keep things running in July-August, but the good news is, most other people in other businesses are on vacation too.

    30 paid vacation days in Germany when you're on a stanadard five-day work week. Usually people take three week in summer. Employers and employee usually start planning employee's summer vacation around December/January.

  • Jon (unregistered)

    I'd resign, on the spot. But I'd shop that idiot first.

    J.

  • Jon (unregistered) in reply to

    Seconded. Germany has 6 weeks standard. Oh and for our amereecan cousins - most people in the western world don't work weekends, Ok ?

    J.

  • (cs)

    A manager who has administrator access to all the servers and not in the loop of things. Fabulous organisational structure. Woot!

  • gram (unregistered) in reply to nobody
    nobody:
    Actually, stored procedures are an extra protection against SQL injection, just in case one of your code paths or pages doesn't properly validate input. (And sometimes, this happens - especially with pages that aren't supposed to be used by the public, but are available for hackers to find)
    SQL injections? wake up, it is possible to use parameters in inline sql query, there is nothing needs to be especially validated.I think your code is WTF as well ;) And SP doesn't add performance gains over dynamic queries anymore
  • gram (unregistered) in reply to waefafw
    waefafw:
    So "MOVING OUT our logic from database" to a bunch of strings inside my code" will magically make it so that *= works in SQL Server 2005?

    Huh, learn something new everyday.

    hey, read, O/R mapping software, don't you think I'm just inlining all sql queries inside my code, don't you? Database abstraction layer handles difference between databases, and o/r makes simple calls to DB, all logic inside your code. In properly designed app you can replace support DLLs to switch from MySql to SQL2000 and visa versa, for example.

  • Chips (unregistered) in reply to gram
    gram:
    Database abstraction layer handles difference between databases

    now there's a real WTF!

  • Jim (unregistered) in reply to Trix
    Trix:
    :
    Anonymouse:
    That should (and usually will) happen to anyone in any enterprise who goes on vacation for a month at a time. If they can do without you for a month, they can do without you forever, even if you didn't bork anything up before you left.

    In many countries, 5 week of vacation a year is the norm. The real WTF is that people in the US are convinced that 2 weeks is "normal".

    Word. Only four weeks by default in Oz and the UK, but 2 weeks is ratshit.

    I was talking about holiday allowances over the weekend with a group of friends, and none of us (in the UK) had less than 25 days. 25 to 30 days seems to be the norm in the UK for anyone who's been at a company for over a year.

  • cyanide (unregistered)

    LOL!

  • f@ (unregistered) in reply to Jim
    Jim:
    I was talking about holiday allowances over the weekend with a group of friends, and none of us (in the UK) had less than 25 days. 25 to 30 days seems to be the norm in the UK for anyone who's been at a company for over a year.
    I'm guessing your 25-30 includes (8) Bank Holidays?
  • (cs)

    I'm an unqualified worker (only finished high school, although I'm slowly working through the uni), and I get 24 days of paid vacation per year. This doesn't include any holidays.

  • Jno (unregistered) in reply to Pap
    Pap:
    I make up my own captchas and they work!

    captcha: sexytime!

  • Jno the Robot (unregistered) in reply to Jno
    Jno:
    Pap:
    I make up my own captchas and they work!

    captcha: sexytime!

    Yeah, the captcha thing has been broken for ages. I just hit return, and posted an empty message. D'oh! Hey, Alex, I'm leaving the captcha empty again

  • gram (unregistered) in reply to Chips
    Chips:
    gram:
    Database abstraction layer handles difference between databases

    now there's a real WTF!

    arguments, please :)
  • Neomojo (unregistered) in reply to f@

    I have 25 exclusive of bank holidays

  • Stephen Touset (unregistered) in reply to SomeCoder
    SomeCoder:
    I would be curious as to know what kind of queries failed to function the same way under SQL Server 2005 opposed to SQL Server 2000.

    Seriously, every time Alex posts about some specific product, everyone starts to ask how the WTF could have possibly happened with that product. He anonymizes the posts. Okay? Stop asking.

  • AC (unregistered) in reply to Ben

    We had a PHB that tried to use this same logic for upgrading Exchange 5.5 to Exchange 2003.

    Captcha: riaa Is this post in violation of the DMCA?

  • Sandy (unregistered)

    Also just testing the make-your-own-captcha rumour... From poindexter to powerpoint.

  • KoFFiE (unregistered) in reply to gram
    gram:
    just another 2 cents from me. If you don't want your things to be broken, just MOVE OUT our logic from database, FORGET about stored procedures, and you'll be happy. Things can be easily done inside your code and with O/R mapping software on the market. Let SP handle only for really hard stuff, but that's a rare case for well designed app.

    And then you have stories like these: some time ago, in a universe not so far away, someone wrote a report-generator which works on a (postgres) database with over 5 million transactions. Nothing wrong with the code, it did exactly what it had to do and was very clean and well-designed, and I couldn't have improved performance drasticly with some code-tweaks. There was only one small problem: he did not use stored procedures for exactly the reason you mentioned.

    Anyway - estimated time for a 5-page report generation: 8 hours on a dual xeon 2.4 with 2gig ram. I first optimized the code and reduced to take 'only' 7h 30 mins... Finally I rewrote the reporting stuff so it used stored procedures. Right now, the ETA is 12 minutes... The report did some fucked up stuff - agreed, but some data processing is a lot more efficient to do inside a database engine than outside...

    And the ppl not believing a simple db upgrade from 2000 to 2005 could cause problems have never been in a big project where in such a situation. For big projects, when upgrading something trivial like the software itself or a database engine, it's not a question if compatability issues will turn up, but WHEN. Upgrading a DB server without extensive testing is like rewriting a large piece of code, checking if it compiles and then putting it into production. But well - there must be a reason for tech support no? :D

  • Benjamin Smith (unregistered) in reply to use the backups
    use the backups:
    The rogue upgrade should have been treated like any other system disaster. The systems should be have been restored to their backups.

    Why would anyone go-live with beta quality code if they had the ability to restore to backup?

    Yep. Methinks there is a deeper, undetected WTF here - inadequate backups!

    I can restore any of our servers to any of a half-dozen snapshot points over the past 2-3 months within a few hours. There's no WAY I would go forward with something like this without some serious testing...

  • jayh (unregistered) in reply to gram
    gram:
    just another 2 cents from me. If you don't want your things to be broken, just MOVE OUT our logic from database, FORGET about stored procedures, and you'll be happy. Things can be easily done inside your code and with O/R mapping software on the market. Let SP handle only for really hard stuff, but that's a rare case for well designed app.

    oh my oh my. I suppose you might do everthing with cursors too! Arrghh!

    Modern db engines have fabulous on the fly optimization, which goes totally out the window when you pull the logic outside.

  • Loren Pechtel (unregistered)

    The real WTF is a clueless manager with admin authority. If it wasn't this it would have been something else.

    Such people should be fired--by firing squad.

  • Commies Suit Ya (unregistered) in reply to Ed
    Ed:
    We used to do a lot of web work for one of the big four record companies and they had similar tests in place for software upgrades on their webservers. i think it was like 6months of testing on development servers before being rolled out onto the live ones. (not that it helped, at least three times in a row when updating they forgot to compile php with any extensions so all the live websites broke and it took them at least a week to rectify it)

    One day we came into work with emails waiting for us complaining that some sites were broken. Suspecting another upgrade we had a look at the phpinfo() output. This time they had gone from being several versions behind on the 4.x branch to a release candidate for version 5.1. Not only had they done a major version upgrade without warning anyone, they had upgraded to a release candidate... so much for 6months of testing. And it just so happened that this release candidate had a pretty serious bug in it. The sites remained broken for well over a month.

    Perfectly illustrates that industry's opinion of the internet and technology in general.

  • Tailors Suit Ya (unregistered)

    At my software company we all get: 80 hours of personal time allotted (sick days, et cetera) 80 hours of vacation time allotted add to that, 72 hours worth of bank holidays.

    In June, I will have marked 1 year anniversary, and will be allotted an additional 40 hours more in vacation time. So, 6 weeks and one day NOT working and getting paid. (potentially) I would say that I am on par with Europe. I just don't know how to spend three solid weeks on vacation. I am only used to one.

    I live in Austin, Texas, USA.

    captcha = buttpickle (gygax)

  • VARCHAR3 (unregistered) in reply to hey

    USE_SQL_SERVER = FILE_NOT_FOUND

  • EFF Five (unregistered) in reply to Boris
    Boris:
    SomeCoder:
    I would be curious as to know what kind of queries failed to function the same way under SQL Server 2005 opposed to SQL Server 2000.

    I recently upgraded one of our products to use SQL Server 2005 from 2000. The upgrade was simply a matter of setting up rights on the new server, and then importing the old database onto the new server. That's it. I didn't have to change any queries or any code. Just had to point the app at the new server.

    Granted, this app isn't doing anything too complicated but I'm still surprised to see stuff just out and out failing on 2005 vs 2000.

    If it involves moving Analysis Services from 2000 to 2005, then G-d help them. Even without it, SQL 2005 is by default much more standards compliant than 2000 was, so you get errors where there were none before. Then there is compatibility with deprecated features that were in 2000 like = and = joins

    I thought I might add that If you want to know if your SP's will fail in 2005 without upgrading your Database you can use Best Practices Analyzer Tool for Microsoft SQL Server 2000. http://www.microsoft.com/downloads/details.aspx?familyid=b352eb1f-d3ca-44ee-893e-9e07339c1f22&displaylang=en It includes a report for 2005 compatibility. Mostly it makes sure you SQL follow the 15 year old standards (ANSI SQL 92). Of course for those caught off guard you could use set the compatibility level e.g. sp_dbcmptlevel ‘foo’, 80. But compatibility modes are for weaklings ;)

  • EFF Five (unregistered) in reply to Boris
    Boris:
    SomeCoder:
    I would be curious as to know what kind of queries failed to function the same way under SQL Server 2005 opposed to SQL Server 2000.

    I recently upgraded one of our products to use SQL Server 2005 from 2000. The upgrade was simply a matter of setting up rights on the new server, and then importing the old database onto the new server. That's it. I didn't have to change any queries or any code. Just had to point the app at the new server.

    Granted, this app isn't doing anything too complicated but I'm still surprised to see stuff just out and out failing on 2005 vs 2000.

    If it involves moving Analysis Services from 2000 to 2005, then G-d help them. Even without it, SQL 2005 is by default much more standards compliant than 2000 was, so you get errors where there were none before. Then there is compatibility with deprecated features that were in 2000 like = and = joins

    I thought I might add that If you want to know if your SP's will fail in 2005 without upgrading your Database you can use the Best Practices Analyzer Tool for Microsoft SQL Server 2000. http://www.microsoft.com/downloads/details.aspx?familyid=b352eb1f-d3ca-44ee-893e-9e07339c1f22&displaylang=en

    It includes a report for 2005 compatibility. Mostly it makes sure you SQL follow the 15 year old standards (ANSI SQL 92).

    Of course for those caught off guard you could use set the compatibility level e.g. sp_dbcmptlevel ‘foo’, 80. But compatibility modes are for weaklings ;)

Leave a comment on “Practice Makes Perfect”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article