Techniques de résolution des problèmes liés aux rapports

Nouveau : 17 novembre 2008

La première étape de résolution d'un problème lié à un rapport consiste à identifier les composants impliqués. Par exemple, si vous affichez un rapport sur le serveur de rapports, vous visualisez un rapport à l'aide du convertisseur HTML dans le Gestionnaire de rapports. Si vous affichez le rapport en prévisualisation, vous visualisez un rapport dans le contrôle de visionneuse de rapports dans Business Intelligence Development Studio. Si vous affichez un rapport qui a été exporté vers Excel, vous utilisez Excel sur l'ordinateur client local pour ouvrir le fichier exporté. Pour comprendre et aider à résoudre le problème, vous devez tout d'abord identifier les composants impliqués dans ce problème. Essayez de recueillir le plus d'informations possible concernant le composant ou le processus. Utilisez les informations fournies dans cette rubrique pour en savoir plus sur les différentes manières de résoudre les problèmes liés aux rapports.

Les liens ci-dessous fournissent des informations supplémentaires sur des rubriques spécifiques :

Technique : surveillance des serveurs de rapports

Vous pouvez utiliser des outils système et des outils de base de données pour surveiller l'activité du serveur de rapports. Vous pouvez également afficher des fichiers journaux de trace de serveur de rapports ou interroger le journal d'exécution du serveur de rapports afin d'obtenir des informations détaillées concernant des rapports spécifiques. Si vous utilisez l'Analyseur de performances, vous pouvez ajouter des compteurs de performance pour le service Web Report Server et le service Windows afin d'identifier les goulots d'étranglement lors du traitement planifié ou à la demande.

Pour plus d'informations, consultez Analyse des performances d'un serveur de rapports.

Technique : affichage des journaux de serveur de rapports

Reporting Services enregistre de nombreux événements internes et externes dans des fichiers journaux qui contiennent des données concernant des rapports spécifiques, des informations de débogage, des requêtes et réponses HTTP et des événements de serveur de rapports. Vous pouvez également créer des journaux de performances et sélectionner des compteurs de performance qui spécifient les données à recueillir. Le répertoire par défaut des fichiers journaux pour une installation d'instance par défaut est <lecteur>\Program Files\Microsoft SQL Server\MSSQL.N\Reporting Services\LogFiles. Pour plus d'informations, consultez Fichiers journaux de Reporting Services.

Pour déterminer de manière spécifique si les durées d'attente de rapport sont dues à l'extraction des données, au traitement du rapport ou au rendu du rapport, utilisez le journal d'exécution. Pour plus d'informations, consultez Journal d'exécution du serveur de rapports.

Technique : affichage de la pile des appels pour les messages d'erreur de traitement de rapport sur le serveur de rapports

Lorsque vous affichez un rapport publié dans le Gestionnaire de rapports, vous pouvez recevoir un message qui signale une erreur générale de traitement ou de rendu. Pour afficher davantage d'informations, vous pouvez consulter la pile des appels.

Pour afficher la pile des appels, ouvrez une session sur le serveur de rapports avec des informations d'identification d'administrateur local, cliquez avec le bouton droit sur la page Gestionnaire de rapports, puis cliquez sur Afficher la source. La pile des appels fournit le contexte détaillé du message d'erreur.

Technique : activation des erreurs distantes sur le serveur de rapports

Dans le Gestionnaire de rapports, lorsque vous affichez un rapport avec une erreur, le message d'erreur suivant peut s'afficher : « Pour obtenir plus d'informations sur cette erreur, accédez au serveur de rapports sur le serveur local ou activez les erreurs distantes ».

Pour afficher davantage d'informations sur l'erreur, vous pouvez configurer un serveur de rapports de manière à fournir des informations sur le contexte du message d'erreur. Pour plus d'informations, consultez Procédure : activer les erreurs distantes (Configuration Reporting Services).

Technique : utilisation de SQL Server Management Studio pour vérifier les requêtes et les informations d'identification

SQL Server inclut SQL Server Management Studio, un outil de gestion pour les composants décisionnels. Utilisez Management Studio pour vous connecter à votre source de données, ouvrez une fenêtre de requête, puis créez et validez les requêtes complexes avant de les inclure dans votre rapport.

Pour vérifier si vous pouvez accéder à la source de données sous un contexte de sécurité différent, exécutez Management Studio à l'aide de la commande Microsoft Windows Run As et entrez les informations d'identification que vous souhaitez tester. Pendant que Management Studio est ouvert, les connexions aux sources de données utilisent les informations d'identification spécifiées.

Pour plus d'informations, consultez Requête Transact-SQL - SQL Server Management Studio et Utilisation de l'Explorateur d'objets.

Technique : analyse des rapports de problèmes avec les données de rapport mises en cache sur le client

Lorsqu'un auteur crée un rapport dans Business Intelligence Development Studio, le client de création de rapport met en cache les données dans un fichier .rdl.data, qui est utilisé lors de la prévisualisation du rapport. Chaque fois que la requête change, le cache est mis à jour. Pour déboguer les problèmes de rapports, il est parfois utile d'empêcher l'actualisation des données du rapport, de sorte qu'elles ne changent pas lorsque vous effectuez le débogage.

Pour contrôler si BI Development Studio utilise uniquement les données du cache, vous pouvez définir la propriété ForceCache dans le fichier de configuration d'application devenv.exe.config. Par défaut, le fichier de configuration se trouve dans le répertoire suivant : <drive>:Program Files\Microsoft Visual Studio 8\Common7\IDE. Pour empêcher que les requêtes actualisent les données, affectez la valeur 1 à ForceCache. Le code suivant illustre la configuration du cache sous la forme d'un fragment XML :

...
<system.diagnostics>
  <switches>
    <add name=
"Microsoft.ReportDesigner.ReportPreviewStore.ForceCache" value="1"
    />
    </switches>
</system.diagnostics>
...

Tant que ForceCache a la valeur 1, seules les données du rapport mises en cache sont utilisées. N'oubliez pas de supprimer cette section une fois que vous avez terminé de déboguer le rapport.

Voir aussi

Concepts

Fichiers journaux de Reporting Services

Autres ressources

Erreurs et événements de Reporting Services
Dépannage de Reporting Services

Aide et Informations

Assistance sur SQL Server 2005