Xplayn.org

"DevCon'07" a Milano il 15/16/17 Maggio

Francesco Quaratino — Tue, 06 Feb 2007 00:00:00 GMT

Anche quest'anno, abbiamo il piacere di annunciare l'apertura dei lavori della "DevCon'07", la conferenza - a nostra avviso - pi� importante che si tenga in Italia in materia di sviluppo software made in Microsoft.

La fitta agenda e la professionalit� degli speaker sono garanzia di un evento di altissimo livello:

Gran parte della conferenza verter� su .NET, mentre .NET 2.0 occuper� alcuni slot in cui si andr� nel massimo dettaglio possibile sviscerando le sue peculiarit�. .NET 3.5, LINQ e altre novit� troveranno lo spazio necessario senza toglierne agli argomenti principale. Verr� trattato anche SQL 2005 per l�analisi efficiente dei dati (senza parlare di OLAP), e alcune sessioni sul mondo Mobile completano lo scenario della conferenza.

Per maggiori dettagli rimandiamo caldamente al sito ufficiale della conferenza:
http://devcon2007.devleap.com/

"Microsoft .NET Present & Future" a Bari

Francesco Quaratino — Tue, 05 Sep 2006 04:00:00 GMT

Si terr� il 26 ottobre prossimo a Bari presso lo Sheraton Hotel, il terzo workshop organizzato da DotNetSide, lo user group del sud Italia dedicato alle neo-tecnologie di sviluppo Microsoft. Il workshop sar� ricco di sessioni di sicuro interesse sull'argomento "Microsoft .NET Present & Future". Tra gli speaker, alcuni tra i pi� affermati speaker italiani specialisti in ambito .NET come Francesco Balena, Giuseppe Di Mauro e Lorenzo Barbieri, e molti altri ancora.

L'agenda completa � consultabile sul sito dotNetSide al questo indirizzo:
http://www.dotnetside.org/content/netpresentandfuture.aspx

La partecipazione � gratuita e per iscriversi basta accedere al sito Microsoft a questo indirizzo:
http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=it-IT&EventID=1032305037&EventCategory=1

Large Object (LOB) in Sql Server 2000

Francesco Quaratino — Fri, 09 Jun 2006 03:57:00 GMT

   Sql Server 2000 prevede i cosiddetti Large Object (LOB) - detti anche Binary Large Object (BLOB) -, tre tipi di dati per registrare grandi quantit� di dati (come ad esempio immagini e file):
    - TEXT: fino a 2 ^ 31 - 1 ( = 2.147.483.647 ) caratteri non-Unicode;
    - NTEXT: fino a 2 ^ 30 - 1 ( = 1.073.741.823 ) caratteri Unicode;
    - IMAGE: fino a 2 ^ 31 ( = 2.147.483.647 ) bytes di caratteri binari.

Per motivi strutturali, i dati di una singola riga di tabella non possono eccedere gli 8060 bytes. A questo proposito, ricordo che Sql Server 2000 registra i suoi dati in strutture denominate Data Pages (pagine dati) che hanno dimensione pari a 8 Kb, di cui 8060 bytes dedicati ai dati veri e propri, e che i dati di una riga non possono essere ripartiti su pi� pagine dati. Perci�, per i dati di tipo LOB, viene adottato un sistema particolare che prevede la registrazione del dato in altre pagine dati (sempre di 8Kb). Ognuna di queste particolari pagine di dati, accoglie i dati di tipo LOB di una singola tabella, ed � velocemente attraversabile attraverso una struttura ad albero B-Tree.

Quindi, nella pagina dati che accoglie la riga, sar� registrato un puntatore al nodo principale di questa struttura B-Tree. Ci� accadr� in ogni caso, anche se la dimensione della riga (compreso il dato LOB) fosse inferiore a 8060 bytes. In tal caso, per rendere pi� veloce il reperimento del dato LOB, possiamo intervenire mediante l'impostazione dell'opzione di tabella 'text in row'.

Ecco un esempio:

