In questo articolo spiegherò come ottenere una classificazione per fasce di una serie di valori.

Una delle classificazione classiche di una lista di valori è per fasce (di prezzo, ad esempio): quanti articoli costano meno di 100 Euro? Quanti tra 100 e 200? e così via.

La soluzione migliore sarebbe di inserire la fascia già nel record da classificare, magari con un trigger. Questa però è una soluzione ’statica’, che prevede una classificazione rigida decisa a priori.

Potrebbe invece essere necessario creare una classificazione arbitraria, momentanea e non decisa a priori.

Per ottenere questi tipo di prospetto, si può usare una combinazione di GROUP BY e CASE, come nell’esempio che segue:

SELECT
   COUNT(Prezzo) AS [Numero Articoli],
	(CASE
		WHEN Prezzo<1000 THEN 'Bassa'
		WHEN Prezzo>10000 THEN 'Alta'
		ELSE 'Media' END
         ) AS [Fascia di prezzo]
FROM
	Articoli
GROUP BY
	(CASE
		WHEN Prezzo<1000 THEN 'Bassa'
		WHEN Prezzo>10000 THEN 'Alta'
		ELSE 'Media' END
        )

Otterremo quindi un elenco di quanti articoli sono nella fascia di prezzo ‘bassa’ (meno di 1.000 Euro), quanti nella fascia ‘Media’ (tra 1.000 e 10.000), e quanti nella fascia alta (più di 10.000 Euro).

Un’altra soluzione consiste nell’utilizzare una tabella di appoggio (fissa o temporanea) dove dichiarare le varie fasce, ed ottenere la classificazione con una JOIN.

Vedremo questa soluzione in un prossimo articolo.

Come far decidere direttamente allo script SQL se fare una INSERT o una UPDATE.

Quante volte vi sarà capitato di dover aggiornare una tabella con dei dati provenienti da una fonte esterna? Nella maggioranza dei casi, i dati da importare possono sia essere nuovi rispetto alla vostra tabella che essere degli aggiornamenti.
Scorrere con un cursore la tabella da importare e vedere record per record se è una novità o un aggiornamento è una scelta poco efficiente. Quale può essere allora una soluzione più performante?

Sfruttare la JOIN

La domanda necessaria da farsi è questa: in base a quale chiave riesco a capire se un record è una novità o un aggiornamento?

Una volta trovata la risposta, il meccanismo è semplice:

• si metteranno in JOIN le due tabelle (da importare ed esistente) relazionandole proprio con la chiave individuata
• la JOIN sarà una LEFT JOIN, con a sinistra la tabella da importare, e a destra quella già esistente
• come noto, la LEFT JOIN restituirà una serie di colonne NULL nella tabella di destra nel caso non ci siano corrispondenze: sfruttando questa caratteristica potremo quindi individuare quali sono i record già esistenti e quali invece sono nuovi
• ovviamente quelli nuovi saranno quelli con contenuto NULL, che sta a significare che i record della tabella di sinistra (da importare) NON sono già esistenti nella tabella di destra (esistente) e vanno quindi inseriti
• quelli invece non-NULL sono già esistenti, e quindi andranno aggiornati
• attenzione ad eseguire PRIMA la UPDATE e poi la INSERT; in caso contrario verranno aggiornati anche i record appena inseriti: i dati non vengono assolutamente danneggiati, ma sicuramente ci sarà una perdita di tempo

Esempio pratico

Un esempio aiuterà a comprendere più facilmente il meccanismo.

Immaginiamo di dover aggiornare una tabella di Dati Anagrafici con dei dati che ci vengono inviati periodicamente da un corrispondente; in questo caso, la chiave identificativa (univoca) sarà la Partita IVA.

Per comodità, avremo già importato i dati del nostro corrispondente in una tabella temporanea; i nomi delle colonne saranno gli stessi.

Impostiamo quindi la JOIN:

-- TS=TableSource, TT=TableTarget
SELECT
   TS.Descrizione, TS.PartitaIVA,
   TT.Descrizione, TT.PartitaIVA
FROM
   #tmpAnag TS LEFT JOIN ANAGRAFICHE TT ON TS.PartitaIVA=TT.PartitaIVA

Quando eseguiremo questa query, vederemo elencate delle corrispondenze esatte nel caso di record da aggiornare, mentre invece noteremo TT.Descrizione e TT.PartitaIVA a NULL nel caso di novità.

