- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
$errorMsg = " Record deleted successfully !! ";
Because apparently that's an error...
Admin
Should have put it in a loop with a parameter passed in to specify how many times to delete. That's what we do at my employer.
Admin
If this is their solution, I'd love to see the problem!
Admin
Why do you hate us that much ?
Admin
I think they were trying to solve the "How do I get a lot of money fast, considering I get paid by the number of lines of code" problem.
Pretty clever since in the next sprint it will be easy to solve the "How do we get this code to run faster" problem.
They probably have a nice solution for the following phases too.
Admin
Well, to be fair, a record in MySQL can get pretty mean if you only wing it with the first delete. And if it has any child records around, you better look out.
Admin
My guess is someone doesn't know how the hell transactions work.
Admin
My guess is he wrote the code to delete the record, when he tested it he found the record was still there after the delete, so instead of concluding, "There must be an error in my code -- I'm deleting the wrong record or some such", he thought, "I guess the database made a mistake. I'll try telling it to delete three or four times, just to make sure it does it."
I have fond memories of a programmer I worked with years ago who wrote a COBOL program with four GOTO statements in a row, all going to the same destination. I asked him why he did this, and he said, "I wanted to make sure it really went there."
Admin
Oh, and have no-one not noticed the completely bad thing in deleting the record in the first place? Do not delete, mark record invalid or something similar instead (in which case you have the option of undelete if you messed up)!
And yea, they did not get the concept of transactions where you can do all or nothing style of changes
Admin
Anonymization fail: Every one knows Trick R.'s last name -- Trick R. Treat!
Admin
Maybe they'd gotten a case which said something like: "After delete, record still exists" Possibly caused by something else re-inserting the record. Or maybe the "id" column isn't a unique identifier, and each delete statement only deletes the first matching row (because of some wonky configuration in either mysql or php or both).
Admin
Even if that was the case i do not even want to know what kind of configuration could force SQl to behave like that and in the case of multiple records with the same ID you got a bigger problem than merely having to delete twice.....
Yazeran
Plan: To go to Mars one day with a hamer
Admin
The answer is that each item is stored in multiple consecutive rows because the item has outgrown the schema.
But since the original coder was a firm believer in consecutive indexing there is a trigger that is renumbering all rows on delete to prevent holes.
So to delete all five rows contaning the items data you have to do five deletes on the same id :D
A little like fat32 long filename support (a little)
Admin
Registered and logged in.
"Essay Help" is a spam link.
Registration doesn't solve much, does it?
Admin
I really hope pid in the other tables is supposed to be a link back to the department id. Otherwise it seems to be a game of "I don't know what type of record I'm looking at, but I know the ID, so let's delete that from everything!" Not, obviously, an ACTUAL link with foreign keys and everything, but at least one in intention.
Still, the child table deletes look buggy to me. It's running a query to find all records whose pid matches the request id, then iterating over them and for each one deleting all records whose pid (not id) matches the returned record's id. It should either delete records who id matches the returned record's id (for one-at-a-time deletion), or records whose pid matches the request id (for sooper-kool all-at-once deletion), though in the latter case there'd be no need to iterate over the result set -- except to make really sure, of course. Given that the original complaint was records disappearing, I'm afraid that this might not just be a triumph of anonymisation.
Also cringeworthy is the way some queries treat the id or pid as a number and some treat it as a string. (I notice that the request ID is tested to make sure it is a string composed of digits... whichever way that works, it can't be good.) If it really is a string, I bet that makes life interesting when someone tries to delete a record whose ID starts with 0.
All in all, it's rather a pity that they've never heard of referential integrity - and, for the advanced class, ON DELETE CASCADE.
Admin
I submitted a good WTF article ages ago, but flavorless crud like this continues to get posted. Sigh.
Admin
So, why not post it here, as a comment? ;-)
Admin
Sometimes we get an error when we try to delete a File or a folder for no reason , but of course there is a reason.We have many damage file or blocked files.Do not worry if we want to remove the error files or too long path files from our system,here I suggest a smooth way.So use “Long path tool” software and keep yourself.
Admin
My friend recommended this blog and he was totally right keep up the fantastic work!
Admin
I visited your website. it's too informative to me and others. I would like to visit here again. thank so much for it.