So, a couple of weeks ago I decided to post my first bug to Microsoft Connect, an issue which I had discovered in SQL Server 2012 RC0.  Because this process took me more time than I’d expected, I‘m now blogging about my experience.

The hardest part about the whole experience was finding the actual page that needs to be used to enter and submit the content.

Submitting Content To Microsoft Connect

Are you in for a ride on the Connect site?  Here we go!

Step 1: Search For Your Product on The Connect Home Page

On the Home page, enter a search term with which you can locate your favorite product.  If you’re not signed in yet, do that first.

Step 2: Click To Participate

Once the search engine has produced the output, locate your favorite product and click the Participate action next to it.

Step 3: Submit Product Feedback

After clicking Participate, the following overwhelming screen appears.  The link that you’re looking for is called Submit Product Feedback.

Step 4: The Feedback Center

After clicking Submit Product Feedback, you end up at the Feedback Center.

Looking at the screen above, you’d think that the yellow Submit Feedback button can be used to open the page where you’d need to enter the bug details.  Well, it doesn’t…

You need to search for your issue first, to ensure it doesn’t exist already.

Step 5: The Submit Feedback Button Has Been Found, Eureka!

After you’ve performed the search for your issue, you get to the following page above.  Finally, on that page you can click a real Submit Feedback button that will bring you to the Select Feedback Form page.

Step 6: Select Your Feedback Form Of Choice

On the Select Feedback Form page, select SQL Server Bug Form to file a SQL Server issue, or select SQL Server Suggestion Form to enter a suggestion.

Step 7: Fill Out The Textboxes

Finally, the page we’ve been trying to locate when we started the adventure, quest accomplished!  With this new knowledge, we can now skip directly to step 6 through the following link: Select Feedback Form

Disclaimer: please ensure that you’re not creating duplicate bugs or suggestions, but use whatever search engine your prefer to achieve that goal!

So, here’s my New Year’s present to all of you!  And remember: have fun!

Valentino.

References

Microsoft Connect

Feedback Center

Select Feedback Form

As usual, a picture says so much more than … :

As I have posted earlier, 10.0.2531 is the version number for SP1, while 10.0.1600 is the original RTM version number.

I never really spent time looking for an answer to this.  It was obviously a bug but I could live with it and someone else would probably already have filed it as being a bug.  So recently I came across a post by Phil Brammer that mentioned this issue.  This post got a comment from Matt Masson, a developer on the SSIS team.  Have a look at the comment but in short: the version numbers that are being shown in the Object Explorer are actually the version numbers of the service’s .exe file!  And SSMS is now showing the wrong number because these files didn’t get an update in SP1.

After a little search I found the bug report on Microsoft Connect, reported on March 11, 2009, by Dan English.  Its status is Fixed but it seems that it isn’t.  At least, looking at the comments, CU5 (Cumulative Update) for SQL Server 2008 SP1 is still showing the problem.  So I guess you could go over to the Connect page and click on that Yes button if you’re interested in seeing this fixed.  After all, it could be quite misleading to novice DB guys and gals…

On this same subject, there’s another interesting post by Adam W. Saxton, a member of the Microsoft SQL Server Escalation Services Team.  In this post he takes a closer look at the SQL Server 2008 Reporting Services version number after having installed CU2.

Conclusion: if you need to find out what version your server is running, do not rely on the version numbers that you see in the Object Explorer.  As Adam explained, one way is to look at the version numbers of the files that were included in the upgrade.  But that may a bit of an overkill.  My favorite way, assuming that all components of the SQL Server installation have been upgraded to the same version, is to use the following query:

SELECT @@VERSION;

On my machine that comes back with the following result:

Microsoft SQL Server 2008 (SP1) – 10.0.2531.0 (Intel X86)   Mar 29 2009 10:27:29   Copyright (c) 1988-2008 Microsoft Corporation  Developer Edition on Windows NT 5.1 <X86> (Build 2600: Service Pack 3)

And remember, have fun!

This report cannot be run in report builder because it contains one or more embedded data sources with credential options that are not supported.  Instead of embedded data sources use shared data sources or save and view the report on the server.

Okay, no problem I thought, let’s just create a shared data source and switch to that one then.  So I opened up the Data Source Properties in Report Builder and selected the Use a shared connection or report model radio button.

Unfortunately, when running the report it threw me that same error?!  And when I open the Data Source properties again, my change was undone!  It was still using the embedded data source.

As far as I’m concerned that should be a bug.

The only way that I could switch my data source to a shared connection was by creating a new data source, which means you also need to move all datasets connected to the original data source.

Quick tip: if you first rename the original data source and datasets to something like srcMyDataset_OLD, you can give the correct name to the new one straightaway.

So I guess that’s another workaround on my list