Sfrutteremo quindi la JOIN di riferimento per impostare prima una UPDATE…FROM…JOIN per fare gli aggiornamenti, poi una INSERT…SELECT…JOIN per fare gli inserimenti.

UPDATE

-- TS=TableSource, TT=TableTarget
UPDATE ANAGRAFICHE SET
      TT.Denominazione=TS.Denominazione,
      TT.Indirizzo=TS.Indirizzo,
      TT.CAP=TS.CAP,
      TT.Localita=TS.Localita,
      TT.PartitaIVA=TS.PartitaIVA
   FROM
      #tmpAnag TS LEFT JOIN ANAGRAFICHE TT ON TS.PartitaIVA=TT.PartitaIVA
      -- fa correttamente la JOIN? Quindi c'è GIA'! ---> UPDATE

INSERT

-- TS=TableSource, TT=TableTarget
INSERT INTO ANAGRAFICHE
     (Denominazione,
      Indirizzo,
      CAP,
      Localita,
      PartitaIVA)
   SELECT
      TS.Denominazione,
      TS.Indirizzo,
      TS.CAP,
      TS.Localita,
      TS.PartitaIVA
   FROM
      #tmpAnag TS LEFT JOIN ANAGRAFICHE TT ON TS.PartitaIVA=TT.PartitaIVA
   WHERE TT.PartitaIVA IS NULL
   -- non fa la JOIN? Quindi NON c'è! ---> INSERT

In questo articolo spiegherò come convertire in sicurezza una colonna float in una colonna varchar.

Mi è recentemente capitato di dover trasformare dei valori contenuti originariamente in una colonna float in un’altra colonna di tipo varchar. Il caso pratico si verifica facilmente, ad esempio con i numeri di telefono, partita iva, ecc.

La prima cosa che viene in mente è di effettuare una conversione diretta.

ALTER TABLE nome_tabella ALTER COLUMN VARCHAR(11)

Sembra tutto corretto, ma il risultato è inaccettabile; infatti la colonna trasformata conterrà i dati con notazione scientifica. Ad esempio il numero 12345678901 diventa 1.23457e+010

Questo perché il formato float contiene il numero in virgola mobile, e la sua rappresentazione alfanumerica è proprio con notazione scientifica.

Nei casi citati abbiamo però a che fare con numeri interi (senza decimali), per cui possiamo ottenere il risultato ottenuto tramite un passaggio intermedio.

ALTER TABLE nome_tabella ALTER COLUMN DECIMAL(11,0)

In questo modo abbiamo fissato il numero, togliendolo dalla scomoda (per il nostro fine) situazione di numero in virgola mobile.

A questo punto possiamo effettuare la nostra conversione:

ALTER TABLE nome_tabella ALTER COLUMN VARCHAR(11)

La colonna numerica diventerà alfanumerica mantenendo il numero esattamente come ce lo aspettiamo.

Nell’esempio ho usato una ALTER, ma lo stesso ragionamento vale anche per le conversioni effettuate con CONVERT e CAST, come nell’esempio che segue:

DECLARE @float AS FLOAT
SELECT @float=12345678901
PRINT CONVERT(VARCHAR, @float)
PRINT CONVERT(VARCHAR, CONVERT(DECIMAL(11,0), @float))

Il metodo funziona anche con NVARCHAR.

In questo articolo spiegherò come effettuare una query SELECT…WHERE usando una lista di valori.

E’ abbastanza comune dover effettuare delle query SQL usando una lista di valori anziché un valore singolo.

L’operatore OR

Questa operazione viene effettuata normalmente usando l’operatore OR.

Se ad esempio vogliamo selezionare i clienti che si trovano nelle provincie di Milano e Como, basterà scrivere una query così:

SELECT
   Denominazione, Indirizzo, Localita
FROM
   Clienti
WHERE
   Provincia='MI' OR Provincia='CO'

L’operazione però diventa lunga e tediosa se la lista contiene molti valori: pensate infatti a cosa diventerebbe la query riportata sopra per dieci o più provincie.

L’operatore IN

L’operatore IN dell’istruzione SELECT di SQL Server permette di semplificare notevolmente la scrittura della query.

Tornando al nostro esempio, per selezionare i clienti che si trovano nelle provincie di Milano e Como, basterà riscrivere la query così:

