The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.

Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.

It's a BeginInvoke call, which only blocks (very) briefly while the work item is queued to the dispatcher. The dispatcher in turn will execute a brief delay at some point executing the 'empty' work item.

I forget exactly what the purpose was, but I've seen something very similar done in WPF. The purpose was something like forcing the rendering to refresh. Though, I thought some "priority" (or something like that) was necessary for it to work.

I know, vague, but there could be a real purpose (that they apparently didn't leave a comment for).

WPF has the same constraint that you had under Win32 and MFC: you can only modify UI objects from the UI thread. I think the intent here was to promoted a UI change to the UI thread. Unfortunately, this code appeared in handlers that are already guaranteed to be called from the UI thread.

As for using Invoke/BeginInvoke though, unless it's really really obvious that it can only be called in the dispatch thread (e.g. it's in an event handler or something), perhaps it used to be used from multiple threads, or the author couldn't be sure?

There were 2 projects in the solution, neither one had any real code (I like to lay out my projects before I start working). From what I dug up, it is a VS bug that has been there for a while. (Too lazy to pull up a link)

Found this in a sp, not sure why it was done this way, @fileLength and @userId are passed in, and i've changed the names of the tables so i could post this, so i realize the tables may not make sense(they do in the real code).

we dont have an offical dba, we were trusted to check our own stuff once we proved we were doing things right (small shop). obviously nobody ever checked the proc this was in regardless of my recomending they do so.

Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.

I wouldnt have posted, well ok maybe i would have, if this was a new or junior person. If they were still around i would have tried to help them. This was written near the end of their time with the company, maybe that explains it. This person also spent a lot of time trying to prove how much smarter they were than everyone else.

Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.

I wouldnt have posted, well ok maybe i would have, if this was a new or junior
person

I said "new to SQL" and not new to programming.

And that is what I meant. Someone new to programming might be more likely to do it correctly because they don't already have expectations of how it 'should' be done. But these days either is likely to due a google search an implement it using the first example they find because neither has the necessary knowledge to filter it out.

Wow, talk about doing it the hard (and wrong) way. I suspect that this is a symptom of the state of on-the-job training in the programming world. It usually goes like "hey here's a new programmer, do this." But I still don't see how one becomes a programmer without learning the basics of SQL. No one likes code reviews, but it's useful for things like this.

Also, I love how @@FETCH_STATUS is global. I once saw an expensive production system blow-up due to a legacy code time bomb in the form of a SP using a global variable like this.