Attualmente uno dei grossi limiti dei Reporting Services - anche se, a dirla tutta, è un pò forzato parlare di limite - è l'impossibilità da parte dell'utente finale (l'utilizzatore del report) di poter ridefinire la query sulla quale il report è stato creato.
Certo, la presenza dei parametri e la possiblitià quindi di creare query parametriche rende l'esigenza piuttosto remota, ma non per questo meno sentita quando si devono realizzare report i cui parametri, a priori, non sono conosciuti. Questo può avvenire quando il report è fatto su una base dati piuttosto grossa, dove non è possibile sapere che tipo di filtro dovrà essere applicato e con che logica.
Missione impossibile? Per nulla! I Reporting Services sono stati progettati per essere estesi e quindi...detto fatto: scartata l'ipotesti di crearea una data extension, data la difficoltà che, nel mio caso, unita al poco tempo a disposizione, rendeva la strada poco percorribile, ho scelto un'altra via che si è mostrata altamente flessibile e altrettanto potente.
La via scelta è quella di costruire un custom assembly che è in grado di produrre una query T-SQL o PL-SQL al volo, tramite l'adozione di un semplice Object Model per l'incapsulamente della stessa. Tale query può essere passata ai Reporting Services come expression: con questo giochetto i Reporting Services diventano così capaci di potere eseguire una query specificata da un utente a run-time, non a design time, tramite un'applicazione creata ad-hoc per far si che la query possa essere creata visualmente, senza che l'utente finale di debba trovare a dover scrivere una sola riga di codice SQL.
Niente male davvero!