SELECT
   Denominazione, Indirizzo, Localita
FROM
   Clienti
WHERE
   Provincia IN ('MI','CO')

Il motore SQL elaborerà il contenuto della lista inserita tra parentesi e ri-trasformerà la query espandendo la IN in una serie di OR, per poi eseguirla normalmente.

Già da questo breve esempio è facile intuire quanto la stesura della query venga semplificata; e il livello di semplificazione aumenta all’aumentare degli elementi contenuti nella IN.

Ovviamente la stessa sintassi può essere usata anche per valori numerici.

SELECT
   Denominazione, Indirizzo, Localita
FROM
   Clienti
WHERE
   Tipo IN (2,7,12,14,35,36,37)

Uso con Stored Procedures

Nascerà sicuramente la necessità di usare questa sintassi con una Stored Procedure (SP), passando i valori con un parametro.

Immaginiamo allora una SP così:

Create Procedure usp_Cerca_Clienti (@pLista AS VARCHAR(MAX))
AS
BEGIN

   SELECT
      Denominazione, Indirizzo, Localita
   FROM
      Clienti
   WHERE
      Provincia IN (@pLista)

END

Qui iniziano subito le difficoltà, già all’atto del richiamo della SP. Avremo infatti delle difficoltà a passare il parametro; se proviamo così:

EXEC usp_Cerca_Clienti @pLista='MI,CO'

la SP svolta diventerà:

SELECT
   Denominazione, Indirizzo, Localita
FROM
   Clienti
WHERE
   Provincia IN ('MI,CO')

che ovviamente non ci darà alcun risultato (non esiste infatti la provincia ‘MI,CO’)

Se invece proviamo così:

EXEC usp_Cerca_Clienti @pLista=''MI','CO''

riceveremo un errore di sintassi.

Anche con valori numerici avremo un errore; infatti se proviamo così:

EXEC usp_Cerca_Clienti_per_Tipo @pLista='1,4'

la SP svolta diventerà:

SELECT
   Denominazione, Indirizzo, Localita
FROM
   Clienti
WHERE
   Tipo IN ('1,4')

restituendoci un errore perché Tipo è una colonna numerica che non può essere raffrontata con un valore stringa.

Emulare un array

Certo, se SQL supportasse gli array, tutto sarebbe più semplice: basterebbe passare un array con i valori da usare nella IN e il gioco sarebbe fatto.

Per emulare il funzionamento di un array possiamo usare una variabile di tipo table: se la prepariamo con una sola colonna avremo emulato un array (monodimensionale).
Però non possiamo usare una variabile table con l’operatore IN: dobbiamo per forza modificare la nostra SP usando una JOIN.

Il ragionamento diventa quindi il seguente:

• prepariamo una lista di valori da passare alla SP
• i valori saranno separati da un carattere predefinito (in questo esempio useremo una virgola)
• passiamo la lista di valori separati da virgola alla SP, in un’unica variabile
• la SP elabora la variabile stringa e la trasforma in una variabile table, inserendo ogni valore in una riga
• infine mette in JOIN la tabella da selezionare con la variabile table ottenuta prima ed esegue la query

Trasformazione della lista in una table

La prima cosa che dovremo fare sarà quindi di trasformare la nostra lista in una variable table. Per fare questo prepareremo una funzione, così da poterla riusare tutte le volte che vogliamo.

USE [master]
GO

SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER ON
GO

--The following is a general purpose UDF to split comma separated lists into individual items.
--Consider an additional input parameter for the delimiter, so that you can use any delimiter you like.

-- edc 01.SEP.05
-- adattamento da http://vyaskn.tripod.com/passing_arrays_to_stored_procedures.htm
-- 

-- edc 20.sep.06
-- adattato per le stringhe

CREATE FUNCTION [dbo].[udf_CodeSplitter]
(
	@CodeList varchar(MAX)
)
RETURNS
@ParsedList table
(
	OneCode varchar(10) -- adjust the single element length to fit your needs
)
AS
BEGIN
	DECLARE @Pos int, @OneCode varchar(10) -- adjust the single element length to fit your needs

	SET @CodeList = LTRIM(RTRIM(@CodeList))+ ','
	SET @Pos = CHARINDEX(',', @CodeList, 1)

	IF REPLACE(@CodeList, ',', '') <> ''
	BEGIN
		WHILE @Pos > 0
		BEGIN
			SET @OneCode = LTRIM(RTRIM(LEFT(@CodeList, @Pos - 1)))
			IF @OneCode <> ''
			BEGIN
				INSERT INTO @ParsedList (OneCode) VALUES (@OneCode)
			END
			SET @CodeList = RIGHT(@CodeList, LEN(@CodeList) - @Pos)
			SET @Pos = CHARINDEX(',', @CodeList, 1)

		END
	END
	RETURN
