The only thing I ever saw was a "best guess" script. It was matching the tables by finding columns with the same name and IIRC data types.

Now that will...

Thanks for the help.

And the least I can say is WOW that's screwed up.

However I was able to get myself out of it with this "simple" expression :...

add this to your where clause :

AND starttime >= DATEADD(n, -30, GETDATE())

Of course it might also make good sense to to check on the endtime instead...

Yes I think part of it is done async. However you're still starting a process outside the transaction which is outside the control of sql server db engine... never...

Grant Fritchey (1/17/2011)

---

Ninja's_RGR'us (1/17/2011)

---

I'm not even sure you have a size problem. From what you are saying the whole db takes less than 30 GB? It's very...

I'm not even sure you have a size problem. From what you are saying the whole db takes less than 30 GB? It's very small by most...

Well yes and no.

Then what you need is to mash up the periods into a single row which will then cause a single update.

Then you'll have a simple update statement...

The transaction has to wait for something external to the application before completing. It's like waiting for the mailman to pick up the mail before taking the next breath.

Also...

christopher.hawkes (1/17/2011)

---

Jeff,

Thanks for the information about UPDATE queries only updating a row once, I never realised this but now everything makes sense.

Looks like i'll be writting a loop and firing...

Well here's to plan B. Sending mails from triggers is a bad idea anyways.

Make a log table that saves the history of the processed orders.

Then create a job that...

Just a hunch, try using SET NOCOUNT ON in the trigger.

SQL08Kid (1/14/2011)

---

I agree 170GB isn't huge, and yes, I'm sure some of the SSRS queries are not written very well, but the bossman wanted a seperate reporting server so we...

BETWEEN >>> where date >= and date <=

my version >> where date >= and date <

That slight variation excludes the very first MS of the next day correcting...

No offense but 170 GB is still a rather small db. Performance shouldn't be all that bad if the ssrs queries are well written.

I was thinking about that option...

Any reason why you cannot report directly from prod (for a little while).