0

J'ai un rapport SSRS qui est affiché aux utilisateurs dans le contrôle ASP.NET ReportViewer. Le rapport comporte de nombreux paramètres et nous utilisons les invites de paramètre proposées par le contrôle ReportViewer. En fonction d'un certain paramètre du rapport, il suffit que l'utilisateur soit invité à entrer un sous-ensemble du reste des paramètres du rapport.Problème lors de la tentative d'affichage/masquage des paramètres dans le contrôle ReportViewer ASP.NET

Nous aurions pu utiliser des rapports liés et masquer les paramètres appropriés, mais il existe de nombreuses combinaisons possibles pour ce premier paramètre (il est multi-valué), nous préférons ne pas le faire. Au lieu de cela, nous avons un ListBox ASP.NET qui contrôle le premier paramètre et lorsque sa sélection est modifiée, nous utilisons la fonction ReportViewer.ServerReport.SetParameters() pour masquer/afficher les paramètres (il prend dans un tableau de ReportParameter et le constructeur ReportParameter prend un booléen pour cacher/montrer le paramètre).

Voici le problème. Tout fonctionne bien dans notre environnement de développement. Lorsque nous déployons le rapport et le site ASP.NET dans l'environnement de production, les paramètres ne sont jamais affichés lorsque ces appels SetParameters() sont appelés. Nous savons que le code est appelé parce que nous mettons une sortie de débogage pour être sûr. Le code pour masquer les paramètres fonctionne correctement. C'est juste le code qui devrait faire apparaître certains paramètres à nouveau ne fonctionne pas. Non seulement les invites de paramètre n'apparaissent pas, mais la propriété Visible du paramètre n'est pas définie sur true (vérifiée à l'aide de ReportViewer.ServerReport.GetParameters()).

SQL Server 2005 SP3 est installé dans les deux environnements et la même version du contrôle du visualiseur de rapports (Microsoft.ReportViewer.WebForms.dll). Des idées sur ce qui pourrait être faux? Des idées de contournement? Si vous avez des questions, laissez des commentaires.

Éditer: Après plus d'investigations, nous avons isolé le problème plus loin. J'ai fait un rapport simple avec seulement 1 paramètre sans aucune connexion DB. Puis j'ai fait une page aspx avec 2 boutons et un contrôle ReportViewer relié à ce rapport. 1 bouton cache le paramètre et 1 bouton montre le paramètre (en utilisant la fonction SetParameters(), comme mentionné ci-dessus). Même avec ce scénario simple, les boutons hide/show fonctionnent bien dans l'environnement de développement, mais nous avons toujours le même problème dans l'environnement de production (le bouton show ne fonctionne pas). Nous avons également essayé ceci sur un autre serveur sur le réseau dans l'environnement de production, et nous avons le même problème. Donc, tout semble fonctionner correctement dans l'environnement de développement, mais sur deux serveurs différents en dehors de cet environnement, nous semblons avoir le même problème.

Édition2: Vous trouverez ci-dessous le code de la page du rapport de test. La page a un ReportViewer, 2 boutons, et une étiquette pour la sortie de débogage. Lorsque l'affichage des paramètres masqués ne fonctionne pas, l'étiquette indique même que la propriété Visible est toujours false après l'appel à ShowParameter.

Public Partial Class TestReportPage 
    Inherits System.Web.UI.Page 

    Public Sub HideParameter(ByVal parameterName As String) 
     Dim parameters As ReportParameterInfoCollection = ReportViewer1.ServerReport.GetParameters() 
     ReportViewer1.ServerReport.SetParameters(New ReportParameter() {New ReportParameter(parameterName, GetParameterDefaults(parameterName, parameters), False)}) 
     parameters = ReportViewer1.ServerReport.GetParameters() 
     lblTest.Text &= "Hide param " & parameterName & "; Is Visible: " & parameters(parameterName).Visible & "<br>" 
    End Sub 
    Public Sub ShowParameter(ByVal parameterName As String) 
     Dim parameters As ReportParameterInfoCollection = ReportViewer1.ServerReport.GetParameters() 
     ReportViewer1.ServerReport.SetParameters(New ReportParameter() {New ReportParameter(parameterName, GetParameterDefaults(parameterName, parameters), True)}) 
     parameters = ReportViewer1.ServerReport.GetParameters() 
     lblTest.Text &= "Show param " & parameterName & "; Is Visible: " & parameters(parameterName).Visible & "<br>" 
    End Sub 
    Public Shared Function GetParameterDefaults(ByVal parameterName As String, ByVal parameters As Microsoft.Reporting.WebForms.ReportParameterInfoCollection) As String() 
     Dim paramDefaults() As String = {} 
     Dim i As Int16 = 0 
     For Each paramValue As String In parameters(parameterName).Values 
      ReDim Preserve paramDefaults(i) 
      paramDefaults(i) = paramValue 
      i = i + 1 
     Next 
     Return paramDefaults 
    End Function 
    Protected Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click 
     HideParameter("foo") 
    End Sub 
    Protected Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click 
     ShowParameter("foo") 
    End Sub 
End Class 
+0

Avez-vous un exemple de code sur la façon dont vous définissez les paramètres à partir de la page ASP.NET? Peut-être votre test simple. J'ai rencontré des problèmes similaires mais le problème s'est avéré être le code et non le rapport. – Mozy

+0

J'ai édité la question avec le code pour la page de test ASP.NET. –

Répondre

0

Juste pour quelqu'un d'autre qui a toujours cette question, voici la raison pour laquelle nous avions cette question:

La question était due à une différence dans les environnements. Même si la DLL ReportViewer a été copiée dans le dossier bin du projet (et donc copiée là où le projet a été hébergé), ce problème w/params est un bogue dans les anciennes versions du contrôle ReportViewer. Vous devez obtenir le Microsoft Report Viewer Redistributable 2005 SP1 pour résoudre ce problème. Apparemment, nous avons installé ce correctif dans l'environnement de développement. Pour une raison quelconque, la DLL ReportViewer était la même version des deux côtés. Cela peut être dû au fait que la DLL était en cours d'accès à partir d'un emplacement différent.

Questions connexes