END

La funzione non fa altro che selezionare i vari elementi ed inserirli in una variabile table; la tabella restituita è formata da una sola colonna (OneCode), e potrà essere messa facilmente in JOIN con la tabella da ricercare.

Per testare il corretto funzionamento della funzione, e per avere un’idea del risultato, basterà eseguire questa query:

SELECT * FROM master.dbo.udf_CodeSplitter('MI,CO')

La Stored Procedure finale

Andremo quindi a sistemare la nostra SP così:

Create Procedure usp_Cerca_Clienti (@pLista AS VARCHAR(MAX))
AS
BEGIN

   SELECT
      Denominazione, Indirizzo, Localita
   FROM
      Clienti INNER JOIN master.dbo.udf_CodeSplitter(@pLista) TJ
      ON Clienti.Provincia=TJ.OneCode

END

mettiamo cioè in JOIN la tabella Clienti con la tabella riportata dalla funzione udf_CodeSplitter, usando come campo di corrispondenza il campo della tabella Cliente dove vogliamo operare la selezione (Clienti.Provincia) e l’unico campo riportato dalla funzione (TJ.OneCode, dove TJ è l’alias della tabella restituita dalla funzione).

L’uso diventa quindi semplicissimo:

exec usp_Cerca_Clienti @pLista='MI,CO'

Gestione delle liste numeriche

Il ragionamento da fare per poter utilizzare delle liste numeriche resta fondamentalmente lo stesso, ma bisogna operare qualche piccola variazione per poter gestire numeri, appunto, anziché stringhe.

Prepareremo quindi una nuova ulteriore funzione:

USE [master]
GO
/****** Object:  UserDefinedFunction [dbo].[IDSplitter]    Script Date: 02/12/2010 12:26:50 ******/
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER ON
GO

--The following is a general purpose UDF to split comma separated lists into individual items.
--Consider an additional input parameter for the delimiter, so that you can use any delimiter you like.

-- edc 01.SEP.05
-- adattamento da http://vyaskn.tripod.com/passing_arrays_to_stored_procedures.htm
-- 

ALTER FUNCTION [dbo].[udf_IDSplitter]
(
	@IDList varchar(MAX)
)
RETURNS
@ParsedList table
(
	OneID int
)
AS
BEGIN
	DECLARE @OneID varchar(10), @Pos int

	SET @IDList = LTRIM(RTRIM(@IDList))+ ','
	SET @Pos = CHARINDEX(',', @IDList, 1)

	IF REPLACE(@IDList, ',', '') <> ''
	BEGIN
		WHILE @Pos > 0
		BEGIN
			SET @OneID = LTRIM(RTRIM(LEFT(@IDList, @Pos - 1)))
			IF @OneID <> ''
			BEGIN
				INSERT INTO @ParsedList (OneID)
				VALUES (CAST(@OneID AS int)) --Use Appropriate conversion
			END
			SET @IDList = RIGHT(@IDList, LEN(@IDList) - @Pos)
			SET @Pos = CHARINDEX(',', @IDList, 1)

		END
	END
	RETURN
END

In questo caso la tabella restituita è formata da una colonna (OneID) di tipo numerico (int).

Per testare il corretto funzionamento della funzione, e per avere un’idea del risultato, basterà eseguire questa query:

SELECT * FROM master.dbo.udf_IdSplitter('1,2,4,6,15,22')

Ricordatevi che la lista è un valore stringa, quindi va passata tra apici singoli.

La Stored Procedure finale per i valori numerici

Andremo quindi a sistemare la nostra SP così:

Create Procedure usp_Cerca_Clienti_Tipo (@pLista AS VARCHAR(MAX))
AS
BEGIN

   SELECT
      Denominazione, Indirizzo, Localita
   FROM
      Clienti INNER JOIN master.dbo.udf_IdSplitter(@pLista) TJ
      ON Clienti.Tipo=TJ.OneId