This issue was encountered while using Report Builder 2.0 (10.0.2531.0).  I tried to reproduce it using Report Builder 3.0 (10.50.1092.20 – that’s the version of the SQL Server 2008 R2 August CTP) and I couldn’t.  Which means it has been fixed.  Good on you Microsoft!

An error occurred during local report processing.

The value provided for the report parameter ‘YourParameter’ is not valid for its type.

I encountered this error even though I had not specified a default value for the parameter.  So how can it be not valid if it doesn’t exist?

I found a perfect solution in this little article.

Apparently it has something to do with the Allow blank value checkbox.  In my report the data type for my parameter was Integer.  And as explained in the mentioned article, the Allow blank value checkbox is checked and greyed out.  Luckily the little trick of switching to String, unchecking the checkbox and switching back to Integer solves the error.

But why?  How come that an error occurs due to a setting that is greyed out?  A greyed out setting, doesn’t that mean that its value is not applicable in combination with the other settings?  Apparently not.  Well, I guess that’s a bug then, right?

If someone has a good explanation on this behaviour don’t hesitate to post a comment!

The Foreach Loop has several enumerators available.  By default it selects the Foreach File Enumerator.  However, as the screenshot below shows, there’s no way to configure it – the Enumerator configuration group just shows blank space.

This phenomenon is caused by a bug which has been reported on Microsoft Connect.  The workaround, if you really need the File Enumerator, is to select another enumerator first and then switch back to the File Enumerator.  You’ll notice that the regular controls show up and on you go, define that folder name!

And the worst part of it, in my opinion, is that, even when you close your client connection to Analysis Services, the query keeps running on the server consuming CPU and memory and will finally take it down.

The good part is that Microsoft has fixed it in Cumulative Update 2 for Service Pack 2 for SQL Server 2005.  And now of course SP3 can be used as well to fix this situation.

The bug is described here: http://support.microsoft.com/kb/935832

If you have the task to optimize performance of your server or database, Microsoft has provided an interesting additional download called the Performance Dashboard.  When you’ve installed the package, there will be some .RDL files and an interesting .CHM file in our SQL Server folder, for instance C:\Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard\.

Among this bunch of .RDLs there is one main report called performance_dashboard_main.rdl.  All other reports are used in drillthrough scenarios from the main Performance Dashboard report.  The main report can be opened by right-clicking your server in SSMS, then choose Reports > Custom Reports… and browse to the RDL.

For a more detailed explanation on the installation procedure, have a look at this Database Journal article.  And for an explanation of each report plus some screenshots, part two of that article is certainly useful as well.

Additional info is also available in the PerfDash.chm file located in the same folder as the RDLs.

A bug

Earlier this week I came across a bug in one of the stored procedures that the main Performance Dashboard report is using.  When I tried executing the report I got the following error:

Msg 535, Level 16, State 0, Line 1
Difference of two datetime columns caused overflow at runtime.

This issue manifests itself when there are open connections which have been open for a period longer than approx. 24.85 days.

You can simulate the same error by executing the following select:

select datediff(ms, '2007-12-27 08:49:50.853', GetDate())

The bug is known by Microsoft, see this Microsoft Connect page, but will not be fixed as these reports are not supported.  In the feedback you can get enough info on how to fix the issue.  I also got the above query from there although I added an m to select milliseconds instead of seconds (which would not generate the error).

I’ve solved it by modifying the usp_Main_GetSessionInfo stored procedure like this:

CREATE PROCEDURE MS_PerfDashboard.usp_Main_GetSessionInfoas
BEGIN
select count(*) as num_sessions,
sum(convert(bigint, s.total_elapsed_time)) as total_elapsed_time,
sum(convert(bigint, s.cpu_time)) as cpu_time,
sum(convert(bigint, s.total_elapsed_time))
    - sum(convert(bigint, s.cpu_time)) as wait_time,
/*
 following line gives an error when login_time > 24 days
 see http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=324906
 the line: sum(convert(bigint, datediff(ms, login_time, getdate())))
    - sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,
*/
sum(convert(bigint, datediff(s, login_time, getdate()))) * 1000
    - sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,
case when sum(s.logical_reads) > 0 then (sum(s.logical_reads)
    - isnull(sum(s.reads), 0)) / convert(float, sum(s.logical_reads))
else NULL
end as cache_hit_ratio
from sys.dm_exec_sessions s
where s.is_user_process = 0x1
END

The by default Transparent background would show as black instead of white. Obviously this is not very convenient, especially when the text is also black.

Luckily Microsoft was already aware of this issue, its KB is located here.

I managed to solve the problem by installing Cumulative Update 1 (build 3161), which can be requested for download through the following Microsoft page: http://support.microsoft.com/kb/935356/en-us.

If you don’t like installing CUs, you could wait until SP3 ships in Q3 this year (this info comes from several sources, just do a search on “sql server 2005 SP3″).