Articoli

Nell’articolo precedente, il secondo di questa serie, abbiamo descritto come installare il framework tSQLt, il tool SQL Test di Red-Gate e come avviene l’esecuzione di una unit di test. Ora è giunto il momento di scrivere il nostro primo test! Useremo gli strumenti che abbiamo descritto in precedenza!

Specifiche e requisiti

Scriveremo la nostra prima unit di test per verificare i requisiti di un trigger che ci è stato commissionato dall’Azienda inventata Adventure Works LTD il cui database è disponibile per il download su questo repository di GitHub. Il database AdventureWorks2017 contiene la tabella Product riferita allo schema Production. La tabella Product rappresenta l’anagrafica dei prodotti gestiti e commercializzati dall’Azienda che vi ha commissionato un trigger per impedire l’inserimento di nuovi prodotti aventi come “scorta di sicurezza” valori minori di 10. L’Azienda desidera quindi avere sempre una scorta di magazzino pari a 10 unità. La scorta di sicurezza è un dato molto importante per le procedure automatiche di riordino dei materiali, che ne tengono conto per l’emissione degli ordini a fornitore o degli ordini di produzione. Per semplificare l’esempio, il trigger risponderà soltanto all’evento OnInsert, per i comandi INSERT.

Nell’articolo precedente, il primo di questa serie, abbiamo descritto che cosa è lo Unit Test e perché è importante prevederlo anche durante lo sviluppo di soluzioni database con T-SQL. In questo secondo articolo descriveremo come installare il framework tSQLt e faremo una breve introduzione a SQL Test, il tool di Red-Gate che semplifica la gestione e l’esecuzione dei test in SQL Server. Descriveremo infine come avviene l’esecuzione di un test case.

Questo articolo è il primo di una serie di post in cui tratteremo l’importante tema dello unit testing applicato allo sviluppo di soluzioni database in T-SQL per SQL Server. Let’s start!

Cos’è lo Unit Test?

Lo unit test è un livello di test del software che ha lo scopo di testare una porzione di codice discreta. La parola “unit” si riferisce alla più piccola porzione di codice che è possibile testare separatamente, una funzione o una procedura autonoma che può essere testata in modo isolato. Nello sviluppo di soluzioni database, la “unit” è tipicamente una stored procedure (un trigger) oppure una function. Quando eseguiamo lo unit test di una stored procedura o di una function il test dovrebbe essere focalizzato esclusivamente sul codice che stiamo testando e non su come la procedura interagisce con le alte, è molto importante quindi definire da subito il “System Under Test” (SUT) e isolarlo in modo che non venga influenzato dal comportamento di altre procedure richiamate all’interno di quella che si desidera testare.

Chi ha avuto l’opportunità di sviluppare applicazioni per trasportare i prodotti da un luogo ad un altro, ha appreso che per gestire in modo efficiente la movimentazione delle merci all’interno di un magazzino è necessario adottare un sistema di movimentazione basato su codici a barre.

Il codice a barre è la rappresentazione grafica di una sequenza di numeri e altri simboli. La rappresentazione consiste di linee (barre) e spazi. Un codice a barre è tipicamente composto da cinque parti, una di queste è la cifra di controllo, nota anche come check digit. L’algoritmo di calcolo della cifra di controllo è descritto in questa pagina del sito di GS1, l’associazione internazionale che si occupa di diffondere gli standard progettati per migliorare l’efficienza della filiera domanda-offerta, tra questi c’è anche lo standard relativo ai codici a barre. In questo articolo abbiamo descritto una possibile implementazione dell’algoritmo di calcolo della cifra di controllo in TSQL, in quell’occasione abbiamo trattato il calcolo del check digit per un barcode EAN13. Recentemente, ho avuto l’occasione di migliorare la soluzione implementando le funzioni mancanti che permettono di calcolare il check digit per i seguenti tipi di barcode:

Introduzione

Nell’articolo Automazione delle attività di manutenzione in Azure SQL Database abbiamo descritto le attività e le possibili soluzioni per effettuare la manutenzione dei database in Azure SQL; abbiamo inoltre descritto i servizi più opportuni da utilizzare, offerti dalla piattaforma Microsoft Azure.

In questo articolo verrà approfondita la soluzione che permette di effettuare le attività di manutenzione database in Azure SQL attraverso l’utilizzo di Azure Elastic Job Agents che esegue processi le cui definizioni sono archiviate all’interno di un database Azure SQL. Un processo è uno script T-SQL pianificato o eseguito ad-hoc su un gruppo di database in Azure SQL.

Introduzione

Azure SQL Database non possiede un servizio di schedulazione nativo paragonabile a SQL Agent presente nelle istanze on-premise. Quando si implementano soluzioni database in Azure SQL, dopo la fase di progettazione dello schema del DB, devono essere studiate le possibili soluzioni per effettuare le attività di manutenzione database come Integrity Check, Index Rebuild ecc.. ad esclusione dell’attività di Backup che ha già un’ottima configurazione di default fornita dalla piattaforma.

Introduzione

Sarà successo anche a voi di dover modificare il tipo di dato di una colonna presente da tempo in una tabella di un database SQL Server e probabilmente vi sarete scontrati con l’errore 5074 che segnala l’impossibilità di modificare la colonna a causa della presenza di oggetti collegati come Primary Key, Foreign Key, Indici, Vincoli (di univocità e non), Statistiche, ecc..

Ecco un esempio dell’errore 5074:

Msg 5074, Level 16, State 1, Line 1135 - The object 'objectname' is dependent on column 'Columnname'.

Come già annunciato allo scorso Ignite, una delle nuove (tra le tante) feature di SQL Server 2019 accolta con ovazione dei presenti è la possibilità di ottenere informazioni più complete rispetto al tanto odiato messaggio

La buona notizia è che è possibile abilitare la stessa funzionalità anche su SQL Server 2017 (e con la SP2 su SQL Server 2016) installando la CU12 e abilitando trace flag 460.

Qui trovate tutti i dettagli.

Il team Database Migration del product group di SQL Server ha creato i seguenti strumenti e servizi per facilitare le operazioni di migrazione tra diverse versioni di SQL Server, tra on-premises e cloud.. ma non solo! È anche possibile fornire il vostro feedback scrivendo a @Data_Migrations (datamigration at microsoft dot com).

Se state valutando la migrazione a SQL Azure, vi consiglio di leggere questo white paper: Choosing your database migration path to Azure.

Microsoft Docs è la nuova piattaforma utilizzata da Microsoft per condividere documentazione tecnica di altissima qualità su tecnologie Microsoft e prodotti ad esse correlati. La documentazione è ospitata su GitHub ed è aperta alle modifiche.

Le community tecniche di tutto il mondo hanno ora l’opportunità di migliorare sia la qualità della documentazione localizzata nelle diverse lingue, sia di attivare il processo di modifica del contenuto dell’articolo originale su Docs.

Quante volte avete pensato che la traduzione in Italiano (di un articolo tecnico, di messaggio o di una voce di menu) potesse essere migliorata? Oggi abbiamo l’opportunità di farlo!