Steve posted a link a few months ago to a study that found out that working 40 hours / week for 2 months gave the same exact output as working...

Ya I've seen that feature elsewhere, I'll propose this feature for this site, it would definitly be a great addition.

I'm not surprised actually. If you were able to do it 500 times and now 501 is not working then the problem is with that 1. From there...

Are you sure the sp is not locking or deadlocking?

Are they any less clueless now?

Not from what I've seen here.

Well ya, add another parameter for each "nullable" parameter that says wether the user set it to null or wether you did it yourself in the application. That's longer...

Assuming you can answer the "why do you care" question...

you can run if @Age = -987654321... do whatever.

I've never seen...

Yes, you need to define an impossible value for the parameter and set that as the default value

IE : @Age = -987654321

Then you can check between not supplied and NULL...

Unsubing...

thanks for sending me 18+ e-mails to my box :w00t:.

Same difference.... it's the same core engine, different service pack. :w00t:

Look you either do it right or you use a cursor to call that sp a couple 1000 times.

I garantee you that the cursor will be slow as hell.

Redoing it...

You can always search the network or dev computer for *.rdl* files.

The last star is important because there's a slim chance that the extension is rdlc which would mean an...

How can the reports not have been built in BIDS (or anything similar)? There's no way in hell that someone touched typed all that code in XML, in notepad...

No, you need to find the 1 sku that makes the proc fail. When you read the executions results from the job you see that it succeeds a few...

Maybe I was not clear. COPY the sp and call it update inv BATCH or whatever you like and make the changes there.

There's no magic bullet for this one,...