Diciamoci la verità. Il lavoro quotidiano di un informatico è quello di trovare soluzioni a problemi che nella maggior parte delle volte sono veramente complicati.

Per poter affrontare queste problematiche, ognuno si crea una propria cassetta degli attrezzi da cui attingere (con un’abilità più da prestigiatore che da informatico) pezzi di codice, tools vari o quant’altro possa servire.

Col passare del tempo però, questa cassetta degli attrezzi rischia di diventare di dimensioni titaniche, troppo grande perché possa effettivamente essere di aiuto.

Per ovviare a questo problema, la prima cosa da fare è sicuramente quella scegliere con estrema attenzione quali strumenti conservare e quali no tra l’enormità di quelli che ci vengono messi a disposizione. Il secondo passo consiste nel manutenere gli strumenti che si è scelto, aggiornarli, e soprattutto non smettere mai di guardarsi attorno, perché tali strumenti rischiano di diventare obsoleti, o addirittura inappropriati allo scopo per cui furono originariamente progettati.

Partendo proprio da questo concetto, visto che spesso per mancanza di tempo o magari solo per pigrizia non si ha modo di guardarsi attorno, ho pensato di scrivere questo articolo su SQL Server Management Objects o più brevemente SMO. Con SMO si andrà ad aggiungere alla propria cassetta degli attrezzi uno strumento che pare essere davvero poco conosciuto seppur potentissimo, abbastanza semplice da usare anche se forse come strumento di lavoro è un tantino … ingombrante !

Ma perché ingombrante ? Vi spiegherò il perché tra breve. Ma prima di cominciarne l’esplorazione, è bene fare una importante premessa: cosa fa esattamente SMO e a cosa serve ?

SMO è una delle infinite libreria di classi che rientra nell’enorme patrimonio del framework .NET.  E’ stato scritto per gestire SQL Server. Il suo scopo principale è solo quello. E’ una libreria che si presta perfettamente a compiti quali, ad esempio, elencare i database di una istanza, elencare le tabelle che vi sono contenute ed elencare le colonne di ogni singola tabella, oltre ovviamente a fornire svariate funzionalità di gestione per ognuno di questi oggetti. Consente inoltre di effettuare procedure di backup e di restore con le relative verifiche, ed altre operazioni di questo tipo, non sempre facilmente implementabili anche utilizzando una libreria potente come ADO.NET.

Il miglior esempio che si possa fare per rendersi immediatamente conto di cosa intendo per gestire, è immaginare una situazione in cui si deve poter amministrare SQL Server da una qualsiasi macchina della propria rete aziendale senza avere a disposizione Management Studio ! Per continuare ad avere la comodità di una interfaccia grafica, si decide di creare un tool ad hoc. Una volta completato il tool scritto con SMO, lo si può copiare sulla propria penna USB, e così sarà possibile accedere all’istanza di SQL Server di proprio interesse ed amministrarla, scrivendo davvero pochissime righe di codice !

Perché allora non usare sempre SMO anziché ADO.NET ?

Le risposte in verità sono più di una, ma la principale è che SMO è molto, ma molto pesante (ed ecco perché prima lo definivo ingombrante). SMO porta sulla vostra macchina, in un oggetto chiamato Server, tutta un’intera istanza di SQL Server ! Ora, non sappiamo quanto può essere grande una rappresentazione di una istanza, ma parlando di valori medi è sicuramente molto, ma molto più grande della rappresentazione di una tabella popolata con il risultato di una query, che poi è quello per cui è indicato ADO.NET.

In SMO, per fare una qualsiasi operazione, dobbiamo prima portarci in locale la copia dell’istanza di SQL Server che ci interessa, e poi, una volta connessi, possiamo cominciare a lavorare (per esempio lanciare una query per la modifica della struttura di una tabella). In ADO.NET, invece, effettuiamo solo la connessione al database e poi, tramite questa connessione, lanciamo la query. Quello che dobbiamo gestire, oltre all’oggetto connessione di per se, è il risultato della query (se c’è). Tale risultato potrà essere inserito, ad esempio, in un DataTable, ma certamente il DataTable risultant