Transaction Promotion su database SQL Azure

Abilitando l’autenticazione tramite ASP.NET Identity 2 abbiamo avuto la necessità di creare una transazione (tramite TrasactionScope) che effettuasse la scrittura su tabelle dello stesso database ma su schemi diversi.
La situazione è la seguente:
– due stringhe di connessione identiche, una per lo schema di dominio, l’altra per lo schema ASP.NET Indentity, per le quali cambiavano i soli metadata;
– scritture che avvengono tramite ORM differenti: una tramite EntityFramework 6 Model first e l’altra tramite Entity Framework 6 Code First.

Il problema si scatena alla complete delle transazioni con il seguente messaggio: “The underlying provider failed on Open“. Esaminando l’InnerException si scopre che SQL Azure tenta di eseguire la Promotion della transazione su DTS e questo genera il problema su SQL Azure.
In realtà, consultando la documentazione ufficiale la Promotion non dovrebbe mai avvenire se le connection string sono identiche e allo stesso database.
La soluzione è quella di creare l’utente di database e cambiare conseguentemente le stringhe di connessione.


Script per creazione utente su SQL Azure:
da eseguire su database master
CREATE LOGIN myuser WITH password=[password]
GO
CREATE USER [myuser] FOR LOGIN [myuser] WITH DEFAULT_SCHEMA=[dbo]
GO
da eseguire su database specifico
CREATE USER [myuser] FOR LOGIN [myuser] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember ‘db_owner’, ‘myuser’;
GO

Gianvito Casulli

Problemi con il database collegato a una Azure web app

​Quando creiamo una web app su Azure dobbiamo associarvi un DataBase: quello predefinito per la sottoscrizione gratuita è la versione base di ClearDB di tipo mySQL​ (che ha una dimensione ridotta, 20MB, e questa dimensione non viene specificata in nessun punto della procedura di creazione della web app). ClearDB dovrebbe inoltre avvisarci tramite email del fatto che ci stiamo avvicinando al limite dei 20MB e che l’abbiamo raggiunto, ma le email non arrivano nè nel primo, nè nel secondo caso. Una volta raggiunto questo limite, ClearDB rimuove i permessi di insert e update sulle sue tabelle, rendendo di fatto impossibile anche il semplice login al back end della web app, come ad esempio nel caso in cui questa sia un sito che gira su un CMS.

Questo problema, segnalato anche da John Papa, può essere evitato monitorando di tanto in tanto lo stato del DB con dei tool di monitoraggio come SQL Manager.net o, più semplicemente, acquistando un DB più capiente nella fase di creazione della web app.

Per un ulteriore approfondimento, si rimanda all’articolo di Papa http://www.johnpapa.net/azurecleardbmysql/​

Daniele Bitetti

Transaction Promotion su database SQL Azure

/
Abilitando l'autenticazione tramite ASP.NET Identity 2 abbiamo…

Problemi con il database collegato a una Azure web app

/
​Quando creiamo una web app su Azure dobbiamo associarvi un…