/* Transact-SQL */
sp_tableoption 'nome_tabella', 'text in row', 'ON'
sp_tableoption 'nome_tabella', 'text in row', '1000'
SELECT OBJECTPROPERTY(OBJECT_ID('Employee'), 'TableTextInRowLimit')SELECT OBJECTPROPERTY(OBJECT_ID('Customer'), 'TableTextInRowLimit')

Nel primo caso, con l'opzione ON si imposta un numero di bytes disponibili nella pagina dati pari al default di 256 bytes. Nel secondo caso, si esplicita il valore di 1000 bytes - il range a disposizione � 24 - 7000 bytes. Se i dati LOB eccedono i bytes disponibili, la pagina dati accoglier� il nodo principale della struttura di pagine riservate ai dati LOB della specifica tabella.

Affinch� l'impostazione 'text in row' abbia effetto sui dati LOB gi� presenti, gli stessi dati devono essere aggiornati. Se si vuole disabilitare l'opzione, si usa la stessa stored procedure di sistema specificando OFF oppure 0:

/* Transact-SQL */
sp_tableoption 'nome_tabella', 'text in row', 'OFF'
sp_tableoption 'nome_tabella', 'text in row', '0'

Utilizzo "sicuro" di stringhe in .NET 2.0

Maurizio Tammacco — Thu, 01 Jun 2006 00:00:00 GMT

La classe System.String non rappresenta la soluzione pi� sicura quando � necessario memorizzare sotto forma di stringa contenuti confidenziali, ad esempio stringhe di connessione a database, password varie, numeri di carta di credito, ecc.. Informazioni di questo genere andrebbero mantenute in memoria solo il tempo strettamente necessario alla loro elaborazione, e la memoria occupata andrebbe rilasciata il pi� presto possibile. Questo accorgimento � necessario poich� il contenuto della memoria utilizzata da un processo in esecuzione potrebbe essere letta attraverso varie tecniche di hacking, e quindi il suo eventuale contenuto confidenziale correrebbe seri pericoli di manomissione. Inoltre, un processo in esecuzione potrebbe utilizzare un file di swap su disco che provocherebbe la scrittura anche di questo genere di informazioni.

[Perch� una stringa � insicura]
La classe System.String non si adatta affatto a queste caratteristiche. Infatti, una stringa � un oggetto immutabile, per cui ogni modifica ad essa comporta la creazione di una nuova stringa memorizzata in un�area di memoria differente, mentre la vecchia stringa continuer� ad esistere fino alla successiva operazione di garbage collection, che, a causa della sua natura non deterministica, potrebbe avvenire ben pi� tardi rispetto al momento in cui tutti i riferimenti ad essa sono rilasciati.
L�immutabilit� delle stringhe costituisce un serio problema se una stringa contiene informazioni confidenziali per almeno 3 motivi:

� Ogni manipolazione effettuata su di essa lascia in memoria una copia della stessa, in attesa del garbage collector;
� Non esiste alcun modo per �resettare� il contenuto della stringa una volta utilizzato; il tentativo di assegnare un valore nullo provocher� la creazione di un nuovo oggetto stringa con il nuovo contenuto lasciando invariato il vecchio;
� L�indirizzo di memoria in cui � memorizzata una stringa non � costante una volta creata;
� Non � possibile criptare il contenuto di una stringa senza provocare la creazione di un nuovo oggetto con il contenuto criptato;

[La soluzione in .NET 1.0/1.1]
Nella versione 1.0/1.1 del Microsoft .NET Framework non esiste una soluzione semplice a questo problema. Infatti l�unica strada percorribile � quella di criptare/decriptare manualmente il contenuto di una stringa confidenziale utilizzando un array di caratteri come area di lavoro. Non � invece possibile resettare una stringa senza attendere che il garbage collector agisca.

[La soluzione in .NET 2.0]
La versione 2.0 del .NET Framework pone rimedio a tutti i problemi di sicurezza precedentemente elencati attraverso la nuova classe SecureString presente nel namespace System.Security. Questa nuova classe permette di memorizzare in modo sicuro e criptato una stringa contenente contenuto confidenziale, utilizzando DPAPI (Data Protection API), ovvero una serie di API per il criptaggio ed il decriptaggio di informazioni mediante l�algoritmo Triple-DES.

