Aren't SQL Azure limitations shooting themselves in the foot?

Considering my question "Should snapshot transaction isolation be avoided in client ADO.NET applications? then, what was its main purpose?",

what is the purpose/rationale/sense under SQL Azure Database rigid limitation:

• "Both the READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION database options are set to ON in SQL Azure Database. Because SET in the开发者_如何学Python ALTER DATABASE Transact-SQL statement is not supported, these database options cannot be changed"

Isn't the latter, also, in contradiction with SQL Azure Database Connection Constraints:

• "your connection to the service may be closed due to the following conditions:

  • Excessive resource usage
  • Connections that have been idle for 30 minutes or longer"

SNAPSHOT isolation is absolutely by far the best to go with. The only correct downside, from all the links you provided, is that overhead of row versioning. There is absolutely no requirement for a 'persisted' database connection in order to use SNAPSHOT isolation. Dan Guzman's article you link is misleading at best. While it does not make a false claim, the way it formulates the issue leads to false conclusions.

You can always develop your applications using optimistic concurrency model for updates:

Read:

SELECT
      ContactName,
      ContactTitle
FROM dbo.Suppliers
WHERE SupplierID = @SupplierID;

Write:

UPDATE dbo.Suppliers
SET
      ContactName = @NewContactName,
      ContactTitle = @NewContactTitle
WHERE
      SupplierID = @SupplierID AND
      ContactName = @OriginalContactName AND
      ContactTitle = @OriginalContactTitle;

IF @@ROWCOUNT = 0 --a zero rowcount indicates data was deleted or changed
BEGIN
      RAISERROR ('Contact information was changed by another user', 16, 1);
END;

There is absolutely no requirement that the Read and the Write should occur in the same connection. And absolutely, positively, you can read and write under SNAPSHOT isolation and obtain optimistic concurrency control. The article gives an example of concurrency that relies on SNAPSHOT isolation instead of optimistic concurrency control, but of course in doing so it has silently changed everything about the application: in the second example the Read and the Write must occur in the same transaction, therefore is no longer the same scenario as the first example (it cannot be a typical read-display-post-update as the first scenario).

So no, SQL Azure does not shoot itself in the foot. Nor does SNAPSHOT isolation require persisted connections. Nor is SNAPSHOT isolation unusable with ASP.Net. I'm afraid I have to say you need to filter your input much better. Rummage a bit longer on what you find on the intertubes, assume everything is wrong until proven right, stick to the official product specifications and avoid blogs, pundits, or forum/answer sites like stackoverflow...