- 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
Well, I've come up with a new reason not to register for this site. My handle is not registratable! Is this the reason for your name, C-Octothorpe?
Admin
Admin
I hope you're not proud of that...
Admin
There's no reason why your db server can't send emails, despite what you might read here in the comments, but it is certainly a really bad idea to do it from a trigger. If for any reason your mail server is unreachable, it will block the trigger and hang the process until it times out, potentially locking the table upon which the trigger resides. Triggers should be fast as hell.
If you put business logic in your database, the preferred method of sending emails is to throw data to a table used for queueing, then have a a separate job that polls the table.
Admin
In my mind, TRWTF is the problem solving approach used by our protagonist.
An appropriate way of dealing with a strange behaviour like this would be to (a) try to reproduce the problem in order to (b) identify and fix the actual cause before (c) repairing the damage.
Instead, this guy jumps straight to (c) and hopes that (a) and (b) get taken care of by themselves?
Admin
Admin
I am re-posting this deleted comment to combat the god-****-stupid random deletion of idiot moderators. **** off, jackasses, this is a valid comment.
**** you, mods.
Admin
Admin
The text establishes both the system as "unreliable" and the urgency of the issue. With such a system, manual intervention is most likely SOP in the course of day-to-day production support. Our hero no doubt assumed the cause was either already known (and not fixed for economic reasons) or would require an inordinate amount of troubleshooting--which, in fact, it did.
Why would you chose an unknowable amount of down time in order to perform A and B rather than go for a seemingly immediate fix? What would you tell your boss, much less the users? "Sorry, I'm looking for the root cause but this system is an unreliable turd. I'll get back to you...some time." They all already know it's a turd from having to use it, they just want to get on with life. When you look for root causes, you risk an unknowable length of down time while you fumble around trying to find a root cause--which you may not even be able to address.
Now, in this case, unfortunately for our hero, he still ended up looking like a dope while he fumbled around figuring out why his immediate fix didn't fix anything, or rather fixed only 1/1138th of the problem. But his support technique makes good sense to me. Fix the data issue now, pacify the users now, and THEN get on the developmestigration environment and look for root causes where the users don't need to see the sausage being made.
CAPTCHA: sagaciter - reading my posts makes you sagacious, I am the sagaciter
Admin
FTFY
Admin
Thanks. That makes sense.
Not trolling, I could see some company wanting to track every delete, whether a user delete or a direct delete from the db.
Admin
Admin
SDoes anyone else notice the red lines under my worreds? some kinf of pattern maybe code messege?
SpectatteSwampDesktop Search - Computing's EASY BUTTOn~!
Admin
Are you sure you didn't originally post this against "The Rockstar's Guard", dated 29th August?
Titter. This smacks of one of those comedy-movie routines where someone bursts into a room to harangue the occupants about how they have committed some indignity against him (e.g. they've misapproriated something of his), only to realise that (a) he burst into the wrong room, and is railing against a complete bunch of strangers, and (b) the indignity that was done against him never actually happened, but it was the result of his own absent-mindedness.
Admin
Want to know how division by zero works in Java? Look it up!
Admin
Admin
As for me, I find it's prudent to be polite to the mods of any forum to which I contribute, in case they decided to take pains to exclude me.
Admin
I've found it. It was "358940 in reply to 358828" on Page 4 of the previous day's comments.
(Smirks behind hand, most definitely does not laugh jeeringly and point, that would be bad-mannered.)
Admin
I though this was a joke. It really exists! They even have a map!
Admin
Why wouldn't a developer have access? He's a developer, he should have access to everything. Who has access if not the developers?
Admin
Admin
3 or 4 cups of coffee A DAY!!! You should come an live in Finland....3 cups before you get out of bed for start....
...this is what's wrong with today's programmers...obviously no concept of what coffee is or what its for...
In my day....oy YOU!! Get off my lawn!
Admin
I like that it apparently took them "a few years" to figure out that they couldn't delete reservations on the Outlook calendar. o.O
Admin
Admin
Poor martin and his poor rectum.
Was I the only one who caught that?
Admin
No you weren't regrettably - but I had to look up "pink sock". I wish I hadn't, it was as distasteful as your posts frequently are.
Admin
Admin
How else does one go back and relive those moments of feeling elite after pretending to be witty on an internet message board?
I'm actually thinking of putting all my favorite comments into a nice book, so I can read it to my children. Hell, I might even throw in the not-so-great ones too; I felt smart when I posted them.
Admin
Some days I wish it could be done to the throat too. Just imagine it. Let those images swirl through your head.
Admin
Of course, in some WTF-powered businesses, devs are given UPDATE/INSERT/DELETE powers because they have to constantly fix some DB screwup caused by WTFy code.
Example: An "Enterprisey" app that would call a WebService which applied charges on some accounts ... the webservice would sometimes barf, but the transaction might have been partially committed because each charge was made inside its own transaction. The calling app had no way to know if the transaction succeeded in these cases, so all unknown status transactions were left in an "unknown state" and had to be manually checked. WTF indeed!!!
Admin
Admin
Admin
Admin
Tracking conference rooms and providing direct interactive write access to developers is also usually not the job of a production sql server database. Please note - if a developer can open up a query window and just type 'delete * from meeting where user_login_id = "somebody"' - then a trigger is literally the only thing you can rely on. The application code layer is totally ignored in that situation. So make the application layer as nice as you want to, and in X% of the time people won't be alerted.
I like how you first delete the meeting, then look up who owned it :)
Admin
TODO: Create unit tests with >1 Row Affected
Admin
Admin
My favorite part is where Martin actually scheduled the room once a week for the next 21 years. Now that is job security. "you can't fire me, I have the conference room scheduled"
Admin
Admin
I was averaging about three to four cups a day
ONLY 3 to 4? I call shenanigans.
Admin
Admin
Aaaaand that's a friggin scandal ... no default trigger should be protected from recursive hell - how else can you guarantee:
a) integrity b) Mail-Hell
I know it's a nice noob-style default, and it's a good thing it's part of the docs but it's still a pity that the default should hide the logic ... damn docs and gotchas !
There is one good reason to allow recursive triggers : consistency. What you're talking about is "having the possibility to prevent recursion", which is of course important. Having it implemented by default is syntactic sugar hiding the horrible truth from the noobs (seriously, if there's got to be recursion check or event propagation, do it explicitly, not hidden in a default).
ms190739.aspx
So in fact, it's a noob option on by default, and everything is manageable as should be, except that for some reason MSSQL thinks that 32 levels deep nesting is enough . fail db -> now we have the REAL WTF .. you want coding advice from these guys you're sure ? ^^
And for comparison, a real dbms (PostgreSQL):
docs/9.1/static/trigger-definition.html
Where you see : programmer's responsibility, virtually limitless (although your computer might blowup after max(int8) levels of nesting ... says the legend).
As a summary: My bad, I really thought mssql could be respected, I was (a bit) wrong.
Admin
Right ... the big issue is not recursion (although I prefer to have an unused railgun in the cupboard instead of no railgun), it's SQL server having varying levels up to only 32 ... and you not even mentioning it as a major fail.
No REAL programmer would disable recursive triggers in their database.
Let's see, blade 1 in enclosure 1 is on fire, thus enclosure 1 is on fire, thus blades 2-9 are on fire. No recursion you sure ?
What about a table containing citizens from the middle ages, some of which have "the black death".. AHAAA !! recursive trigger with foreach(citizen in same city block) if(random(1-100)>p(black death contamination)) -> give black death
I like it . recursion enables black death . all smooth . I'm not sane but ... I think being affraid of recursive triggers (or black death) is for noobs, sorry.
There ARE cases where it will be the best modelisation you can have. And not using it IS a crime - wish there was death sentence though.
Admin
Tell you what, we can do better. In all logic, people will start running away when they notice too many victims of the black death, I think we can safely ADD another RECURSIVE trigger to manage the panic effect ... yum. God bless SQL.
Admin
Admin
Service Broker? Isn't that something that makes the service broke?
Admin
Name almost any design philosophy from OO onwards, databases will break it: stored procedures, transactions, cascading operations, triggers, flat data types, fixed string lengths, numeric display specifications. Databases work best with old procedural waterfall and (sometimes) iterated development dating from the old Fortran/Cobol/Lisp mindset.
Admin
Errr right sure . show me your java implementation of a transaction-safe solution and tell me it was worth developping.
Then compare performance against a good dbms ...
Also, what kind of DB have you been using .??? why do you think SP's break OOP ? transactions /cascades /triggers are an issue for you ??? is it because you'd much prefer to implement that in the much weaker language layer ?.
Flat data types , fixed string lengths, ... -- try a real dbms like PostgreSQL because you sound uninformed right there.
Databases work best as databases: i.e. basic data management layer, including enforcement of rules (real dbms only, not mysql) of any kind, fast access, transactional integrity and general ACID compliance (which, believe me, if you want to implement in <insert your language here>, is going to be slow, painful and useless).
Then ... "old procedural waterfall" vs "OO onwards" is slightly manichean don't you think ?
I've got some code where I do not use OO semantics and it doesn't prevent me from guaranteeing full reusability and all that, without any heavy syntax or language-enforced principles.
What you call design philosophies from OO onwards aren't necessarily better alternatives, they've all got strengths and weaknesses and classifying them as better is definitely not the best approach.
Admin
Was this true before you clicked Submit?
Admin
That's because, for most sane users, they could delete just fine.
If you only scheduled a one-off meeting, and tried to delete it, it would work.
If you scheduled a repeating meeting, and only tried to cancel a single instance of it at a time, it would work.
If you were only canceling a couple of instances, and it only happened rarely, you might think you just absentmindedly told it to cancel one. Or you could have chosen to just delete one and then the other.
But, this guy had made enough reservations he could repeat the behavior. And, I'm guessing, he was saying 'delete every one of them, even the ones that already happened', so there was no apparent effect at the point he was looking at on his calendar.
Yeah, that's bound to happen before a really long time. But they probably also disregarded the first couple of reported instances. "Well, I created a test meeting, and then deleted it, and it worked just fine for me."
Admin