Hi Mark,
I didn't say it was an issue of parameter sniffing, and I didn't point you towards the good article about that <s>. I asked you whether you had read the article, described to you earlier in the thread.
What I said was that itmight bean issue of appropriate and dynamic query optimization, versus a cached query plan. Parameter sniffing is only one of many ways that SQL Server tries to figure out how to optimize a query. I thought the article did a good job of discussing some of what goes on during this process, and that by absorbing that you could think of ways to handle the wider issue that would be appropriate to your code. I also pointed you to a thread in which I discussed this in more detail.
While there are truly many issues with the date controls in the default parameter interface and how they behave, I don't think that what you're experiencing with the date format is implicated in the performance issue. I guess it *might* be if (say) there is a non-default param value in your proc but your report parameter allows nulls.
Let's say the report server database has a different date default than your production database in your system. I have never sat down and tested this scenario and I guess it might cause problems, So we'll look at that first.
Whether the date format is at faultis really easy to prove one way or the other, and once proven can be pretty easy to fix:
-
Create a test parameter that is of string type. SQL Server is really good about dynamic conversion of string dates to date types as you probably know.
-
place values (formatted however you want) into this version of the parameter instead of your date control parameter. Use valid dates, in both formats.
-
Does your performance change?
-
Do you get the right results but bad performance with US format date strings versus right results with good performance with AU date values?
-
Do you get the WRONG results with US format date strings, or with AU date strings?
-
Try additional permutations involving casting/converting in your proc.
-
FWIW, go ahead in the Query Analyzer and put the SAME values you see in the log into your tests there (in US format, I mean). Do you get the CORRECT results? Does performance change? Hold this thought and see below.
Another thing you can do is look at the query plan as presented by the Query Analyzer when you present the arguments different ways. See #7 above -- try presenting the date in different formats. Does the plan show the same path and the same indexes in use each time, or are some not possible because of the way the date has to be converted? When this happens, the issue isusually that the conversion must be done for each line compared in the filter. You can fix this really easily in most cases by cast/convert in the procedure so that yourSELECT line is only doing that work once.
If the plans are different, and perhaps the indexes used are different and you *can't* fix it by fixing the date before the SELECT, do you need to add an index, or perhaps rebuild one?
Moving on from the date format, as I said before it may be really important NOT to go by your interactive Query Analyzer performance because what you do there may not be used by SQL Server in determining a query plan to cache and re-use. In caseyou haven't read the other discussion that I pointed you to at (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1827775&SiteID=1), think about using RECOMPILE or other options that will force a more dynamic investigation of the query.
>L<