Ecco un esempio di utilizzo:

Come si pu� notare, l�utilizzo di SecureString � un po� pi� macchinoso rispetto alla creazione di un semplice oggetto stringa; infatti esso richiede che la stringa sicura sia costruita aggiungendo un carattere alla volta attraverso il metodo AppendChar(). Il motivo di questo utilizzo dovrebbe essere ovvio: non � possibile costruire una stringa sicura a partire da una stringa gi� in memoria in testo in chiaro, poich� quest�ultima sarebbe immutabile con gli identici problemi di sicurezza visti precedentemente. Inoltre, una istanza di SecureString � mutabile, il suo indirizzo di memoria non cambia una volta creata e pu� quindi facilmente essere azzerata attraverso il metodo Clear() senza attendere il garbage collector. Oltre al metodo AppendChar() esistono altri metodi per modificare il contenuto, ad es. InsertAt(), RemoveAt(), SetAt(), il cui nome � abbastanza intuitivo per comprendere il loro utilizzo. La propriet� MakeReadOnly blocca il contenuto dell�oggetto SecureString non permettendo pi� alcuna modifica. Questa caratteristica pu� essere letta attraverso la propriet� IsReadOnly. Inoltre, la classe SecureString implementa l�interfaccia IDisposable, ovvero permette al suo utilizzatore di distruggere l�istanza in memoria senza attendere il garbage collector.

Dopo aver creato e popolato una istanza della classe SecureString occorre leggere il valore in essa contenuto. Questa operazione non pu� essere fatta richiamando semplicemente il metodo ToString() della classe, in quanto quest�ultimo non � stato ridefinito e ritorna semplicemente l�oggetto sotto forma di stringa cos� come ereditato da System.Object, vale a dire �System.Security.SecureString�, non di grande utilit�, e non � semplicissima in quanto comporta una operazione di marshalling (attraverso l�utilizzo della classe Marshal presente nel namespace System.Runtime.InteropServices) che coinvolge l�utilizzo di un puntatore alla stringa, anche se il tutto si risolve con poche righe di codice, come in questo esempio:

Una volta ottenuta la controparte immutabile della stringa, � necessario assicurarsi che l�area di memoria puntata dal puntatore sia azzerata attraverso l�utilizzo del metodo ZeroFreeBSTR della classe Marshal.

[Riferimenti]
[1] Maurizio Tammacco - Pinned object in .NET
[1] Maurizio Tammacco - Uso efficiente delle stringhe in .NET

Come usare la OUTPUT keyword di Sql Server 2005

Francesco Quaratino — Sat, 20 May 2006 00:00:00 GMT

Sql Server 2005 introduce molte interessanti novit� e migliorie nel linguaggio Transact-SQL. Tra queste la parola chiave OUTPUT o OUTPUT...INTO, la quale permette di restituire i valori di database aggiornati a seguito di operazioni di INSERT, UPDATE e DELETE. Questa funzionalit� pu� essere d'aiuto al DBA (o se preferite DBD - DataBase Developer) in diversi situazioni, per esempio, il recupero del valore dei campi di tipo identity e di quelli calcolati. Vediamo degli esempi che adoperano una tabella [Books] che presenta un campo identity [BookID] e un campo calcolato [ProjectedSales].

/* Transact-SQL 2005 */
CREATE SCHEMA OutputSample AUTHORIZATION dbo
CREATE TABLE Books (
BookID int IDENTITY,
Title nvarchar(50) NOT NULL,
Published datetime NOT NULL,
CurrentSales money NOT NULL,
ProjectedSales AS CurrentSales * 0.01 * DATEDIFF (day, Published, GetDate()), ModifiedBy sysname DEFAULT suser_name() NOT NULL
)
GO