END

In questo caso mettiamo in JOIN la tabella Clienti con la tabella riportata dalla funzione udf_IdSplitter, usando come campo di corrispondenza il campo della tabella Cliente dove vogliamo operare la selezione (Clienti.Tipo, che è di tipo int) e l’unico campo riportato dalla funzione (TJ.OneId, dove TJ è l’alias della tabella restituita dalla funzione).

L’uso diventa quindi semplicissimo:

exec usp_Cerca_Clienti_Tipo @pLista='2,7,12,14,35,36,37'

Considerazioni finali

Il metodo esposto semplifica notevolmente la stesura delle query di selezione basate su liste di valori. Dato che però sfrutta una funzione e una variabile table, potrebbe risultare poco performante in presenza di liste molto corpose. In questi casi potrebbe risultare più comodo popolare direttamente una tabella temporanea e metterla in JOIN con la tabella da selezionare (magari indicizzando la tabella temporanea, cosa che non può essere fatta con le variabili table).
Uso il condizionale perché le performance sono influenzate da molti fattori, per cui è consigliabile effettuare delle prove caso per caso.

Il database di sistema ‘msdb’ di SQL Server 2005 può danneggiarsi: ecco come ripararlo.

Tra i database di sistema di Microsoft SQL Server 2005, ve ne è uno denominato ‘msdb’ che viene usato normalmente come supporto per le pianificazioni ed altre operazioni di manutenzione o di backup.
Può accadere che si danneggi, e che di conseguenza molte operazioni diventino impossibili.
Dato che non si tratta di un normale database, non può essere oggetto di normali operazioni quali attach e detach, ma bisogna seguire una procedura diversa.

Importante! La procedura che descriverò di seguito rigenererà il database di sistema ‘msdb’ come appena installato, quindi tutto il suo contenuto andrà perso. Vi raccomando inoltre di effettuare il backup di tutti i dati di tutti i database dell’istanza. La procedura è riservata ad utenti esperti, e non mi assumo nessuna responsabilità; eventualmente provatelo prima su un database di test.

1. Spegnere SQL Server

Innanzitutto dovrete spegnere il servizio di SQL Server. Esistono diversi metodi; uno dei più veloci è di aprire SQL Server Management Console ed eseguire il seguente comando:

SHUTDOWN

Attendete il completamento del comando ed uscite dalla console.

2. Lanciare SQL Server in modalità master

Per poter eseguire i comandi successivi (specificatamente per poter fare un detach del database ‘msdb’), dovrete lanciare SQL Server col trace flag 3608.
Dovrete portarvi nella cartella dei programmi di SQL Server (‘C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\Binn’ per le installazioni in italiano o ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn’ per le installazioni in inglese) e lanciare il seguente comando:

sqlservr.exe -c -T3608 -s <NOMEISTANZA>

Il comando non restituisce subito il prompt di DOS (C:>), che verrà restuituito quando SQL Server verrà nuovamente spento.

3. Detach-are il database di sistema ‘msdb’

Per detach-are il database di sistema ‘msdb’ dovrete riaprire SQL Server Management Console, che potrebbe mostrare alcuni messaggi di avvertimento, visto che ci si trova in una modalità master.
La console comunque è pronta per accettare comandi; lanciate il seguente:

sp_detach_db 'msdb'

Attendete il completamento del comando ed uscite dalla console.

4. Rinominare i files del database ‘msdb’

Ora che il database ‘msdb’ è disconnesso, potete rinominare i files che lo costituiscono (.mdf e .ldf), che si trovano in ‘C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\Data’ per le installazioni in italiano o in ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data’ per le installazioni in inglese.

5. Lanciare lo script di ricostruzione

Lo script di rigenerazione si trova nella cartella di installazione di SQL Server (‘C:\Programmi\Microsoft SQL Server\MSSQL.1\MSSQL\Install’ per le installazioni in italiano o ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Install’ per le installazioni in inglese); dopo che vi sarete portati nella cartella, lanciate il seguente comando:

osql -E -S <NOMESERVER>\<NOMEISTANZA> -i instmsdb.sql

e attendete il termine delle operazioni.

6. Operazioni finali

La procedura è terminata. Spegnete e riaccendete normalmente SQL Server, e reinserite, se del caso, le informazioni memorizzate nel database di sistema ‘msdb’.

