• (cs) in reply to savar
    savar:
    By the way, I think a law should be passed that says all Terminal emulators use the mouse buttons like this. I can't work on any other terminal other than PuTTY anymore without cursing out loud.
    Do youreself a favour, and set Window->Selection->xterm. This way you'll get the behaviour that's standard on most terminals.
  • ctd (unregistered)

    Worked on a tech support line once.

    The most frustrating call I ever got:

    A user had deleted a file. Being in the heyday of MS-DOS, she had heard of a way to "undelete" files. Not knowing exactly how, she adventureously looked thru the DOS command directory, and found a program that sounded about right - RECOVER.COM. She ran it, specifying the lost file, and hoped to see her lost file again.

    Ooops.

    RECOVER does not undelete files. RECOVER presumes that the entire directory tree has been irrevocably corrupted, and _without_asking_ trashes said directory tree and rebuilds it from the FAT table ... and names _every_ file FILE0001.REC, FILE0002.REC, ...

    Everything was there and in place. All files were intact. The entire directory structure was correct. It's just that every file _name_ had been wiped.

    Frustrating? everything was there; we just had to figure out every file's name. Got backups? no. Figured rebuilding all from scratch was faster. Hello FORMAT.COM...

  • Enagdin (unregistered)

    Nobody have seen the movie office space? Those companynames sounds familiar :P.

    Btw, nice movie ^^


    I've done something like that about 6 months ago. 24:30 oclock. little typo: rm -r / (had to be ./). Hmm, why is removing that tiny dir lasting so long?

  • noname (unregistered) in reply to Juliio C. Oliveira
    Anonymous:

    man, I remenber the day a accidentally issued a halt command on a remote production server... 30 minutes to get someone to press the f*** power button...
     

     

    I used to work as helpdesk/sysadmin at a university. I had to have root access to certain solaris servers. When I left for the day I had the (bad) habit of typing 'kill -9 -1'. Which works fine until you find out you typed that in the terminal connected to the file server.....The upside is we had a good system which recovered itself, so the only damage was people not being able to do any work for 30 minutes at the end of the day. You know, when students finally decide to show up and do something.

  • (cs)
    Alex Papadimoulis:

    Gobbledygook, for those unfamiliar with it, is a technical term that refers to the end result of a noisy modem connection, a Unix shell, and a buggy ERP system. For whatever reason, when these are brought together, a random bouquet of ASCII characters get dumped into whichever directory is currently selected. This leads to a big mess whenever someone tries to list the contents of the unfortunate directory.  At best, a few bizarre file names are seen; at worst, the connection gets disconnected and locks up the client.

    For some reason, this is the thing that's blowing my mind: by the time she's old enough to be able to grok the concept of data communications, she will have no concept of line noise.

    My memories of MUSHing over a 4800 baud connection are my only relics of a time long passed. 

     

  • Jason (unregistered) in reply to Enagdin

    Anonymous:
    Nobody have seen the movie office space? Those companynames sounds familiar :P.

    Btw, nice movie ^^


    I've done something like that about 6 months ago. 24:30 oclock. little typo: rm -r / (had to be ./). Hmm, why is removing that tiny dir lasting so long?

     You must be new here. Those company names are the defacto for anonymizing an entry, to the point where it's not mentioned, it's expected.

     

  • catfood (unregistered) in reply to marvin_rabbit

    *.dbf?

    *.idx?

     FlagShip homie!

    Captcha: knowhutimean

  • (cs)

    I've done something nearly as stupid. Trying to move files from one drive to another, using two term windows, and forgetting which window I was typing in... I moved files off the good drive, and then reformatted the slowly-going-bad drive. Doh!

  • (cs)

    Rule number 2 of consulting has to be 'if you don't recognize what you're seeing, STOP'.  I could list countless times where I witnessed and/or had to stop someone mid-destruction of a system because they were just making on-the-fly judgement calls, all of which wrong, in order to continue progress on some procedure when they should've stopped at the first thing they didn't recognize (i.e. jumbled characters, odd prompt, etc).

  • jrrs (unregistered) in reply to Carnildo

    Hopefully, I'll always remember to 'test' a command with echo when I use wildcards:

    echo rm *

    --Jim 

  • Paul Winkler (unregistered)

    my wife recently sold her old ibook.  I told her to delete all her files after she transferred everything to the new computer.

    So she dragged /Applications into the trash.

     
    Wiping the drive and reinstalling was a better idea anyway :)

     

  • (cs) in reply to marvin_rabbit
    marvin_rabbit:

    Rule number 1 when working on a client's server... have a backup.

    So I needed to copy a live data.dbf and data.idx files to a backup folder.

    What I meant to do this: cp data.* backup

    What I ended up doing is this: cp data.*

    Unix kindly expanded my command to the equivilent of: cp data.idx data.dbf

    and made a copy of the index, overwriting the database.  My boss says "well, didn't you make a backup?"  I said "I was TRYING to make the backup!"

    Ah, yes.  I was bitten by this one myself while logged into a Unix shell account from a Windows machine whose command prompt I was also using.

     It's very easy to get the differences of Windows and Unix syntax a bit muddled in such an arrangement.

    In Windows, "copy \otherdir\*" copies everything from otherdir to the current directory.

    In Unix, "cp /otherdir/*" does what's described in the quote above.

    Which is not good when the first file in /otherdir/ is a compiled Java class from a homework assignment, and the second file is its source code whose backup is seriously out of date... 

  • Anonymous (unregistered) in reply to Thanks, but no thanks.

    That Unix probably understood -i; it likely didn't understand argument reordering.... -i needed to come first.

  • none (unregistered) in reply to rp

    That is why modern Linux systems have sash. It is not dynamically

    linked and has lots of useful builtin commands. As long as you don't 

    delete sash you can usually recover.

     

  • MySQL Carnasaur (unregistered) in reply to none

    While everyone's sharing their 'oops' moments:

     UPDATE important_table SET status=[aborted status] WHERE id-123456;

    The simple substitution of - for = has the amusing effect of setting the abort status for every row EXCEPT the one you wanted to update.  I painted my - key lumo green after that.

     
    We've been thinking of having a panic button fitted to everyone's desk for such situations - locks the developer's keyboard, sets off some flashing lights over their head, and snaps a picture of their ashen face for later posting to the Hall Of Shame blog.
     

  • (cs) in reply to MySQL Carnasaur
    Anonymous:

    While everyone's sharing their 'oops' moments:

     UPDATE important_table SET status=[aborted status] WHERE id-123456;

    The simple substitution of - for = has the amusing effect of setting the abort status for every row EXCEPT the one you wanted to update.  I painted my - key lumo green after that.


    We've been thinking of having a panic button fitted to everyone's desk for such situations - locks the developer's keyboard, sets off some flashing lights over their head, and snaps a picture of their ashen face for later posting to the Hall Of Shame blog.
     

     

    WOW. Just Wow.

    I never realized MySQL was so helpful. Well, maybe not exactly helpful, more like evil.

    I'll definitely read my query strings much closer now. Thanks for the tip.

     

    SE*

  • Allen (unregistered)

    I remember once effectively (but temporarily) hosing a box by untarring a tar archive in the root directory. The problem was, the tar archive contained '.' and had permissions drwx------, which pretty much blocked access to every file on the system to all non-privileged processes. Weird things started happening immediately, but being root, it didn't affect me, and I didn't notice them for a long time.

  • (cs)

    OK, here's another not-so-horrible-but-embarrassing story.  I wrote a program on VMS to monitor the amount of time users were logged in, and log them off if they had been idle for 30 minutes.  The system had lots of users and this was to free up resources.  It would give them warnings at 5 minutes and a few after that.

    The code was straightforward.  The system wakes me up at time T, I check everyone's idle status, send warnings, kill off processes, then ask the system to wake me up again at time T + one minute.

    One user went off to lunch and left his terminal paused.  Ie, type Control-S to prevent output from scrolling, Control-Q to resume (similar on many systems).  My software decided to send him a warning message.  But it couldn't because the terminal was paused and his buffer was full.  So my software blocked until he came back from lunch and typed Control-Q.  (this was all figured out from detective work afterwords)

    At that point the software proceeded to log out everyone in the building. Lots of phone calls ensued.  The culprit, was the "wake up at T + one minute".  So the software wanted to wake up at 12:00 but couldn't.  When it finally wake up, it asked to be woken up at 12:01 (even though it was really 12:45), so the system resume my program immediately.  Then it asked to be woken up at 12:02, 12:03, 12:04, etc.  Whoops...

    So the lesson I've never forgotten:  always wake up at "current time + delta", never "last time + delta".
    (I also fixed up the paused terminal problem)
     

  • George Jansen (unregistered)
    1. Back in the day, I worked on DG minicomputers running AOS/VS. They were curiously disaster-resistant; running "dir :; del #", the equivalent of "cd /; rm -rf *" would nail :PMGR (peripherals manager)  early in the going, leaving the system unable to talk to such peripherals as the disk. Then typically one could find and rename a previous version of PMGR, left behind by patching, and falling later in the hash order. Or one could hang a systape, boot off that, and get going. I still remember somebody from the prime contractor calling after our system had mysteriously stalled and asking where we kept the systapes. I felt quite righteous for a year or two, until ....
    2. Also back in the day, the Communications of the ACM ran a piece about the effect of gobbledygook input on various UNIX programs. The authors had been inspired by problems encountered working over noisy dial-up lines. The programs were not particularly robust.
  • Licky Lindsay (unregistered) in reply to Martin

    My big whoops was the time that the "build manager" of the company (the only person who was set up to be able to build ALL of our code.. really) asked me to shut down this magical machine because they had to leave early and the machine needed to be shut down gracefully before a scheduled power outage.

    At the end of the day I started a shutdown but it took for ever. I eventually got so impatient waiting for it to finish that I just yanked the power cable out of the back of the PC so I could go home.

    Next day, the thing wouldn't boot and had to be rebuilt. The whole company lost a day or so of work because of this.

    The build manager knew it was my fault but didn't tell anybody, I don't think.

     

  • moor (unregistered) in reply to lostlogic

    Anonymous:
    Couldn't he just have used 'mc' or some other console file manager to remove the files without confusing the hell out of his shell?

     QFT

    It may be dumbed down, window-ish behavior, but it sure cuts down on a LOT of errors that using scripts, wildcards, etc. creates.
     

  • ewhac (unregistered)

    Back in the early 1990's, there was a little goodie for UNIX called Columbia AppleTalk that would expose selected UNIX directories as Macintosh directory shares, and manage all that resource fork mish-mash.  We used it to edit source files "locally" on the Mac, while doing compilation and SCM on the UNIX box.  Mind you, this was back in the day when RCS held sway...

    Our working directories had a softlink named 'RCS' that pointed back to the main SCM repository.  When mounted on a Mac, this link showed up as a normal folder.

    I had just finished some kind of prototyping work, and wanted to blow away the entire working directory and restart from scratch.  I started to drag the working folder into the trash...  And abruptly stopped myself.  The Mac would be doing directory enumeration and deletion.  Supposed it followed that softlink into the SCM repository?  After thinking about it, I concluded that, for disaster to strike, two things would have to happen:

    1. The Mac would have to follow the softlink as part of a delete operation (possible, but seemed unlikely),
    2. The UNIX server would allow the Mac client to delete files out of the repository.  This seemed exceptionally unlikely, as I was connected using an unprivileged account, and all the files and directories in the repository were owned by 'rcs' who granted write permission only to itself.

    Since two bad things would have to happen, and both of them seemed unlikely, I concluded I was safe.  I dragged the folder to the trash and emptied it.

    Bad gamble.

    The Mac happily followed the softlink, since it was indistinguishable from a normal folder.  And Columbia AppleTalk, at that time, wasn't really observing account permissions and blithely deleted the repository files.

    Mere minutes later, the guy in charge of the repository was roaming the halls looking perplexed.  I immediately confessed and related my logic.  He agreed it was faultless, had it not been for some inconvenient facts.  Happily, he was a very capable guy and had backups, so we lost minimal work.

  • (cs) in reply to SomebodyElse

    Nobody seemed to mention the beauty of mounted network file systems. You don't even have to be root :).

    I once deleted half of corporate smb share mounted into one of the temporary folders I was going to cleanup. I understood that something is not right when rm started giving access errors with 
    /home/user1/temp/folder1/sharepoint/long/path/deep/into/the/network/drive/very_important_file_1

    Good thing there were files I couldn't delete, otherwise I wouldn't even have noticed.

    Edit: shares were actually mentioned while I was typing. Oh well :)

  • Rich (unregistered) in reply to Fred Trellis

    This forum, as in many forums, has a "captcha', a script that is supposed to block spam robots by asking for some "intelligence" of a poster, namely being able to decode a word.  In general it helps a little, not really keeping out a persistent spammer, but adding a small hurdle to make posting here a touch harder and hopefully make the spammer go elsewhere.  There are some really horrible programs that add fuzz and color changes, making it harder for an OCR program to scan the image.  The problem is it's sometimes hard for a real person to use.

     

    on this forum, the captcha's are a rotating list of terms you're likely to hear on the forum, e.g. brillant, Paula, enterprisey, and the like.  the captcha is just a minor inside joke, and you mention it.

    captcha: quality

     

  • W Sanders (unregistered)

    Back around 1999 Solaris used to do this kind of thing all the time. I also got used to checking /etc/passwd, /etc/vfstab, etc for appended-on garbage, which was another Solaris bad habit.

    Hasn't happened to me in a long time.

    Modern, file systems like VXFS  just disappear the file with no trace, the way it's supposed to be done.
     

  • (cs) in reply to Carnildo
    Carnildo:
    WWWWolf:

    Urrrgh. Everyone who's ever going to use *nix at all for any purpose, especially as root, should add "Unix Horror Stories" to the list of mandatory reading. (The biggest lesson it can teach is extremely relevant to this story: Be Damn Careful With rm(1).) I read this a couple of years before I touched Linux for the first time, and I suppose that's why I've never done stuff like this. =)


    I'm a little paranoid on this, but I never use wildcards when deleting files as root.

     

    That's actually a very good practice.

     

    I learned to respect asterisks the hard way. 

  • (cs) in reply to Kiss me, I'm Polish
    Anonymous:

    Yeah. That reminds me.

    It's been quite an experience, when we were to install some piece of software back in the days I worked in a helpdesk. We had remote desktops on machines at the client's site, and  the installation involved a reboot. We didn't allow the automatic reboot at the time it was suggested, thinking that running at some free time a simple "shutdown -r -f -t0" issued at the command line would be enough. The standard windows buttons in the start menu just weren't there, because of the remote access policy, so we had to do it manually.

    We just didn't expect that "shutdown" was aliased to something. Instead of a nice, quick reboot, some of the miserable ones that ran this thing saw a dialog box counting down 30 seconds to shutdown, with a comment "-r -f -t0". Sorry, no "shutdown -a" would work - not enough privileges.

    The next thing to do was to call local tech support with a "errrm... could you power on our machines? They're kinda  not responding" sentence.

    Oddly enough, this didn't happen every time, and sometimes you had the chance to issue a quick "shutdown /a" or "shutdown -a" that amazingly did the job of cancelling the whole thing, but before the end of the shift I managed to make a few friends at the local support.
     

    If you have remote desktop, you have tsshutdn, which is what you should be using. It doesn't have all the shutdown options, but it has all the basics, including remote shutdown, and it's cancelable with a control-c (eg, it's blocking). There's no dependency on having the adminpak in the path, and especially far less chance of god knows what else calling itself shutdown and installing in the systemroot...

  • Kiss me, I'm Polish (unregistered) in reply to foxyshadis
    foxyshadis:
    Anonymous:

    Yeah. That reminds me.

    It's been quite an experience, when we were to install some piece of software back in the days I worked in a helpdesk. We had remote desktops on machines at the client's site, and  the installation involved a reboot. We didn't allow the automatic reboot at the time it was suggested, thinking that running at some free time a simple "shutdown -r -f -t0" issued at the command line would be enough. The standard windows buttons in the start menu just weren't there, because of the remote access policy, so we had to do it manually.

    We just didn't expect that "shutdown" was aliased to something. Instead of a nice, quick reboot, some of the miserable ones that ran this thing saw a dialog box counting down 30 seconds to shutdown, with a comment "-r -f -t0". Sorry, no "shutdown -a" would work - not enough privileges.

    The next thing to do was to call local tech support with a "errrm... could you power on our machines? They're kinda  not responding" sentence.

    Oddly enough, this didn't happen every time, and sometimes you had the chance to issue a quick "shutdown /a" or "shutdown -a" that amazingly did the job of cancelling the whole thing, but before the end of the shift I managed to make a few friends at the local support.
     

    If you have remote desktop, you have tsshutdn, which is what you should be using. It doesn't have all the shutdown options, but it has all the basics, including remote shutdown, and it's cancelable with a control-c (eg, it's blocking). There's no dependency on having the adminpak in the path, and especially far less chance of god knows what else calling itself shutdown and installing in the systemroot...

    Couldn't close them remotely. The remote desktop was launched from a citrix console, and was inaccessible directly from our workstations. But yes, it could be a good idea to have a ctrl+c interface instead of an unclosable windows counting down from 30 to 0.

  • Mathias (unregistered) in reply to maht
    Anonymous:

    something like : 

    pg_dumpall -c | bzip2 | ssh othercomp '> 100000_customer_records.sql.bz2'

    format old_server's drive & reinstall BSD

    cat 100000_customer_records.sql.bz2 | ssh old_server '| bunzip2 | pgsql'

    bunzip2: (stdin) is not a bzip2 file.

     
    OMG

    turns out the NIC was faulty on old_server and corrupted the bz2 on the way out 

    find only other backup is a month old

    phone boss

     

     

    It's was not the nic, "ssh server <command>" actually starts a shell on the other side and the shell doen't pick up the stdin stream, what you need is a program that can read stdin and then redirect *it's* stdout to  a file - e.g "pg_dumpall -c | bzip2 | ssh server 'cat - > data.bz2'". The original command actually only creates an empty file on the remote server :-)
     

  • lw (unregistered) in reply to Anonymous
    Anonymous:

    Some time ago I did something similar.  I was trying to move /var to a new drive.  I mounted the drive to a temp directory, copied the directory, unmounted, and finally remounted /var to the new drive.

     I forgot to preserve permissions.
     

     

    Hmmmm....  just why any savvy unix admin/user always uses this instead...

     

    cd /var; tar cf - ./ | (cd /tmp/newvar; tar xf - );

    echo $?

     

    And if $? == 0 then mount /tmp/newvar as /var and rm -rf /oldvar.....  (or whatever names you like :-)

    Wonder if this guy thought to use that method in his nifiy/difty script?   tar up the gobbledygook files and move them that way?  

    Obviously not.

     

  • (cs)

    This WTF reminds me of the following: 

    Once, when I was young and caught in the middle of a big heap of WTFery I had some fault in, my boss at that place comforted me with a story that dated back to his young years when memory was still extremely short...

    At the end of a 2-year project, shortly before his well-earned vacation, he was left to save the project on a tape (to be sent to the customer) and to backup it on another tape, then delete it from the machine to make space for the next project. So he saved the project on one tape, copied that tape to another tape, and deleted the project from the machine.

    For some reason, he then wanted to have a last look on the content of the tape that was to be sent to the customer. It was completely blank. In panic, he examined the backup tape. It was also completely blank.

    So, what had happened? Well, he did not copy the full tape to the empty one, but vice-versa. Needless to say, that his well-earned vacation was cancelled and several months followed packed with overtime.

    Morale? For me in that situation: It could be worse... far, far, far worse. 

  • (cs)

    And all of a sudden, I understand the reason for the Windows message "Directory has been cloaked. This folder contains files that ensure the integrity of the system. You should not mess with these files."

    So yes, there *are* users who need that. >_<

  • schwomp (unregistered) in reply to Arancaytar

    Some years ago I was sitting at a user's MS-DOS desktop investigating an application error.

    I thought I'd have a look at the files in the directory using dir:

    C:\CRITAPPL>del *.exe

    hm..  No response..?  Are there any other file in this dir?

    C:\CRITAPPL>del *.*

    hm.. Still no response..  But wait..  !  Holy crap!

    Fortunately where was a recent backup.



     

  • JoshJ (unregistered) in reply to Stephen Touset

    While this isn't applicable to shell scripting, the "best practice" for rm is to do it first with ls, look at the output, then hit up and replace ls with rm.

  • Anonymous (unregistered) in reply to Dazed

    These weird name files that you can't even type into the shell is the only reason I have 'mc' (midnight commander, think dosshell/norton commander) installed. Load that up, select the file and delete it. Maybe 'rm' needs a '-n' parameter for deleting by inode. They are device specific, though, so I guess you need something like: "rm -n /dev/hda2:#234824". (ls -i gives inode numebrs).

  • (cs) in reply to Anonymous

    Anonymous:
    These weird name files that you can't even type into the shell is the only reason I have 'mc' (midnight commander, think dosshell/norton commander) installed. Load that up, select the file and delete it. Maybe 'rm' needs a '-n' parameter for deleting by inode. They are device specific, though, so I guess you need something like: "rm -n /dev/hda2:#234824". (ls -i gives inode numebrs).

    $ touch foo
$ ls -i foo
1550956 foo
$ find -maxdepth 1 -inum 1550956 -delete
$ ls -i foo
ls: cannot access foo: No such file or directory
$
  • (cs) in reply to lw
    Anonymous:

    Hmmmm....  just why any savvy unix admin/user always uses this instead...

     

    cd /var; tar cf - ./ | (cd /tmp/newvar; tar xf - ); 

    Hmm, is this because savvy unix admins like to be overly verbose?

    tar c -C /var . | tar x -C /tmp/newvar

    Anonymous:
    Kernel panic! Cannot mount root filesystem blah blah blah.

    You know, LILO and GRUB have this funny feature which allows you to install several kernels side by side. Wonder what that's good for. :-)

  • annoynimous (unregistered) in reply to maht
    Anonymous:

    something like : 

    pg_dumpall -c | bzip2 | ssh othercomp '> 100000_customer_records.sql.bz2'

    format old_server's drive & reinstall BSD

    cat 100000_customer_records.sql.bz2 | ssh old_server '| bunzip2 | pgsql'

    bunzip2: (stdin) is not a bzip2 file.

    There is such an SQL server, Interbase-Yaffil-Firebird... it has (had) some nasty habits.

    Beeing a versioning engine, it can made inconsystens tables.
    Say, ALTERing column adding NOT NULL check over a million-records of which some share really has NULL value in the column for months/years.
    Then, the backup wents ok, since why this check should be trigerred in reading the data ?
    Then the restore, trying to fill the table, triggers the chack - and here we have it, unrestorable backup.

    Or personally i made in Interbase 5 go mad, when added external DLL function, and then made virtual COMPUTED-BY column dependent on this function over the column. When restoring, Interbase recreated tables.... untilk he met this table, which it could not restore since it restred external functions far after the tables themselves.

    So, while backups are realy well squeezed by removing all redudant things like indices and recreatiung them on restore, if needed, they are not guaranteed to succed.
    But indeed, who reads FAQ when he is administering database ?

    Worse that, until fixed in recent Firebird, Interbase-Yaffil-Firebird need not some specific option to rewrite the existing files, leeding to the obvious scenario:<b>

    make some unlucky changes
    later ...    gback -backup database.gdb database.gbk
    Still later, realizing that the change has led to sideeffects and never tryin if the backup is restorable...gback -restore database.gbk database.gdb
    Restore failed. Database killed.
  • annoynimous (unregistered) in reply to MySQL Carnasaur
    Anonymous:

     UPDATE important_table SET status=[aborted status] WHERE id-123456;</p</div>



    One more great MySQL gotcha!

    Again on IB/Ya/FB:
    Imagine attempt to duplicate some table or some records in it.

    INSERT into table1 SELECT * FROM table2
    INSERT into table1 SELECT * FROM table1 WHERE some condition is met over fields, that new inserted records would not meet (OnInsert trigger for example)

    Maybe strange but valid requests with a little typo are easily turned into
    INSERT into table1 SELECT * FROM table1
    which makes the server continuously append just-created records to the database, then find the clones and append it again, and again...

    until disc runs 100% filled, or (novadays)... until the dtabase file grows over 4GB means that (in Interbase 6-) it wraps and new records are added from the very beginning of the databse file.


    CAPTCHA: clueless - yes, just about the stories above!
  • tbrown (unregistered) in reply to Dazed
    Dazed:
    ...it signalled a well and truly Foxtroted (sic) file system...

    Too funny, this had me on the floor!

  • dupe (unregistered)

    Wow, today's story is just a rewrite of this old thing.

    WTF indeed.

  • foo (unregistered) in reply to tbrown
    tbrown:
    Dazed:
    ...it signalled a well and truly Foxtroted (sic) file system...

    Too funny, this had me on the floor!

    Please don't reply to this comment until we're in the 800000's.

  • Hannes (unregistered)

    I once ran many queries on SQL server, had to do some checking or something to that degree (don't remember exactly). I had a few tabs open in SQL Server Studio and switched between those, running nothing but SELECT statements. But one tab had a DELETE statement, which I executed very early in the day and had completly forgotten about. One time I had a "mouse slip" and selected the wrong tab. Since all I did in the past few hours was running SELECT statements I accidentally ran the DELETE statement again, this time without a WHERE clause. :(

    Lucky for me, we had a daily backup of the database, so I could restore most of the table and only one day of work was wiped. But it's still not a good feeling if you realize that you fucked up and there's NO way of hitting an "undo last action" button.

    Another time I too ran into the "UPDATE without a WHERE clause" trap. "SET Street = 'different Name'". Great... but again, the backup saved me. phew

Leave a comment on “It Must Have Been Using Those Files”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article