ottobre 2007 - Posts
Oggi ho aperto Visio per realizzare un paio di schemi per un nuovo progetto e, esplorando i tipi di disegno, ho trovato una cosa interessante: i Diagrammi Pivot. Non so voi, ma io non li avevo mai utilizzati.
Guidato dalla curiosità ne ho creato subito uno e l'ho collegato ad un cubo Analisys Services 2005. L'interfaccia è comoda quanto quella di Excel ed il risultato è veramente notevole.
I dati vengono distribuiti in maniera gerarchica secondo le dimensioni che vogliamo mostrare, possono essere abbinate immagini e si può variare la disposizione degli elementi. Inoltre, anche aggiungendo più misure (ho provato anche con 5 o 6) il diagramma rimane leggibile e ordinato. Poi il valore aggiunto lo danno i temi di Visio (i soliti degli altri disegni, ma comunque carini), con qualche ritocco il diagramma diventa davvero bello e professionale.
Per ora ci ho solo giocato, ma magari a breve mi verrà in mente qualche applicazione in qualche progetto reale, vi farò sapere.
Riprendendo il mio post dell'altro giorno, vi segnalo un bellissimo script per rilevare incongruenze riguardanti le collation utilizzate. Rileva ad esempio database con collation diversa da quella di default, collation diverse nello stesso db e differenze tra le colonne.
Veramente utilissimo, è testato per SQL 2000 SP4 e SQL 2005.
http://www.sqlservercentral.com/scripts/Miscellaneous/31969/
E' tutto il giorno che non riesco a connettermi a http://blogs.msdn.com/ . Ho provato anche da differenti connessioni, il blog di Technet funziona senza problemi invece.
Mamma Microsoft, cosa mi combini???
[ore 17:40]
Ancora niente, ma a questo punto non credo c'entri Microsoft. Curioso comunque, vi allego i tracert.
MSDN
Technet
Mi è capitato di dover "censire" tutti i report che avevo realizzato nel tempo per un cliente (più di 40). In rete ho trovato diversi modi per farlo, ma a me serviva qualcosa di molto veloce.
Il database ReportServer contiene tutte le informazioni di cui avevo bisogno, ho quindi realizzato questo script che non fa altro che esplorare gli item della tabella Catalog. Visualizza solo le informazioni base, ma può essere esteso per mostrare anche tutte le sottoscrizioni (tabella Subscriptions) o creare statistiche sull'esecuzione dei reports (tabella ExecutionLog).
Basta poi utilizzarlo come dataset di un nuovo report e il gioco è fatto.
Ultimamente mi sono trovato anch'io di fronte al simpatico errore "Cannot resolve collation conflict for equal to operation." effettuando il deploy in produzione del db di una applicazione Asp.Net 2.0 che utilizza il Membership Provider. Ovviamente è successo sul server del cliente (doh!).
Analizziamo il problema:
Sviluppo un'applicazione Asp.Net utilizzando il mio database locale SQL Server 2005 (primo errore, il cliente ha solo server con SQL 2000). Al momento del rilascio di una pre-release genero lo script di tutto il db garantendo la compatibilità con la versione 2000. Testo la creazione del db e la sua esecuzione prima su un'istanza locale di SQL Server 2000 e poi su macchina virtuale Windows Server 2003 sempre con la stessa versione del prodotto. Tutto ok.
Durante l'esecuzione dello script sul server del cliente si verifica il seguente errore:
Server: Msg 446, Level 16, State 9, Procedure aspnet_UsersInRoles_AddUsersToRoles, Line 45
Cannot resolve collation conflict for equal to operation.
Server: Msg 446, Level 16, State 9, Procedure aspnet_UsersInRoles_RemoveUsersFromRoles, Line 50
Cannot resolve collation conflict for equal to operation.
Motivo: tutte le mie istanze di test utilizzano la collation di default del server e dei db Latin1_General_CI_AS, mentre il server del cliente sembra utilizzare la SQL_Latin1_General_CP1_CI_AS in almeno uno dei casi.
All'interno delle due stored procedures viene dichiarata una variabile senza la dichiarazione esplicita della collation da utilizzare:
DECLARE @tbNames table(Name nvarchar(256) NOT NULL PRIMARY KEY)
Più avanti nel codice della SP troviamo:
SELECT RoleId
FROM dbo.aspnet_Roles ar, @tbNames t
WHERE LOWER(t.Name) = ar.LoweredRoleName AND ar.ApplicationId = @AppId
A questo punto l'engine deve confrontare due valori senza sapere quale collation utilizzare (le differenze tra due collation possono essere moltissime: ordine delle lettere dell'alfabeto, case sensitive/insensitive, ecc...).
Una delle soluzioni (cito quella che ho utilizzato) consiste nel modificare la dichiarazione della variabile @tbNames in entrambe le SP aggiungendo la dichiarazione della collation:
DECLARE @tbNames table(Name nvarchar(256) COLLATE database_default NOT NULL PRIMARY KEY)
Come mai questa istruzione risolve il problema? Sinceramente non sono sceso troppo nei dettagli (quindi non prendete questa spiegazione come oro colato), ma immagino che il datatype TABLE funzioni in maniera molto simile ad una tabella temporanea. Le colonne delle tabelle temporanee, se non specificato, utilizzano la collation di default del TempDb, il cui valore può essere diverso da quello di default dei database utente.
Quindi, specificando alla colonna della variabile @tbNames di utilizzare la collation di default degli user db, SQL Server è in grado di effettuare la equal operation visto che entrambe i campi (a patto che non abbiate pasticciato con lo script di creazione del db) utilizzano la stessa collation.
Non inserisco links a proposito di questo argomento perchè se effettuate una ricerca su Google scrivendo "Collation Conflict ASP.NET" avete da leggere per qualche settimana.
Segnalo il consiglio di Andrea Benedetti su come eseguire il REBUILD di tutti gli indici di un db con un solo comando, devo dire che fa risparmiare parecchio tempo.
Ecco il link:
http://community.ugiss.org/blogs/abenedetti/archive/2007/09/11/rebuild-di-tutti-gli-indici.aspx
Su SqlServerCentral.com (uno dei siti di riferimento, per chiunque abbia a che fare con questo prodotto) esiste una divertente ed utile sezione denominata Question of the Day. Contiene un grandissimo numero di domande su tutto ciò che ruota intorno a SQL Server e al linguaggio SQL in generale (c'è da passarci la notte!). La cosa migliore secondo me è attenersi alla definizione: rispondere ad una domanda al giorno. Alla fine dell'anno avrete risposto a 365 domande e, vista la complessità di alcune di esse, avrete imparato almeno 100 cose nuove. Il che vorrebbe dire che la vostra conoscenza di SQL si attesta intorno al 75% dalla quale derivo che almeno una delle seguenti affermazioni è vera:
a. Fate parte del team di sviluppo di SQL Server.
b. (Vi chiamate Davide Mauri) OR (Vi chiamate Gianluca Hotz) OR (Vi chiamate Andrea Benedetti) OR ... e così via con tutti gli MVP...
c. Avete sbirciato sull'MSDN prima di rispondere (eh eh eh.. l'ho fatto anch'io, ma solo su alcune).
d. Siete dei MOSTRI di SQL.
In ogni caso si guadagna molto di più sbagliando, la spiegazione della risposta corretta è sempre esaustiva e se non vi basta potete aprire un post sul forum per discuterla insieme agli altri membri del sito. Che volete di più?
Per farvi un esempio la domanda di oggi (ieri, dato che sono quasi le 2:00) era
What is the registry key to check to see if a server needs a reboot? (tratta dal libro Pro SQL Server 2005 High Availability).
Qui trovate il link per rispondere:
http://www.sqlservercentral.com/Questions
è ovviamente necessaria la registrazione al sito, al termine della quale sarete 1203857548935milionesimi nella classifica Member scores and standings.
In bocca al lupo!
A luglio Microsoft ha pubblicato un pacchetto di report relativi alle performance applicabile a SQL Server 2005 SP2 (senza SP2 ve li scordate...).
La suite di report si colloca localmente sul client dal quale avviate Management Studio, si esegue una query che crea alcune SP e si "agganciano" i report mediante la funzionalità Custom Reports di SSMS. Roba da pochi minuti.
Curiosità: i report sembrano (dico "sembrano" perchè finora sembra essere capitato solo a me...) avere problemi sui server avviati da più di qualche mese. Il problema deriva dal fatto che alcune queries all'interno dei report e alcune delle SP create ad hoc tentano di effettuare sottrazioni tra la data attuale (GETDATE()) e la data di avvio del servizio. Non ho ancora indagato attentamente, ma mi sembra di capire che il problema sia un banale overflow durante il DATEDIFF.
Per farli funzionare in queste condizioni ho modificato manualmente (so che non è bello) una delle SP e due DataSet dei reports. Se a qualcuno interessa pubblicherò le modifiche (magari le rivediamo insieme e troviamo la soluzione ideale, il mio è un accrocchio...)
Per ora vi posto il link del pacchetto, se avete server mai riavviati da qualche mese e potete testarli, scopriamo se il problema è reale o si limita alla mia configurazione:
https://www.microsoft.com/downloads/details.aspx?familyid=1D3A4A0D-7E0C-4730-8204-E419218C1EFC&displaylang=en
Comunque, da quanto ho visto, questi reports sembrano essere solo un assaggio di ciò che saranno i nuovi metodi di monitoring "visuale" di Katmai...
Magari non vi servirà mai nella vita, ho forse servirà solo per vantarsi con i colleghi davanti alla macchinetta del caffè...
In questo post del blog di Joe Webb viene spiegato come determinare la data di avvio del servizio (di SQL 2000 e 2005) basandosi sulla data di creazione del TempDb.
In SQL 2005 è anche possibile utilizzare il campo "sample_ms" della DMV "sys.dm_io_virtual_file_stats" il quale contiene appunto il numero di millisecondi intercorsi dall'ultimo avvio.
Qui trovate il post:
http://weblogs.sqlteam.com/joew/archive/2007/10/03/60351.aspx
E' qui l'articole dei books online che descrive la vista:
http://msdn2.microsoft.com/en-us/library/ms190326.aspx
Un gran bel prodotto! Si installa in un attimo (sia sull'ambiente di sviluppo che su quello di produzione, dato che configura automaticamente tutti i file di configurazione e di policy di SSRS), ha una configurazione semplicissima ed è davvero molto potente. Utile se avete bisogno di utilizzare barcode all'interno di fatture, distinte di consegna e documenti vari.
Supporta un numero veramente grande di formati e, cosa molto interessante, ne documenta tutte le caratteristiche.
Si può testare (ovviamente non permette l'esecuzione vera e propria dei reports) senza licenza, ed una volta acquistata basta inserire la licenza nella scheda proprietà dell'oggetto barcode (di cui si fa drag and drop sul report).
Le soluzione di licensing sono parecchie, ovviamente costa.. ma non ho trovato una soluzione freeware altrettanto valida, voi sì?
Ecco il link:
http://www.neodynamic.com/Products/BCRS/BarcodeRS.aspx?tabid=78&prodid=7
E' la prima volta che apro un blog e non ho mai letto il primo post di uno di essi, quindi non ho proprio idea di come cominciare.
Immagino che la cosa più sensata sia presentarmi e dirvi che tipo di contenuti desidero inserire in questo spazio, quindi:
Mi chiamo Edoardo Ribichesu (cognome di evidentissima origine sarda), vivo in provincia di Torino e, come molte delle persone che finiranno in questo blog guidate dai motori di ricerca, sono un consulente IT. Sono appassionato di informatica da quando avevo 5 anni (ovvero da quando mia madre, che ad oggi non sa accendere un pc, mi comprò il Commodore 64). Ebbene sì, faccio parte di quella generezione di bambini che ha imparato a scrivere il proprio nome prima con la tastiera e poi con la penna... Ho frequentato un istituto tecnico informatico (il mitico C.Olivetti di Ivrea) dove ho avuto la fortuna di avere un paio di docenti veramente in gamba in grado di darmi un solido punto di partenza per il mondo del lavoro. Per questioni economiche non ho potuto frequentare l'università (anche se nella vita non si sa mai) e come molti ho inziato a lavorare il prima possibile (in quarta superiore). Punto di partenza di questa avventura fu ovviamente il web, con la realizzazione di siti in PHP/MySQL per amici e parenti, per poi passare a configurazioni di piccole reti per uffici e cose così, un inizio insomma.
Ad agosto 2005, 15 giorni dopo l'esame di maturità, vengo contattato da una piccola società di Torino (per la quale lavoro tutt'ora) che mi richiede competenze sulla piattaforma Microsoft (SQL Server 2000 e ASP.NET), che fino ad allora avevo solo "osservato da lontano". Nei giorni seguenti mi butto sui libri, in modo da non arrivare completamente impreparato e capisco subito che per portarmi ad un livello di base mi sarebbe servito qualche mese di pratica. Per fortuna l'azienda è veramente piccola, ma con prospettive interessanti. Da settembre 2005 inizio a lavorare su una serie di piccoli progetti ASP.NET 1.1 che mi permettono di capire la filosofia del framework .NET, di imparare un nuovo linguaggio (C# dopo due anni di VB e PHP) e apprezzare le potenzialità di SQL Server 2000. Da ottobre dello stesso anno inizia anche la mia carriera di consulente, proiettato dalla mia azienda a fornire consulenza su SQL Server 2000 Reporting Services alla divisione italiana di una multinazionale (!!).
Senza togliere nulla a ciò che sono i SSRS ora, il prodotto all'epoca stava in piedi a fatica... il consulente ancora meno! C'è stato da rimboccarsi le maniche in quel periodo. Avevo già avuto esperienze di BI, ma mai così complesse. Milionate e milionate di record da analizzare in un db mal strutturato e su un server piuttosto datato. C'è stato da divertirsi!
Per fortuna in miei interlocutori in questa azienda erano (e sono) persone in gamba e molto concrete, hanno capito subito le problematiche e mi hanno permesso di lavorare in modo tranquillo, tant'è che sono ancora oggi consulente per quella azienda.
In questi due anni il 70% del mio lavoro ha riguardato SQL Server (2000, 2005 e per ora solo per curiosità 2008), il 25% .NET (1.1 prima, 2.0 e 3.0 poi, in particolare ASP.NET). Il restante 5% è un mix impressionamente di prodotti e tecnologie varie (da VMware a WS2003, da Pervasive BI a Sharepoint, da DNN a SplendidCRM, passando per Rainbow, PostgreSQL, CodeSmith, ecc)
Molti mi hanno detto: facile arrivare adesso che il prodotto (SQL) è stabile, dovevi fare il consulente sulla 6.5! E io rispondo: al tempo della 6.5 facevo le medie :-).
Questo è il mio racconto. Se state dormendo o avete cambiato pagina da 15 minuti vi capisco, ma mi sembrava giusto fare un po' di introduzione. Ora, considerato che questo blog si trova sulla community di UGISS (che ringrazio sia per l'aiuto, la formazione, la simpatia e, non ultima, la possibilità di scrivere questo blog), e considerato che come vi ho detto la mia esperienza è principalmente orientata a SQL Server, secondo voi.... concentratevi, non è così semplice.... di cosa parlerò in questo blog?
Ma di SQL Server ovviamente!
Premesso che non intendo insegnare niente a nessuno, sia chiaro, la mia idea è condividere problemi, soluzioni, casini, prodotti, nottate al pc con fidanzata isterica, consigli, esperienze, links utili, applicazioni (e sono tante ) della legge di Murphy, libri, Oracolisti anonimi, articoli, recensioni e tutto ciò che mi viene in mente riguardante questo prodotto che alla fine, bisogna ammeterlo, certe volte ci fa divertire proprio tanto!
E' l'1:17 e ho finito il mio primo post. Domani si lavora, buonanotte!
ER