Disabilitare e abilitare tutti i trigger di un database SQL Server

by Andrea 17 February 2015 18:05

Nel caso capitasse anche a voi la necessità di disabilitare o abilitare tutti i trigger predenti in un database SQL Server, ho trovato una soluzione davvero comoda a questo link: SQL Server Disabling All Triggers.

-- per disabilitare
sp_MSforeachtable 'ALTER TABLE ? DISABLE TRIGGER all'

-- per abilitare
sp_MSforeachtable 'ALTER TABLE ? ENABLE TRIGGER all'

Tags:

SQL Server

Codice e slide della sessione Windows Azure - Abbattere tempi e costi di sviluppo

by Andrea Dottor 18 June 2013 16:25

Venerdì 7 Giugno 2013 ho tenuto la sessione “Windows Azure - Abbattere tempi e costi di sviluppo”.

In questa sessione vedremo come utilizzare Windows Azure per velocizzare e semplificare la realizzazione di applicazioni ASP.NET. Dallo sviluppo al deploy, passando per lo storage...andremo in dettaglio su varie funzionalità che ci faranno apprezzare ancora più la piattaforma Windows Azure.

 

Qui invece potete scaricare slide e codice della sessione “Riscrivere le query con SQLServer 2012” di Emanuele Zanchettin download

Tags: , , , ,

.NET | ASP .NET | XeDotNet | SQL Server

Avviare un package di SSIS da un'applicazione ASP.NET

by Andrea 29 March 2010 07:22

SSIS Non so come mai, ma utlimamente mi scontro con problematiche non molto documentate. Una di queste è la possibilità di lanciare l'esecuzione di Package di SQL Server Integration Services da un'applicazione ASP.NET.

Cercando in rete, ho trovato solamente due possibili soluzioni, entrambe elencate in questo post. Una soluzione richiede la chiamata ad un job di SQL Server Agent, mentre l'altra soluzione fa uso di un Web Service da pubblicare nella macchina di SQL Server.

La prima soluzione l'ho scartata in quanto non sono riuscito a trovare il metodo per poter passare dei parametri utili a valorizzare le variabili del package (mia ignoranza). Mentre la seconda richiede di installare un'ulteriore applicazione (da dover poi mantenere e ripubblicare), nella macchina di SQL Server, e quindi anche questa scartata.
Può sembrare banale, ma avere un'applicazione in più da mantenere non è sempre semplice, specialmente nel caso l'applicazione sia distribuita in diversi server, e sia presente in casa di diversi clienti.

Guardando le diverse soluzioni, mi è venuta l'idea di provare a adattare la soluzione del Web Service, ma eseguita direttamente da un server remoto. Devo ammettere che ci sono state svariate problematiche, ma alla fine, sono arrivato ad una soluzione perfettamente funzionante.

Ecco come eseguire un package di SSIS da remoto:

Per l'esecuzione del package sarà necessario creare un utente nel database (oppure utilizzarne uno di esistente) ed assegnargli il ruolo db_dtsoperator nel database msdb. Questo ruolo attribuisce all'utente i permessi di:

  • Enumerate all packages.
  • View all packages.
  • Execute all packages.
  • Export all packages.
  • Execute all packages in SQL Server Agent.

Per quanto rigurda la connessione verso il database, nel web.config ho creato una ConnectionString che contiene solamente "Data Source", "User ID" e "Password", questo perchè poi tramite l'uso della classe DbConnectionStringBuilder, verrà poi parsata per recuperarne i singoli valori. Così ho un unico punto dove saranno contenute le credenziali di accesso.

   1: <add 
   2:   name="olapServerAuth"
   3:   connectionString="Data Source=192.168.0.100;User ID=usr;Password=p4$$w0rd;" 
   4:   providerName="System.Data.EntityClient" />

Nell'applicazione sarà necessario referenziare la dll Microsoft.SQLServer.ManagedDTS, e aggiungere alla classe uno using a Microsoft.SqlServer.Dts.Runtime.

Il codice per eseguire il package da remoto sarà il seguente:

   1: // recupero delle informazioni per l'autenticazione al server
   2: DbConnectionStringBuilder cs = new DbConnectionStringBuilder();
   3: cs.ConnectionString = ConfigurationManager.ConnectionStrings["olapServerAuth"].ConnectionString;
   4:  
   5: Application integrationServices = new Application();
   6: // recupero del package che deve essere presente in SQL Server
   7: Package package = integrationServices.LoadFromSqlServer(
   8:                         @"\Data Collector\Test\TestETL",
   9:                         cs["Data Source"] as string,
  10:                         cs["User ID"] as string,
  11:                         cs["Password"] as string,
  12:                         null);
  13:  
  14: // set delle variabili
  15: Variables variables = package.Variables;
  16: variables["VariabileDaSettare"].Value = valoreDaSettare;
  17:  
  18: // set delle connessioni
  19: Connections connections = package.Connections;
  20: connections["AdoNetAnalysisDatabase"].ConnectionString = ConfigurationManager.ConnectionStrings["AdoNetAnalysisDatabase"].ConnectionString;
  21:  
  22: // esecuzione del package
  23: DTSExecResult result = package.Execute(connections, variables, null, null, null);
  24: if (result != DTSExecResult.Success)
  25:     ... // errore nell'esecuzione
  26: else
  27:     ... // avvio corretto del package

