Great, thanks both.

I have managed to build the expressions with parameters, which are passed at runtime.

Thanks again, Russell.

Great thanks.

I managed to force a query to use parallelism and found the number of cores by looking at the Parallel Operator (as mentioned).

Thanks again all.

Thanks for the suggestion.

I guess I need to come up with a query that hits all cores.

Thanks.

Thats great, thanks.

So a restore will write to disk, and at a later date SQL will write the data to memory once the user starts querying the database?...

Thanks!!

Perfect! Thanks.

The results don't include objects which have not been written/read to/from i.e. nulls. Is there a way of returning these stats? Thanks again.

Even stranger... if I perform a SELECT it works

SELECT tbl_ReportScheduleReportFilterValue.ComparisonValue_vc, 'D"' + REPLACE(CONVERT(nvarchar(50), CONVERT(date, tbl_ReportScheduleReportFilterValue.ComparisonValue_vc, 103), 127) + 'T00:00:00.000Z','/','-') + '"'

FROM tbl_ReportScheduleReportFilterValue

JOIN ReportFilter ON ReportFilter.ID = tbl_ReportScheduleReportFilterValue.ReportFilterID

JOIN tbl_ReportField...

Thanks but I have done this. I have actually given it to everyone just to be completely sure but its still failing.

Any other ideas?

Pluralsight is great and very current but may cost you.

For free vids you could look here; https://technet.microsoft.com/en-us/sqlserver/ff977043

Good luck!

Great! Thanks.

Just for reference, I came across this issue with one of our databases. In my case it was caused by changing the logical and filename for the .mdf and .ldf...

Cracked it. It was a statistics issue. They're not being updated. Thanks!

Hi - I have attached the execution plans. There is a slight difference in the number of records this because the restore took place a week ago. But...

Yes, true. My mad. You cannot restore the .mdf with the .ldf when the database was handling transactions.

steven 44886 (12/1/2014)

---

Thanks for the help.

Looks like I am out of luck. I don't have the logfile for the database (it was on local storage on the dead server -...