Report Builder 3.0 Limitations

Question

Je crée une application et le client demande des rapports. Normalement, nous créons les rapports pour eux en utilisant les services de reporting. Nous voulons donner au constructeur de rapports du client et les laisser construire leurs propres rapports. Certains de ces rapports peuvent être complexes et je ne suis pas sûr à 100% à quel point le constructeur de rapports nous mènera. Avant de décider si cela vaut la peine de donner le générateur de rapport client. Quelles sont les limites du générateur de rapports? Quel type de rapport n'est-il pas bon pour?

Answer 1

J'ai trouvé que c'était bien pour créer et gérer des rapports à placer sur le serveur de rapports. Vous ne pouvez évidemment pas l'utiliser pour les rapports .rdlc. Pour la plupart des utilisateurs standard et des utilisateurs expérimentés, tout ira bien et fera ce dont ils ont besoin, et ne nécessitera pas l'intégralité du shell IDE de VS fourni avec SQL Server (BIDS). Rappelez-vous, si le client demande à gérer ses propres rapports, c'est une sorte de «tout ou rien». Vous ne pouvez pas limiter leur accès aux données. Assurez-vous qu'ils disposent d'un compte de rapports en lecture seule configuré sur le serveur. Tous les rapports que vous créez pour eux à l'origine sont sauvegardés.

Le temps de préparation peut varier en fonction du niveau technique de l'utilisateur final devant utiliser l'outil.