Avete una Stored Procedure SQL e volete usarne l’output in un’altra query (senza modificare la SP originale). Ecco come fare.

Vi sarà capitato di voler usare l’output di una Stored Procedure in un’altra query; la prima cosa che viene in mente è di modificare o duplicare la SP originale e inserire dei parametri OUTPUT, per poi sfruttarli.

Ma non sempre si può; a volte, infatti, soprattutto in ambienti complessi, certe SP non si possono toccare, perché sono usate da altre procedure o gestite da altri programmatori.

Cosa fare allora?

Supponiamo di avere una SP che mi elenca tutti i clienti di una determinata provincia

set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE usp_ClientiProvincia (@p_Provincia VARCHAR(2))

SET NOCOUNT ON

   SELECT CODICE, DESCRIZIONE
   FROM CLIENTI
   WHERE PROVINCIA = @p_PROVINCIA
   ORDER BY 1

una SP davvero semplice.

Se la facciamo girare, otteniamo due campi, CODICE e DESCRIZIONE.

Nella nostra nuova query dichiariamo innanzitutto una variabile TABLE che possa contenere il risultato della SP

DECLARE @ClientiTable TABLE (CODICE VARCHAR(20), DESCRIZIONE VARCHAR(100))

Ovviamente la struttura della variabile varierà in base al variare dell’output della SP che volete catturare.
Per memorizzare l’output della SP usiamo una comune INSERT INTO nella forma breve (INSERT INTO SELECT …), specificando anche i parameti per la SP da cattuare.

INSERT INTO @ClientiTable EXEC usp_ClientiProvincia @p_PROVINCIA='MI'

A questo punto ci ritroviamo nella variabile @ClientiTable l’output della SP, pronta per essere utilizzata per i nostri scopi; ad esempio:

SELECT * FROM @ClientiTable WHERE DESCRIZIONE LIKE @p_cerca

Questa la query complessiva

DECLARE @ClientiTable TABLE (CODICE VARCHAR(20), DESCRIZIONE VARCHAR(100))
INSERT INTO @ClientiTable EXEC usp_ClientiProvincia @p_PROVINCIA='MI'
SELECT * FROM @ClientiTable WHERE DESCRIZIONE LIKE @p_cerca

SQL Server offre la possibilità di controllare se un file esiste. Vediamo come.

Tramite una procedura interna di SQL è possibile controllare l’esistenza di un file. La procedura è xp_fileexist e va usata così

EXEC master..xp_fileexist 'C:\immagine.jpg'

viene riportato 1 se il file esiste, oppure 0 se non esiste.

In un caso pratico ho dovuto controllare l’esistenza di un certo numero di files, il cui nome era memorizzato in una tabella. Per fare questo, ho innanzitutto creato una funzione (udf) che effettuasse il controllo e ritornasse il flag di trovato/non trovato

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		<EDC>
-- Create date: <05.sep.2009>
-- Description:	<Check file exist>
-- =============================================
ALTER FUNCTION udf_FileExist
(
	@in_FileName VARCHAR(512)
)
RETURNS INT
AS
BEGIN

	DECLARE @out_result INT

	EXEC master..xp_fileexist @in_FileName, @out_result OUT

	RETURN ISNULL(@out_result,0)

END
GO

La funzione udf_FileExist accetta in input il nome del file (percorso completo) e restituisce un intero che varrà 1 se il file esiste, oppure 0 se non esiste.

Per usarla, sarà sufficiente richiamare la funzione nella query, così:

SELECT NomeFile, dbo.udf_FileExist(NomeFile) AS Esiste FROM Tabella_Files

Come aggregare risultati diversi in un’unica riga (record) di risultati

Un amico ha sollevato questo problema: come conoscere con un’unica query quante foto ha inserito un dato utente nella tabella foto e quanti blog ha inserito lo stesso utente nella tabella blogs.

Dato che il database in uso era Access, non si potevano usare Stored Procedures, quindi il tutto andava fatto con un’unica query.

Procediamo quindi per passi successivi.

1. Per prima cosa vediamo come leggere quante foto sono state inserite (il nostro utente immaginario si chiamerà…. “Pippo”, come sempre)

SELECT COUNT(*) FROM gallerieFoto WHERE fAutore="Pippo"

il risultato della query sarà (ad esempio):
5

2. Adesso procediamo con la lettura di quanti messaggi sono stati inseriti nel blog

