While looking recently online for a design pattern for implementing a generic retry of operations that could possibly fail I found a really interesting project over on CodePlex.
The SQL Fault Retry Provider project demonstrates best practices for implementing highly available database applications using SQL Server mirroring technology in the database tier.
I wrote an e-mail to Bonnie Feinberg suggesting that the SQL Fault Retry Provider, or code based upon it, should be added to SQL Server and the .NET Framework itself. Bonnie thought it was a great idea and suggested I open a work item for it.
Although CodePlex is a very popular website for open source projects the SQL Fault Retry Provider could easily go unnoticed by many architects and developers who would otherwise benefit from it.
I have since created the work item on Microsoft Connect that both Bonnie and I have voted on so that the SQL Server and the .NET Framework product teams can consider implementing this change in a future release. I would encourage you to vote on the work item especially given the comment Bonnie made on the Microsoft Connect website.
"A key reason this should be implemented in SQL Server and the .NET Framework is that it is currently not possible for user or sample code like Fault Retry to know whether an error is transient or permanent (and so determine if it should try to retry). Also, the code cannot determine if the command succeeded on the server and the response never made it back to the client due to a network issue. Retrying in this case can result in incorrect data. These issues could be overcome if SQL Server and ADO.NET were modified to reliably support this scenario."
After voting on the work item I would also encourage you to download the latest SQL Fault Retry Provider bits and explore them as it is very cool indeed.
One other suggestion I made to Bonnie was that it should be possible to import and export settings from SQL Server Management Studio (SSMS) and ideally it should be possible to import and export some settings between SSMS and Visual Studio.
It really shouldn't be necessary to define the font and color settings, or how many spaces to use in place of tabs, in both SSMS and Visual Studio. Given the fact that SSMS is based upon the Visual Studio shell many of these settings are identical.
With Visual Studio 2008 you can export settings into an Xml file with a .vssettings extension and then import those settings again at a later time or on another machine. It would be awesome to be able to do this with SSMS, possibly to a .sqlsettings file.
Bonnie and I have also voted on this suggestion and I'd encourage you to do the same if you'd like to see this feature in the next version of SQL Server or even in a service pack to SQL Server 2008.
Here are the links to the feedback items on Microsoft Connect:
SQL Fault Retry Provider: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=429652
SQL Server Management Studio Import / Export Settings: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=429646
SQL Server 2008 Settings / Fault Retry Provider
Pour de plus amples informations sur les optimisations de compilation, consultez notre Avertissement concernant les optimisations.