Articoli

“TCP Provider, error: 0 - Il computer remoto ha rifiutato la connessione di rete. Microsoft SQL Server, Error: 1225” questo semplice e significativo messaggio ci avvisa che il Server SQL, col quale stiamo cercando di collergarci, non risponde. Ci possono essere molteplici motivi di questo “disservizio”, in questo articolo viene illustrata una delle cause e la sua risoluzione.

Una volta controllato che il server sia in funzione e collegato alla rete, verifichiamo che effettivamente il servizio relativo a SQL Server 2016 sia in esecuzione.

Generalmente disponibile il supporto JSON per Azure SQL Database

Azure Blog post

MSDN Blog post

I nuovi database creati in Azure SQL Database hanno di Default il Compatibility Level 130, i database creati da qualche tempo hanno invece Default il Compatibility Level 120.

Per controllare il compatibility level corrente SELECT name, compatibility_level FROM sys.databases WHERE name = 'database_name';

Se compatibility_level non è uguale a 130, è necessario impostarlo ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = 130

Immaginate di avere il vostro bel Azure SQL Database e con una serie di indici Azure Search collegati ad altrettanti Datasource che fanno riferimento a tabelle fisiche (o viste) del db (a chi non sapesse cosa sono i servizi Azure Search consiglio vivamente questa lettura).

Il tutto in produzione con ottimi risultati in termini di performance ed usabilità.

Ad un certo punto il CTO decide che il database debba essere spostato sotto altro account Azure con conseguente cambiamento della ConnectionString. Poco male, penso tra me e me, basta cambiare la connectionstring nei relativi datasource et voilà … il gioco è fatto.

Per chi di voi non la conosce, segnalo la sezione Articoli Tecnici della libreria MSDN Italia.

Si tratta di un repository di articoli relativi a temi di sviluppo e scenari d’uso “How-To” di grande utilità per sviluppatori e professionisti dell’IT, che usano tecnologie e prodotti Microsoft.

Gli articoli pubblicati contengono esempi, soluzioni e situazioni di vita vissuta; sono scritti da MVP e da altri esperti italiani che ogni giorno condividono la propria esperienza nelle comunità tecniche, su blog e forum che trattano strumenti e prodotti Microsoft.

Vedere il supporto nativo di JSON su SQLServer 2016 (e anche su Azure SQLDatabase) mi ha fatto pensare che magari era possibile averlo in forma semplificata anche su versioni precedenti.

Tutto è nato dalla necessità di gestire un flusso di dati con una Stored Procedure in arrivo da una WebAPI. Inizialmente la WebAPI, dopo aver fatto gli opportuni controlli logici di validità, deserializzava il flusso per poi formattare una stringa da passare alla Stored Procedure. La gestione del parametro in ingresso alla SP come TABLE non sembrava possibile utilizzando EF6, quindi si è optato di mantenere la SP nello stato originale, ovvero con la stringa e altri parametri per i caratteri separatori.

I Trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza una soluzione standard e chi la fornisce, tra clienti e software vendor. Sembrano facili da scrivere, ma scrivere Trigger efficienti non è affatto semplice e quando la loro complessità aumenta, possono presentare effetti collaterali in grado di confondere persino l’autore. Tuttavia, per quanti difetti possano avere, hanno un pregio dannatamente importante: permettono di risolvere problemi che non potrebbero essere gestiti in qualsiasi altro layer applicativo. Quindi, se non potete farne a meno, non vi resta che imparare i trucchi e delle best practices per scriverli e gestirli in modo efficiente.

I più importanti linguaggi di programmazione hanno strumenti di debug integrati direttamente nell’IDE. Il debugger ha tipicamente un’interfaccia grafica che consente di esaminare i valori che assumono le variabili durante l’esecuzione, il flusso del programma (step-by-step) e permette di definire punti di interruzione in corrispondenza dei quali fermare l’esecuzione del programma.

Ogni sviluppatore ama gli strumenti di debug, specialmente quando deve capire perché un programma genera un errore o quando viene effettuato un calcolo errato.

Vi è mai successo di avere il sito web aziendale talmente lento da essere inutilizzabile? Cosa sta succedendo? Avete mai aggiornato un’applicazione all’ultima versione di SQL Server e incontrato problemi di performance dovuti all’utilizzo di un diverso Piano di Esecuzione per determinate query? La scelta di un diverso piano di esecuzione può causare questi inconvenienti!

L’identificazione e la soluzione dei problemi di performance dovuti alla scelta di un diverso piano di esecuzione da parte del Query Optimizer, richiede molto tempo. In questi casi vi sarete chiesti “Quale era il piano di esecuzione precedente per questa query? Quello che garantiva ottime performance!”.

Una delle feature più richieste dalla community degli utilizzatori e sviluppatori di Power BI era senza ombra di dubbio la possibilità di rendere pubblico, quindi senza alcun tipo di accesso previa registrazione, un report pubblicato su Power BI, un pò come da tempo fa Tableau con il suo servizio Tableau Public.

Come avrete intuito uso il passato perchè con l’ultima release del servizio Power BI è stata finalmente aggiunta questa funzionalità:

Dopo aver spodestato Oracle dalla prima posizione per quanto riguarda il mondo degli Operational Databases, ora Microsoft si conferma nuovamente Leader anche per quanto riguarda la sezione “BI e Analytics Platforms”, come riportato dalla recente news:

Gartner positions Microsoft as a leader in BI and Analytics Platforms

Oltre che il giusto riconoscimento del grande lavoro che negli ultimi anni Microsoft sta facendo nel campo della BI e degli Analytics, è anche interessante notare come Microsoft sia stata indicata come anche la società più “visionaria”, in grado quindi di avere quel “che” in più rispetto ai concorrenti che può fare la differenza.