SELECT COUNT(*) FROM blogs WHERE bAutore="Pippo"

il risultato della query sarà (ad esempio):
3

3. Ora uniamo le due query con una UNION, visto che il formato di uscita è identico

SELECT COUNT(*) FROM gallerieFoto WHERE fAutore="Pippo"
UNION
SELECT COUNT(*) FROM blogs WHERE bAutore="Pippo"

il risultato della query sarà:
5
3

4. così facendo avremmo due record, ma non si vuole fare un ciclo di lettura; quindi bisogna fare in modo che la query restituisca 2 colonne, non due righe

5. iniziamo con l’attribuire i due nomi di colonna per i risultati: qFoto e qBlog

SELECT COUNT(*) AS qFoto FROM gallerieFoto WHERE fAutore="Pippo"
UNION
SELECT COUNT(*) AS qBlog FROM blogs WHERE bAutore="Pippo"

il risultato della query sarà:
5
3

6. però è ancora una colonna sola; quindi aggiungiamo una colonna per query che faccia da segnaposto: nella query delle foto aggiungiamo il segnaposto dei blog, nella query dei blog aggiungiamo il segnaposto delle foto

SELECT COUNT(*) AS qFoto, 0 AS qBlog FROM gallerieFoto WHERE fAutore="Pippo"
UNION
SELECT 0 as qFoto, COUNT(*) AS qBlog FROM blogs WHERE bAutore="Pippo"

da notare l’inserimento incrociato dei segnaposto, per ottenere la corrispondenza delle colonne

il risultato della query sarà:
5 0
0 3

7. sistemata la questione delle due colonne, resta il problema delle due righe; aggiungiamo una query esterna che raccolga i MAX delle query (infatti interessano i risultati 5 e 3, gli zeri vanno ignorati); potremmo usare anche SUM, io per abitudine preferisco MAX.

SELECT MAX(qFoto) AS qFoto, MAX(qBlog) as qBlog FROM (
SELECT COUNT(*) AS qFoto, 0 AS qBlog FROM gallerieFoto WHERE fAutore="Pippo"
UNION
SELECT 0 as qFoto, COUNT(*) AS qBlog FROM blogs WHERE bAutore="Pippo"
) AS subQry

il risultato della query sarà:
5 3

che è esattamente quello che si voleva ottenere.

In questo articolo spiegherò come selezionare (e poi eventualmente eliminare) i record duplicati di una tabella, usando SQL 2005.

Può capitare che in una tabella ci siano dei record (righe) duplicati. Rintracciarli per poi eliminarli è sempre una faccenda noisa.

Per fare questo possiamo avvalerci della funzione di numerazione righe ROW_NUMBER() di MS SQL Server 2005.

Ad esempio, questa query:

SELECT  ROW_NUMBER() OVER(PARTITION BY PART_IVA ORDER BY CODICE) AS [RowNumber]
      , PART_IVA
      , CODICE
FROM  CLIENTI

elencherà tutti i Clienti, numerandoli progressivamente quando hanno la stessa Partita IVA ( … PARTITION BY PART_IVA … ).

Per evidenziare i duplicati, basterà aggiungere una WHERE, così

SELECT * FROM (
   SELECT  ROW_NUMBER() OVER(PARTITION BY PART_IVA ORDER BY CODICE) AS [RowNumber]
         , PART_IVA
         , CODICE
   FROM  CLIENTI
   ) AS T1
WHERE RowNumber>1

Similarmente, potremo usare lo stesso stratagemma per eliminare tutti i doppioni

 DELETE T1 FROM (
   SELECT  ROW_NUMBER() OVER(PARTITION BY PART_IVA ORDER BY CODICE) AS [RowNumber]
         , PART_IVA
         , CODICE
   FROM  CLIENTI
   ) AS T1
  WHERE T1.RowNumber >1

In questo articolo illustrerò alcuni modi di usare la funzione COUNT().

La funzione COUNT() viene usata per contare (appunto) quanti record ci sono in una tabella o vista, eventualmente rispondenti ad una determinata condizione.

Ad esempio potremmo voler contare quanti clienti hanno sede a Milano.

SELECT
    COUNT(*) AS qClienti
FROM
    Clienti
WHERE
   Localita='MILANO'

Potrebbe succedere però di dover riportare più conteggi; ad esempio quanti clienti hanno sede a Milano e quanti in Lombardia.