Inseriremo un record utilizzando la parola chiave OUTPUT allo scopo di restituire al client il valore del campo identity [BookID], del campo calcolato [ProjectedSales] e di quello valorizzato dal default [ModifiedBy]. Per fare ci�, OUTPUT sfrutta le tabelle virtuali Inserted e Deleted, le stesse esposte nei Trigger: la tabella virtuale Inserted contiene i valori delle righe inserite mediante UPDATE o i nuovi valori delle righe aggiornate mediante UPDATE, mentre la Deleted contiene i valori delle righe cancellate mediante DELETE o i vecchi valori delle righe aggiornate mediante UPDATE.

/* Transact-SQL 2005 */
INSERT INTO OutputSample.Books (Title, Published, CurrentSales)
OUTPUT inserted.BookID, inserted.ProjectedSales, inserted.ModifiedBy
VALUES ('Inside Sql Server 2005', '01-04-2006', 100)
GO

Otterremo il risultato seguente:

BookID ProjectedSales ModifiedBy
----------- --------------------------------------- ---------------
1 49.000000 XPLAYN\FRANCESCO

(Righe interessate: 1)

Per la verit�, gi� in Sql Server 2000 si disponeva di tre diversi metodi che garantivano un efficace recupero dell'ultimo valore Identity generato all'interno della sessione utente (mediante @@IDENTITY), all'interno dello scope corrente - stored procedure, user function, batch - (mediante SCOPE_IDENTITY()) e, infine, in una qualsiasi tabella del database indipendentemente da sessione e scope (mediante IDENT_CURRENT). In pi� rispetto a tali metodi, la OUTUPT keyword ci permette di ricavare tutti i valori identity generati in un'inserimento di massa. Ad esempio, supponiamo di voler popolare la tabella [Books] a partire da un'altra tabella chiamata [SourceBooks] che andiamo di seguito a creare e popolare:

/* Transact-SQL 2005 */
CREATE TABLE OutputSample.SourceBooks ( Title nvarchar(50) NOT NULL, Published datetime NOT NULL, CurrentSales money NOT NULL )
GO
INSERT INTO OutputSample.SourceBooks
VALUES ('Transact-SQL in Sql Server 2005', '10-02-2006', 500)
INSERT INTO OutputSample.SourceBooks
VALUES ('Algoritmi e Strutture Dati', '20-01-2005', 1200)
INSERT INTO OutputSample.SourceBooks
VALUES ('Basi di dati 2a Ed.', '01-01-2006', 1500)
GO

Quando popoliamo [Books] a partire da [SourceBooks] mediante la classica istruzione "INSERT INTO ... SELECT" utilizzando OUTPUT:

/* Transact-SQL 2005 */
INSERT INTO OutputSample.Books (Title, Published, CurrentSales)
OUTPUT inserted.BookID, inserted.ProjectedSales, inserted.ModifiedBy
SELECT Title, Published, CurrentSales FROM OutputSample.SourceBooks
GO

otteniamo come risultato:
BookID ProjectedSales ModifiedBy
----------- --------------------------------------- -----------------
          1   495.000000 XPLAYN\FRANCESCO
          2 5820.000000 XPLAYN\FRANCESCO
          3 2085.000000 XPLAYN\FRANCESCO

(Righe interessate: 3)

I valori restituiti dalla OUTPUT keyword possono anche essere registrati in una variabile di tipo tabella oppure una tabella vera e propria. Per fare ci� baster� aggiungere la parola INTO seguita dalla tabella destinazione.

/* Transact-SQL 2005 */
DECLARE @BooksLog TABLE ( BookID int, Title nvarchar(50) NOT NULL, ModifiedBy sysname )
INSERT INTO OutputSample.Books (Title, Published, CurrentSales)
OUTPUT inserted.BookID, inserted.ProjectedSales, inserted.ModifiedBy INTO @BooksLog
VALUES ('.NET Inside', '01-10-2005', 100)
SELECT * FROM @BooksLog
GO

E' facile immaginare un'utilizzo di questa funzionalit� in ambito di logging delle operazioni (di cui � possibile vedere una soluzione per Sql Server 2000 nel mio articolo "Log delle transazioni mediante trigger").