Da notare che:

  • DbConnectionStringBuilder: permette di recuperare ogni singolo elemento che compone una ConnectionString. Utile in questo caso per salvare i dati del server di SQL Server, il nome dell'utente di accesso, e la relativa password in un unico container, e poterli poi recuperare singolarmente.
  • Application.LoadFromSqlServer: permette di recuperare un package presente in SQL Server. Se i campi username e password non vengono valorizzati, viene fatto uso della windows authentication.
  • package.Variables: recupero delle variabili utilizzate nel package. Utile nel caso sia necessario modificarne il valore di default prima dell'esecuzione.
  • package.Connections: recupero delle connessioni utilizzate nel package. Da notare che oltre alle stringhe di connessione, compaiono in questa lista anche le connessioni per i Flat File.
    In questi elementi devono essere presenti tutti i valori richiesti, come ad esempio nel caso di una connessione OLEDB dovranno essere presenti: Provider, Application Name e Auto Translate. (per facilità controllate come sono composte nel vostro package).
  • package.Execute: avvia l'esecuzione del package con le nuove variabili e connessioni impostate. 
  • In caso di non successo nell'esecuzione del package, in package.Errors saranno presenti gli errori.

Devo ammettere che ricostruire questo codice non è stato per niente facile, in quanto gli errori che mi si presentavano non erano proprio semplici da decifrare.
La maggiore difficoltà è stata nel capire che le connessioni dovevano riportare tutti i parametri (gli stessi che si possono vedere quando si esegue il package dal SQL Management Studio), ed infine anche il capire quali fossero i permessi minimi da dover dare all'utente per poter eseguire il tutto (per evitare problematiche di sicurezza).
Ma alla fine, tutto ha funzionato alla perfezione, e questo ripaga del tempo speso/investito in questa soluzione.

Tags: ,

SQL Server | ASP .NET | .NET

Reporting Services - report snapshots

by andrea 23 July 2009 02:31

Una funzionalità che trovo molto utilie di Reporting Services sono gli Report Snapshots.

Cos'è un report snapshot?

Uno Report Snapshot non è altro che una copia del report, eseguito in un preciso istante. Questa copia conterrà tutte le informazioni necessarie per permettere di visualizzare il report in un secondo momento, e avere lo stato al momento della sua creazione.

Quando viene chiesto di salavare uno snapshots, Reporting Services esegue il report in questione e immagazzina tutte le informazioni che vanno a popolare i dataset utilizzati nel report stesso (e anche il layout del report). In questo modo, quando viene richiesta la visualizzazione di un preciso Snapshot, si hanno a disposizione i dati già elaborati, che erano presenti in quel preciso istante (data + ora).
Ecco cosa viene salvato nel server di Reporting Services:

  • The result set (that is, the data in the report, retrieved through the credentials specified in the Data Sources properties page of the report).
  • The underlying report definition, as it exists at the time the snapshot was created. If the report definition was subsequently modified after the snapshot was generated, those changes are not reflected in the snapshot.
  • Parameter values that are used to obtain or filter the result set.
  • Embedded resources, such as images. External resources that are linked to a report are not stored with the report snapshot.

Un enorme vantaggio, che porta all'uso dei Report Snapshots, è il fatto di poter essere schedulati, ed esistono molte impostazioni possibili a riguardo. (esecuzione a intervalli prestabiliti, in precisi giorni, una sola volta, ...)

I Report Snapshots hanno però anche delle limitazioni, una di queste, è dovuta al fatto che vengono salvanti anche i valori dei parametri, e questo comporta che se vogliamo Snapshot con parametri differenti, si dovranno creare differenti Report (o Linked Reports), ma questo è anche capibile.
In alcune condizioni però, è possibile utilizzare un parametro (visibile) all'interno del report per filtrare i dati. Infatti, il filtro dei dati all'interno del report è una prassi consentita, in quanto viene applicato ai dati che popolano i DataSet (e quindi immagazzinati nello snapshot)

Quando utilizzare i report snapshots?

Possono essere utilizzati prevalentemente per due motivazioni:

  • Si vuole avere uno storico di un determinato report.
    Schedulando la creazione di snapshot a determinati intervalli, permettono di avere esattamente la situazione (il risultato del report) in quel dato momento, e quindi poter eseguire a posteriore una visualizzazione di tali dati.
  • Esecuzione di report che richiedono molto tempo di elaborazione.
    E' possibile schedulare l'esecuzione di snapshot per ovviare al problema dell'attesa per l'elaborazione di report che richiedono un lungo tempo di caricamento. In questo modo, l'utente può visualizzare l'ultimo snapshot eseguito, che verrà caricato velocemente in quanto i dataset sono già stati popolati durante la creazione dello snapshot, risparmiando così l'attesa all'utente.

Come visualizzare uno snapshot nel controllo ReportViewer

Per visualizzare uno snapshot di un preciso report nel controllo ReportViewer è sufficiente impostare la proprietà HistoryId del controllo, con l'ID dello snapshot che si vuole visualizzare.

reportViewer.ServerReport.HistoryId = historyID;

Utilizzando il web service esposto da Reporting Services (Consumare il web service di Reporting Services) è possibile recuperare la lista di Snapshots di un determinato report, e utilizzare i dati ricevuti per recuperare l'identificativo dell'ultimo Snapshot eseguito.
Ecco come poter recuperare la lista di tutti gli snapshot di un determinato report:

   1: public ReportHistorySnapshot[] GetReportHistory(string reportFullPath)
   2: {
   3:   using (ReportingService2005SoapClient rs = ReportingService2005SoapClient())
   4:   {
   5:       rs.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
   6:       rs.ClientCredentials.Windows.ClientCredential.UserName = "username";
   7:       rs.ClientCredentials.Windows.ClientCredential.Password = "password";      
   8:  
   9:       ReportHistorySnapshot[] snapshots = null;
  10:       rs.ListReportHistory(reportFullPath, out snapshots);
  11:  
  12:       return snapshots;
  13:   }
  14: }

Link:

Tags: ,

SQL Server | .NET | Reporting Services