Utilisation de la procédure stockée SQL en tant que données pour un rapport Microsoft Dynamics CRM

Question

Nous avons besoin d'un rapport semi-complexe dans CRM qui affiche certaines valeurs cumulées. La seule façon dont je vois ce rapport fonctionner est d'écrire une procédure stockée qui crée deux tables temporaires et calcule/accumule des données en utilisant des curseurs. Ensuite, il est nécessaire d'obtenir les données de la procédure stockée pour être accessibles à partir du rapport Reporting Server. Est-ce que quelqu'un sait si c'est possible? Si je pouvais avoir l'option d'écrire une instruction SQL personnalisée pour générer des données de rapport, ce serait tout simplement excellent.

Des pointeurs?

Edit:

Pour clarifier mon utilisation de curseurs je peux expliquer exactement ce que je fais avec eux.

La base de mon rapport (qui devrait être un tableau BTW) est une table (tableau 1) qui a 3 colonnes pertinentes:

Start date 
Number of months 
Value 

Je crée une table temporaire (Temp1) qui contient les colonnes suivantes:

Year 
Month number 
Month name 
Value 

Première boucle I à travers les rangées dans la première table et insérer une ligne dans le temptable pour chaque mois, incrémenter mois, tout en fixant la valeur de la valeur totale divisée par mois. I.e.:

2009-03-01,4,1000 des rendements table1

2009,03,March,250 
2009,04,April,250 
2009,05,May,250 
2009,06,June,250 

dans la table temp1.

Un nouveau curseur est ensuite utilisé pour additionner et créer un total cumulé à partir des valeurs de temp1 et l'alimenter en temp2 qui est renvoyé à l'appelant sous forme de données à graver.

exemple données temp1:

2009,03,March,250 
2009,04,April,200 
2009,04,April,250 
2009,05,May,250 
2009,05,May,100 
2009,06,June,250 

rendements temp2 données:

2009,03,March,250,250 
2009,04,April,450,700 
2009,05,May,350,1050 
2009,06,June,250,1300 

La dernière colonne est le total de fonctionnement, qui commence à zéro pour chaque nouvelle année.

Answer 1

J'ai trouvé la solution. Report Builder 2.0 téléchargé de Microsoft. Cela me permet d'écrire des requêtes et d'appeler des procédures stockées pour les données du rapport.

Microsoft SQL Server Report Builder link

Answer 2

Avez-vous envisagé d'utiliser des vues. Utilisez une hiérarchie de vues si c'est très compliqué. Chaque vue représente l'une de vos tables temporaires.

EDIT Sur la base des commentaires

Je songeais de vues SQL, essentiellement le même SQL que vous avez écrit dans vos procédures stockées.

Answer 3

Je n'ai pas fait cela - je pensais simplement comment je commencerais. Je m'assurerais que lorsque les procédures stockées peuplent les tables temporaires, elles utilisent les vues filtrées pour extraire des données. Je définirais alors l'accès pour exécuter le SP pour avoir les mêmes rôles de sécurité que les vues Filtered (ce qui devrait être à peu près pour permettre aux membres du PrivReportingGroup).

Je pense que cela couvrirait vous permettant d'exécuter le SP dans votre rapport. J'imagine que si vous configurez le SP avant la main, le concepteur SSRS a un moyen de vous montrer quelles sont les données disponibles et de sélectionner un SP lors de la conception. Mais je ne le sais pas à coup sûr.

Answer 4

D'abord, comme la plupart des curseurs sont inutiles, que faites-vous exactement dans ces curseurs? Il existe peut-être une solution basée sur un ensemble et vous pouvez ensuite utiliser une vue. Une autre ligne de pensée possible, si vous faites quelque chose comme courir des totaux dans le curseur, est-ce que vous pouvez créer une vue en tant que source sans le total cumulé et le rapport lui-même fait ce genre de calcul? En outre, les rapports SSRS peuvent utiliser des procs stockés comme source de données, lire à propos de comment dans Livres en ligne.