Connect digest : 2009-07-04

I know most readers are out polishing their grills, buying hamburger buns and preparing potato and macaroni salads.  I am recovering from a pre-4th party, so here I am, groggy and online, finally not the host of Independence Day madness.  🙂

This week I only have a few entries for the Connect digest:

=================================

#471201 : Incorrect query results with Enterprise edition indexed view substitution and NULL usage.

This is a new one filed this past week, which Microsoft believes they have fixed, in spite of the fact that several other people, myself included, have confirmed that it still exists in current builds.  It is also an issue in SQL Server 2005, which they fail to acknowledge.

=================================

#472439 : Indexed View create via CREATE SCHEMA statement can produce error 8646 during updates

Another indexed view issue filed yesterday, and also involving NULLs, in this item the submitter shows how a simple indexed view with two rows can succumb to the 8646 error (unable to find index entry) and the ominous:

 
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.

=================================

#257502 : Deprecation of sysprocesses – DMV's doesn't fully replace all columns

This is one that many of us have been complaining about since 2005 was released : because sys.dm_exec_requests only shows *active* sessions, and it is the primary place to obtain database context, it is very cumbersome to get database context for sessions that are not currently performing work.  You also can't easily get the open transaction count from the new DMVs.  This information was readily available in sysprocesses, of course, though we have been told that we should stop using this system table (actually now a backward-compatibility view) in favor of the new views.  But Microsoft simply can't deprecate sysprocesses until they duplicate its functionality elsewhere.

=================================

#472266 : Install fails when choosing a path for tempdb two folders deep

This was an interesting one filed this week, where installation of SQL Server 2008 fails if you specify a folder for tempdb that contains the name "tempdb" (which is certainly a valid approach).  The submitter did not get the symptom right; they think it has something to do with the number of folders in the path, but it is still an issue that Microsoft should look at.

=================================

SQL Management Studio 2008 – enter Data Type of datetimeoffset(0) reverts to datetimeoffset(7)

More issues with the table designer… it's like a never-ending stream of scenarios that weren't tested or were deemed "good enough."  This time someone noticed that when you tab out of a DATETIMEOFFSET column's data type, after having changed the precision to 0, it reverts to 7.  Some related Connect items:

#333445 : SSMS 2005 – Bug Table Designer substitues its own length , loses user input on changing data types

#366117 : RTM, SSMS: changing precision on datetime2 from default in table designer reverts back to 7

#124872 : Table Designer does not support newSequentialId()

#362699 : 2008 RTM, SSMS/Engine: Table designer doesn't script WHERE clause in filtered indexes

#124658 : SSMS Table Designer adds unwanted default to uniqueidentifier column

=================================

Sorry I couldn't collate more this week, but as New England is seeing the sun for the first time in weeks, I really feel the need to go out and enjoy the holiday!

Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at SQLPerformance and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a father of two, a huge hockey and football fan, and my pronouns are he/him. If I've helped you out, consider thanking me with a coffee. :-)

1 Response

  1. Ranga Narasimhan says:

    May I add this connect item to Aaron's list…this is about sql wiping out the job history.
    http://web.archive.org/web/*/http://web.archive.org/web/*/https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=368649