<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Alexander Kuznetsov</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/default.aspx</link><description /><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Inline UDFs do not prevent parallel execution plans</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/02/20/inline-udfs-do-not-prevent-parallel-execution-plans.aspx</link><pubDate>Wed, 20 Feb 2013 14:23:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:47833</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>0</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/47833.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=47833</wfw:commentRss><description>Lots of things can prevent parallel execution plans, but inline UDFs are not one of them. Inline UDFs are essentially macros - they are at least as fast as CTEs. As such, the optimizer can produce exactly the same parallel execution plans whether if our...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/02/20/inline-udfs-do-not-prevent-parallel-execution-plans.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=47833" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/sql+performance/default.aspx">sql performance</category></item><item><title>Using constraints to enforce uniqueness of ordered sets of rows</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/28/using-constraints-to-enforce-uniqueness-of-ordered-sets-of-rows.aspx</link><pubDate>Mon, 28 Jan 2013 20:10:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:47366</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/47366.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=47366</wfw:commentRss><description>Even the simplest data integrity rules are not easy to implement in the database if instead of individual rows we need to deal with groups or subsets. For example, making sure that a column value is unique in a table is as trivial as creating a unique...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/28/using-constraints-to-enforce-uniqueness-of-ordered-sets-of-rows.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=47366" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Data+Integrity/default.aspx">Data Integrity</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/T-SQL/default.aspx">T-SQL</category></item><item><title>The client code that handles timeouts</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/10/the-client-code-that-handles-timeouts.aspx</link><pubDate>Thu, 10 Jan 2013 21:05:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:47107</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/47107.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=47107</wfw:commentRss><description>After timeouts we need to make sure that active transactions, if any, are rolled back. All timeout handling must be done on the client. This post provides the implementation and unit tests. Implementation The following class extends SqlCommand and rolls...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/10/the-client-code-that-handles-timeouts.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=47107" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Error+Handling/default.aspx">Error Handling</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/T-SQL/default.aspx">T-SQL</category></item><item><title>After the timeout</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/09/after-the-timeout.aspx</link><pubDate>Wed, 09 Jan 2013 18:23:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:47087</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/47087.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=47087</wfw:commentRss><description>After the timeout, we may sometimes, but not always, end up with an outstanding transaction. If this is the case, we need to rollback the transaction ourselves. Otherwise the consequent commands which use the same connection might not work as expected....(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2013/01/09/after-the-timeout.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=47087" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Ado.Net/default.aspx">Ado.Net</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Error+Handling/default.aspx">Error Handling</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/T-SQL/default.aspx">T-SQL</category></item><item><title>Book Review: Pro SQL Server 2008 Relational Database Design and Implementation</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/09/24/book-review-pro-sql-server-2008-relational-database-design-and-implementation.aspx</link><pubDate>Mon, 24 Sep 2012 16:56:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:45329</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/45329.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=45329</wfw:commentRss><description>Investing in proper database design is a very efficient way to cut maintenance costs. If we expect a system to last, we need to make sure it has a good solid foundation - high quality database design. Surely we can and sometimes do cut corners and save...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/09/24/book-review-pro-sql-server-2008-relational-database-design-and-implementation.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=45329" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Book+Review/default.aspx">Book Review</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Design/default.aspx">Database Design</category></item><item><title>Awesome videos on Agile</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/18/awesome-videos-on-agile.aspx</link><pubDate>Mon, 18 Jun 2012 20:45:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:43941</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>0</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/43941.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=43941</wfw:commentRss><description>The following videos are a must-see for anyone interested in Agile methodology: Decisions, Decisions Embracing Uncertainty Patterns of Effective Delivery Enjoy!...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/18/awesome-videos-on-agile.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=43941" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Agile+Development/default.aspx">Agile Development</category></item><item><title>Yet another use of OUTER APPLY in defensive programming</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/yet-another-use-of-outer-apply-in-defensive-programming.aspx</link><pubDate>Wed, 06 Jun 2012 21:58:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:43779</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/43779.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=43779</wfw:commentRss><description>When a SELECT is used to populate variables from a subquery, it fails to change them if the subquery returns nothing - and that can lead to subtle bugs. We shall use OUTER APPLY to eliminate this problem. Prerequisites All we need is the following mock...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/yet-another-use-of-outer-apply-in-defensive-programming.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=43779" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Catching multiple exceptions on the client is robust and easy</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/catching-multiple-exceptions-on-the-client-is-robust-and-easy.aspx</link><pubDate>Wed, 06 Jun 2012 17:30:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:43766</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/43766.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=43766</wfw:commentRss><description>Maria Zakourdaev has just demonstrated that if our T-SQL throws multiple exceptions, ERROR_MESSAGE() in TRY..CATCH block will only expose one. When we handle errors in C#, we have a very easy access to all errors. The following procedure throws two exceptions:...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/catching-multiple-exceptions-on-the-client-is-robust-and-easy.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=43766" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Error+Handling/default.aspx">Error Handling</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Avoiding nested transactions might not improve performance.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/08/avoiding-nested-transactions-might-not-improve-performance.aspx</link><pubDate>Wed, 08 Feb 2012 18:09:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41577</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>10</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41577.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41577</wfw:commentRss><description>Beginning a transaction only when @@TRANCOUNT=0 might not improve performance at all. At least, I did not notice any difference whatsoever. No matter if I use this pattern: BEGIN TRAN ; -- (snip) COMMIT ; or a more complex one: DECLARE @trancount INT...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/08/avoiding-nested-transactions-might-not-improve-performance.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41577" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transactions/default.aspx">Transactions</category></item><item><title>Using XACT_ABORT ON may be faster than using TRY...CATCH</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/using-xact-abort-on-may-be-faster-than-using-try-catch.aspx</link><pubDate>Wed, 01 Feb 2012 22:25:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41497</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41497.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41497</wfw:commentRss><description>To ensure atomicity of transactions, we can use XACT_ABORT ON or wrap the transaction in TRY block and rollback in CATCH block. In some cases, the XACT_ABORT ON approach uses noticeably less CPU. I am posting repro scripts. Please run them, tweak them,...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/using-xact-abort-on-may-be-faster-than-using-try-catch.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41497" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Data+Integrity/default.aspx">Data Integrity</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transactions/default.aspx">Transactions</category></item><item><title>Wrapping related changes in a transaction may use less CPU.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/wrapping-related-changes-in-a-transaction-may-use-less-cpu.aspx</link><pubDate>Wed, 01 Feb 2012 22:02:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41495</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41495.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41495</wfw:commentRss><description>Wrapping related changes in a transaction is a good way to ensure data integrity. Besides, in some cases it just runs noticeably faster, using less CPU. As usual, I am posting repro scripts, which you can run, tweak, and see for yourself. Environment...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/wrapping-related-changes-in-a-transaction-may-use-less-cpu.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41495" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Data+Integrity/default.aspx">Data Integrity</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Yet another gotcha: variables' scopes do not end where they should.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/25/yet-another-gotcha-variables-scopes-do-not-end-where-they-should.aspx</link><pubDate>Wed, 25 Jan 2012 22:09:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41315</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>11</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41315.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41315</wfw:commentRss><description>Be careful: unlike most other languages, T-SQL does not limit variables' scope to the block where the variable has been defined. For example, the following snippet compiles and runs: -- @to is not in scope yet -- the line below would not compile --SET...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/25/yet-another-gotcha-variables-scopes-do-not-end-where-they-should.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41315" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/consistency/default.aspx">consistency</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Running OLTPish system without deadlocks, and loving it.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/04/running-oltpish-system-wihtout-deadlocks-and-loving-it.aspx</link><pubDate>Wed, 04 Jan 2012 22:31:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40808</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>9</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/40808.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=40808</wfw:commentRss><description>Our OLTPish mixed load system has not had a single deadlock since last April, and we just love it. I would not make any blanket statements, but I think in our case being deadlock-free just makes a lot of practical sense. Of course, in other cases in might...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/04/running-oltpish-system-wihtout-deadlocks-and-loving-it.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=40808" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Deadlocks/default.aspx">Deadlocks</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Refactoring large live OLTP tables without downtime</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/03/refactoring-large-live-oltp-tables-without-downtime.aspx</link><pubDate>Tue, 03 Jan 2012 18:11:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40746</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>0</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/40746.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=40746</wfw:commentRss><description>Refactoring tables does not have to be such a big deal. We do not have to shut modifications down, migrate all data into new structure, deploy modified modules, and do it all at once, while the system is down. Doing all migration at once may be risky,...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/03/refactoring-large-live-oltp-tables-without-downtime.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=40746" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Agile+Development/default.aspx">Agile Development</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Refactoring/default.aspx">Refactoring</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/T-SQL+Programming/default.aspx">T-SQL Programming</category></item><item><title>"Trusted" Foreign Keys Allow Orphans, Reject Valid Child Rows</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/10/17/trusted-foreign-keys-allow-orphans-reject-valid-child-rows.aspx</link><pubDate>Mon, 17 Oct 2011 17:15:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:39107</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>11</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/39107.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=39107</wfw:commentRss><description>In SQL 2008 R2, MERGE does not implement foreign keys properly. I will show both false negatives (valid rows are rejected) and false positives - orphan rows that are allowed to save. False Negatives The following tables implement a very common type/subtype...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/10/17/trusted-foreign-keys-allow-orphans-reject-valid-child-rows.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=39107" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Data+Integrity/default.aspx">Data Integrity</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item></channel></rss>