La prima soluzione che viene in mente è di eseguire due interrogazioni, con due WHERE diverse; si potrebbero anche riunire le due interrogazioni con una UNION, in questo modo:

SELECT SUM(cMilano) AS qMilano, SUM(cLombardia) AS qLombardia FROM
   (SELECT COUNT(*) AS cMilano, 0 as cLombardia FROM Clienti WHERE Localita='MILANO'
    UNION
    SELECT 0 AS cMilano, COUNT(*) AS cLombardia FROM Clienti WHERE Regione='LOMBARDIA')

Non il massimo dell’eleganza, né dell’efficienza.

Nella funzione COUNT possiamo però usare l’istruzione CASE, che ci permetterà di scrivere una interrogazione migliore.

Sfrutteremo la regola per cui i NULL non vengono contati nella COUNT; in particolare, nel nostro caso, se il risultato della WHEN è positivo (cioè corrisponde) viene restituito un risultato non-NULL, e conseguentemente contato; altrimenti (un altrimenti implicito) viene riportato NULL, che non viene contato.

SELECT
   (COUNT(CASE WHEN Localita='MILANO' THEN 1 END)) qMilano,
   (COUNT(CASE WHEN Regione='LOMBARDIA' THEN 1 END)) qLombardia
FROM
   CLIENTI

La query è più pulita, più performante e più manutenibile. Non lasciatevi fuorviare dalla cifra ‘1′ restituita dal CASE; un qualunque valore non-NULL va altrettanto bene (es.: COUNT(CASE WHEN Localita=’MILANO’ THEN ‘Ok!’ END)  )

Tutte le funzioni di aggregazione (COUNT, SUM, AVG, ecc.) possono essere usate in questo modo.

Come aggiungere opzioni di riordinamento dinamico ad una griglia asp.net (GridView) alimentata da una sorgente dati LINQ SQL

Articolo in fase di completamento

Abbiamo una griglia asp.net (una GridView) che espone i dati di una tabella SQL; la griglia è alimentata da una sorgente dati LINQ 2 SQL che si interfaccia (ovviamente?) ad un database MS SQL 2005.

Il codice sorgente (HTML) della griglia sarà quindi questo:

<asp:GridView ID="grdData" runat="server"
   AutoGenerateColumns="false"
   EmptyDataText="Nessun dato presente">
   <Columns>
      <asp:BoundField DataField="ID_AREA" HeaderText="ID_Area" />
      <asp:BoundField DataField="Codice" HeaderText="Codice" />
      <asp:BoundField DataField="Livello" HeaderText="Livello" />
      <asp:BoundField DataField="Titolo" HeaderText="Titolo" />
   </Columns>
</asp:GridView>

Questa è la funzione generica di caricamento dei dati.

Public Function GetAllCategorie() As IList(Of Categoria)
Dim dc = Factory.GetReadyDataContext()
Return (From c In dc.GetTable(Of Categoria)() Where c.STATUS = 10).ToList
End Function

La griglia così ottenuta mostrerà semplicemente i dati, senza alcuna opzione di riordinamento.

continua …

In questo articolo spiegherò come far numerare i record selezionati direttamente a SQL 2005.

Una delle funzioni più richieste, e allo stesso tempo più noiose da realizzare, è la numerazione dei record selezionati con uno statement SQL. La versione 2005 di MS SQL Server include una serie di nuove funzioni che ci possono aiutare in questo senso.

La funzione che andremo ad utilizzare per la numerazione sarà ROW_NUMBER().

ROW_NUMBER (letteralmente, numero di riga) si usa in questo modo:

SELECT
    ROW_NUMBER() OVER(ORDER BY Importo DESC) AS [RowNumber],
    CodCliente, NumeroOrdine, DataOrdine, ImportoOrdine
FROM
    Ordini

L’istruzione SELECT metterà il risultato in ordine discendente di importo (in base alla richiesta OVER(ORDER BY Importo DESC), e numererà le righe così ottenute.

Il resto della SELECT è una selezione classica.

Questo è l’utilizzo più semplice di ROW_NUMBER(), ma è già abbastanza per farcelo apprezzare.

Vedremo in seguito come usare ROW_NUMBER() per

• numerazione a gruppi
• estrazione di sub-set di record (simulazione della LIMIT di MySql)
• estrazioni dei primi n record per gruppi