• (cs) in reply to JohnB
    JohnB:
    SarahE:
    SCB:
    Nice try:
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Now express that in SQL

    My turn...

    DELETE FROM [table] WHERE 1 = 0

    Almost the same as what I was going to do... DELETE FROM [table] WHERE HellTemp <= 0
    It could happen: Hell, MI

    Still trying after multiple reports of "spam" (fixed by replacing an "e" with a "-")

    FTFY.

    Did this thing really force you to censor the word "Hell"? This is not kindergarten, Alex.

  • Vendor Relations (unregistered) in reply to Harrow
    Harrow:
    The client's MIS manager squinted at me skeptically. "Are you sure? Nothing like this has ever happened before."

    "I'm quite sure. Your data is gone," I said. "It's not in the working set and it's not in the archived set. That kind of thing worries me. What if it's nowhere?"

    The manager dismissed my concerns with an airy wave of his paw. "Pish. Here at Initrode, we backup." He leaned back expansively. "I've been doing daily backups religiously for fifteen years."

    "Have you ever done a restore?"

    The manager sat forward. "A what?"

    The MIS manager's day was about to get much, much worse.

    -Harrow.

    The MIS Manager pelted down the stairs to the street exit. That damn DB restore took much too long to set up, and he was going to miss his lunch if he didn't hurry. That hot dog stand guy had a habit of packing up and moving blocks away.... right about now...

    He charged down the street, scattering pigeons and pedestrians. He rounded the corner...

    and heaved a sigh of relief.

    His day was about to get much, much, wurst.

  • (cs) in reply to Swa
    Swa:
    if you want to remove stuff 3 years old from a database (i suspect for performance & size restrictions?), you archive it to another database first and then remove it from the primary database. it really aint all that hard.

    Absolutely.

  • jordanwb (unregistered)

    So the computer thought that it was 2009 instead of 2006 and deleted all the transactions made in 2006 and earlier?

  • Don't hate the player, hate the game (unregistered) in reply to Patrick
    Patrick:
    ...(if using MySQL)...

    heh, yeah, like that would happen

  • (cs)

    I find it amusing that some people think that "a system of this size and importance should obviously have backups"...

    No. Really. Not that obvious at all.

  • My Name? (unregistered) in reply to Blue Collar
    Blue Collar:
    [image]

    I bet ya it wasn't the getdate function... i bet it was the Cashier doing SQL Injection from that REGISTER!!

    No, the real problem is that the old hardware (see picture) had the Y3-bug[1]. Also, it still counts in Mark and Pfennig and not in Euro. Not mentioning the buffer-overflow problem arising from the hard-coded 9,99 Mark limit, which was surely no problem until the 1920s.

    [1] Y3-bug: The built-in calendar can only handle a period of 3 years (from 1 Jan 1901 to 31 Dec 1903).

    captcha: bene

  • Franz Kafka (unregistered) in reply to Swa
    Swa:
    if you want to remove stuff 3 years old from a database (i suspect for performance & size restrictions?), you archive it to another database first and then remove it from the primary database. it really aint all that hard.

    as for the date screw-up on programmer side? i've seen worse.

    the suggested solution of getdate() functions (or variations thereof) might also go haywire if for instance your motherboard fried, you swap it with another unit, but your battery was dead. you didn't bother to check the bios, you boot up with the years old default date & blam, you could be in trouble. now, with this particular app it wouldn't be an issue (since it only deletes "3y older than x"), but relying on getdate() isn't perfect either.

    tl;dr: you shouldn't base a delete transaction on a getdate() statement.

    so you replace the mobo but neglect basic setup on the replacement. ok, fine - restore from backup and you're set.

  • Foo (unregistered) in reply to Don't hate the player, hate the game
    Don't hate the player:
    Patrick:
    ...(if using MySQL)...

    heh, yeah, like that would happen

    all kinds of government ecommerce in iowa - including electronic payment of property taxes - is handled on mySQL

    prop tax is approx $400bil in payments handled on mySQL each year.

    never had a data loss, have had massively awesome performance.

    just because you're some sort of oracle bigot....

    captcha: should be 'useless' based on all the nike spam in the sidebar.

    oh, and random breaking is what you get WHEN YOU USE ASP. I know Alex is a microsoft shill, but even at this point he has to know his system is busted.

  • My Name? (unregistered) in reply to jordanwb
    jordanwb:
    So the computer thought that it was 2009 instead of 2006 and deleted all the transactions made in 2006 and earlier?

    No! It had been told to delete everything with a date 3 years less than the systems current date.

    The computer might have thougt "WTF!". It could have said something, yes. A little hint, a litte warning... As ever, it decided to keep perfectly quiet.

    The machine could not resist the amusement it would cause, once all the data got rubbed out.

  • GreenGecko (unregistered) in reply to Nice try
    Nice try:
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Now express that in SQL

    Add a column... current. Yes / No.

  • John (unregistered) in reply to CrazyBomber
    CrazyBomber:
    I find it amusing that some people think that "a system of this size and importance should *obviously* have backups"...

    No. Really. Not that obvious at all.

    I'm assuming you are not a troll (because you sound like you really meant that).

    The size of the system is irrelevant. The importance is relative.

    Not sure in the US, but here there is a Statute of Limitations (for most things about 7 years). This means Mr TaxMan can ask all sorts of questions about your business for up to 7 years after you lodge a TaxReturn for a particular year. why anyone would delete data less than 8 years old (in this scenario) is a mystery.

    If you are in business (even a teeny tiny little business) and you value your business, you should use backups. This is not an IT thing, this is common sense. Most shopkeepers I know, have a habit of keeping the Docket Rolls from their (old) cash registers (even though finding a particular transaction on these rolls would be near impossible). Why do they do this? Because one day something might happen that means they need the information there. Have they ever needed it? Not that I know it, but common sense dictates that you protect your investments. If those investments happen to be in the form of a store, then you do absolutely everything you can to (try to) make sure you are never in a position where that store is compromised.

    A place like that should obviously have backups. That said, it is possible that it doesn't - but in that case, it serves the owner right. To have backups or not is not a question of understanding technology, it is pure common sense (and something that has been done for (almost) as long as people have issued receipts. Ever wonder why there is carbon paper in receipt books? Ever wonder why people are (usually) reluctant, even years after they have finished using a receipt book, to throw it away?

    To say that having backups on such a system is not obvious is naive at best....

  • My Name? (unregistered) in reply to John
    John:
    CrazyBomber:
    I find it amusing that some people think that "a system of this size and importance should *obviously* have backups"...

    No. Really. Not that obvious at all.

    I'm assuming you are not a troll (because you sound like you really meant that).

    The size of the system is irrelevant. The importance is relative.

    Not sure in the US, but here there is a Statute of Limitations (for most things about 7 years). This means Mr TaxMan can ask all sorts of questions about your business for up to 7 years after you lodge a TaxReturn for a particular year. why anyone would delete data less than 8 years old (in this scenario) is a mystery.

    They printed all the relevant data out, placed it on top of an old writing desk from the early victorian era. Then a photographer came and photographed every single sheet of paper. Now everything is on microfilm....

  • Null (unregistered) in reply to Foo
    Foo:
    Don't hate the player:
    Patrick:
    ...(if using MySQL)...

    heh, yeah, like that would happen

    all kinds of government ecommerce in iowa - including electronic payment of property taxes - is handled on mySQL

    prop tax is approx $400bil in payments handled on mySQL each year.

    never had a data loss, have had massively awesome performance.

    just because you're some sort of oracle bigot....

    captcha: should be 'useless' based on all the nike spam in the sidebar.

    oh, and random breaking is what you get WHEN YOU USE ASP. I know Alex is a microsoft shill, but even at this point he has to know his system is busted.

    Oracle bigot? You know Oracle owns MySQL now, right?

  • It's Me (unregistered) in reply to Vendor Relations

    "His day was about to get much, much, wurst."

    That made me laugh loud enough to be noticed by coworkers in an office down the hall. Thanks! I love puns!

    CAPTCHA: dignissim - a simulation of worthiness?

  • (cs) in reply to My Name?
    My Name?:
    John:
    CrazyBomber:
    I find it amusing that some people think that "a system of this size and importance should *obviously* have backups"...

    No. Really. Not that obvious at all.

    I'm assuming you are not a troll (because you sound like you really meant that).

    The size of the system is irrelevant. The importance is relative.

    Not sure in the US, but here there is a Statute of Limitations (for most things about 7 years). This means Mr TaxMan can ask all sorts of questions about your business for up to 7 years after you lodge a TaxReturn for a particular year. why anyone would delete data less than 8 years old (in this scenario) is a mystery.

    They printed all the relevant data out, placed it on top of an old writing desk from the early victorian era. Then a photographer came and photographed every single sheet of paper. Now everything is on microfilm....

    Not being a troll. Only being sarcastic.

    It is obvious anything of any importance should have a backup. It's all those managers who only care about reducing costs who need to figure it out though.

    I'll tell a personal story about this later :)

  • (cs) in reply to Nice try
    Nice try:
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Now express that in SQL

    delete from general_journal where needed_ind='N';

  • (cs) in reply to Vendor Relations
    Vendor Relations:
    Harrow:
    The client's MIS manager squinted at me skeptically. "Are you sure? Nothing like this has ever happened before."

    "I'm quite sure. Your data is gone," I said. "It's not in the working set and it's not in the archived set. That kind of thing worries me. What if it's nowhere?"

    The manager dismissed my concerns with an airy wave of his paw. "Pish. Here at Initrode, we backup." He leaned back expansively. "I've been doing daily backups religiously for fifteen years."

    "Have you ever done a restore?"

    The manager sat forward. "A what?"

    The MIS manager's day was about to get much, much worse.

    -Harrow.

    The MIS Manager pelted down the stairs to the street exit. That damn DB restore took much too long to set up, and he was going to miss his lunch if he didn't hurry. That hot dog stand guy had a habit of packing up and moving blocks away.... right about now...

    He charged down the street, scattering pigeons and pedestrians. He rounded the corner...

    and heaved a sigh of relief.

    His day was about to get much, much, wurst.

    I usually only have one question when interviewing DBAs:

    "Your resume mentions backup and recovery experience. Can you describe a restore you have done?"

  • Xythar (unregistered) in reply to lolwtf
    lolwtf:
    Guys, we're in a bit of a jam. We accidentally posted in 2009 an article already published in 2006.

    I guess that's why all the past WTFs mysteriously disappeared.

  • E.T. (unregistered)

    I call shenanigans.

    I've worked on several retail systems used by national chains. Every single one of them had a system where the individual stores "phoned home" to post the transactions (usually in summary, but sometimes detail) to the central database at corporate. It's required for the Sales Audit staff to close the day and reconcile to the bank. Without corporate having the data, there's no way to do chain-wide reporting. That is of course, unless you have each store manager print out the days sales reports, put them on a table, photograph them, etc. Then again, they couldn't spring for extended support, so maybe they did buy a crap package without centralization of data.

  • dag (unregistered) in reply to averageGuy
    averageGuy:
    How about: - Validating that the business date is reasonable (for example: today +/- 1 day)

    Just what I thought.

    But I wouldn't limit it for past dates, only for future ones. Like maybe at most one month in the future.

    (Not that I know what that would be useful for, I don't know anything about accounting)

  • A Developer (unregistered) in reply to Brompot

    That is indeed the case, if you run the operation near midnight. However, he said "Express it in SQL", not "PL/SQL", so I complied :)

    Perhaps:

    DECLARE TransDate DATE; BEGIN TransDate := (SYSDATE - INTERVAL '3' YEAR);

    INSERT INTO TableName_BAK SELECT * FROM TableName WHERE TRANS_DATE < TransDate; DELETE FROM TableName WHERE TRANS_DATE < TransDate; COMMIT; END; /

  • (cs)

    An Oak tree was standing in the woods minding it's own business (monitoring an acorn growing on a branch) when suddenly two bipeds arrive. He feels a squirrel coming up on the trunk...

    The Oak his day was about to get much, much worse.

    The End

  • (cs) in reply to dpm
    dpm:
    Just as he was sipping his coffee, the "Classic WTF" banner appeared on his monitor . . .

    The programmer's day was about to get much, much worse.

    To be fair, “much, much worse” ought to be reserved for Mandatory Fun Day…

  • baka0815 (unregistered) in reply to Nice try
    Nice try:
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Now express that in SQL

    Just don't truncate/delete?

  • baka0815 (unregistered)

    As already mentioned you can set a deleted flag or move the data to a different table/table space/database/whatever. Just don't remove the data.

  • Alejandro (unregistered)

    "The manager's day was about to get much, much worse.". How? Where's the end of the story? Oh! I see. That's the WTF, the end of the story is missing!

  • (cs) 
    CREATE TRIGGER delete_tablename_to_bak
BEFORE DELETE ON tablename
FOR EACH ROW
BEGIN
  REPLACE INTO tablename_BAK
  SELECT * FROM tablename
  WHERE rowid == OLD.rowid;
END;
  • (cs) in reply to Null
    Null:
    Oracle bigot? You know Oracle owns MySQL now, right?
    You know Oracle doesn't own MySQL just yet?
  • Harrow (unregistered) in reply to Alejandro
    Alejandro:
    "The manager's day was about to get much, much worse.". How? Where's the end of the story? Oh! I see. That's the WTF, the end of the story is missing!
    It means that the manager is relaxed and confident because he thinks he has been doing backups for fifteen years, but if he has never done a restore, then there's no way to know that the backups are any good.

    (In the cause of dramatic humor, they were not. We spent all morning finding something to restore from, and we almost missed lunch. Fortunately the frankwurst vendor had not gone home yet.)

    -Harrow.

  • C (unregistered) in reply to CrazyBomber
    CrazyBomber:
    It *is* obvious anything of *any* importance should have a backup. It's all those managers who only care about reducing costs who need to figure it out though.

    I'll tell a personal story about this later :)

    How much later?

  • (cs)

    I'm curious why it's necessary to delete EVERYTHING that is over a certain age. Why not just delete the oldest record to make "room" for the new one (provided there's some sort of size constraint)?

  • (cs)
    And how does one find three-year old data when the [b]system clock is not a reliable indicator[/b[? Why, by taking the business date of the newest transaction and subtracting three years, of course!

    NTP.

    I love it when people don't know tried and true solutions to a existing problem, and, as a result, gnaw at a slab of granite with their own teeth until the get something out of it, then proclaim proudly "I've invented the wheel". But in reality all they get is an asymmetrically sized polygon so structurally weak it crumbles little pieces of itself as it's dragged along into production.

    The manager's day was about to get much, much worse.

    Indeed, it would suck to be him at that moment.

  • Brian (unregistered)

    Our system does the same thing.. data older than five years is purged. But the raw data is always there so it can be restored.

  • batmanhatguy (unregistered)

    The moral of the story is.... When it comes to 'cleanup' of files i.e. deleting ANYthing, design that to be a task manually performed, not automatically performed. If your stuff is important, don't have a program that automatically deletes it for ANY reason.

  • NFG (unregistered) in reply to E.T.
    E.T.:
    I call shenanigans.

    I've worked on several retail systems used by national chains. Every single one of them had a system where the individual stores "phoned home" to post the transactions (usually in summary, but sometimes detail) to the central database at corporate. It's required for the Sales Audit staff to close the day and reconcile to the bank. Without corporate having the data, there's no way to do chain-wide reporting. That is of course, unless you have each store manager print out the days sales reports, put them on a table, photograph them, etc. Then again, they couldn't spring for extended support, so maybe they did buy a crap package without centralization of data.

    This is NOT FARK.com

    Don't call shenanigans on these stories - it means you utterly, utterly miss the point of this site.

    Your experience is not total. There are a lot of people in the world, they do weird things and you do not know them all!

  • ex-vb6-dev (unregistered) in reply to baka0815
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Never remove any data

    FTFY!

  • ex-vb6-dev (unregistered) in reply to Brompot
    Brompot:
    Assuming each statement takes a significant amount of time using 'SYSDATE' twice may produce a set of records that are deleted, but not copied.

    So you put sysdate into a variable and then use that variable in your statements.

    This may not work either. Maybe new data with the wrong transaction date are added while the old data are copied to the backup table. And maybe these new data are missed by the copy statement but not by the delete statement.

  • Anonymous (unregistered)

    Where's the rest of the story?

  • Anonymous (unregistered) in reply to The guy
    The guy:
    Nice try:
    baka0815:
    Never remove any data if there could be the slightest possibility you'll need it later.

    Now express that in SQL

    In SQL:

    Don't delete anything automatically! Only delete based on a real user's explicit request. At the very minimum, ask the user if they really want to delete the data...

    Automatically deleting data without a prompt instead of archiving or something else non-destructive is TRWTF.

    SP2-0734: unknown command beginning "Don't dele..." - rest of line ignored.

    Doesn't seem to be working...

  • Pluc!! (unregistered)

    WTF? o.0 don't get it

  • al (unregistered) in reply to Nice try

    update orders set deleted = 'Y' where order_id=%1

Leave a comment on “Classic WTF: Don't Worry, We'll Fix It!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article