[CR ?] CR est il le bon choix ?

Bonjour à tous,

Dans le cadre d'un projet d'entreprise, je dois intégrer à un site web (pas encore développé, il le sera sans doute en ASP.NET) des graphiques de toutes sortes que je dois générer dynamiquement à partir d'une base de données (type SQL).

Ces graphiques peuvent être aussi bien des chronogrammes, que des histogrammes, des camemberts, nuages de points, etc... bref un panel ultra large. J'ai beau fouiner sur le web je ne trouve pas grand chose de convaincant, je me tourne vers vous pour savoir si Crystal Reports, dont j'ai de bons échos (je ne l'ai jamais utilisé), serait la bonne solution.

Je ne veux pas créer des rapports à la main mais tout automatiser par le code, depuis les requêtes sur la base de données jusqu'à l'affichage des graphiques et leurs mises à jour sur un site web. CR serait-il le bon choix ? Avez vous des exemples/tutoriels sous la main (ceux que j'ai trouvé ne m'ont pas convaincu pour faire ce que je désire) pour faire ce genre de reporting ?

Merci beaucoup ! :hola:

Bonjour,

Si tu vas faire de l'ASP.net je suppose que tu vas utiliser Visual Studio, qui intègre une version de Crystal Report (version 9 me semble t-il) mais tu peux toujours intégrer n'importe quelle version car des composants d'intégration existe.

J'ai fait exactement ce que tu dois faire il fut un temps.

Pour ce type d'application 2 choix possibles :

• Crystal Reports
• Reporting Services si tu disposes d'un SQL Server

Dans les deux cas tu peux faire exactement ce que tu veux, y compris les exemples que tu as cités.

Concernant les tutoriels pour Crystal Reports et Reporting Services :

tout est la

Personnellement, le choix c'était porté sur Crystal Reports (mes supérieurs en avaient décidé ainsi).

Si tu utilises Crystal Reports, n'oublie pas de déployer à la racine de ton application web, CrRedist.msi qui te permettra d'afficher la toolbar Crystal.

Tu vas aussi rencontrer des problèmes de cache :aie: que je n'ai pas réussi a solutionner me concernant.

have fun :D

Fleur Anne, merci pour ta réponse,

J'ai lu les tutoriels (dont le tiens), c'est en effet le résultat que je désire, mais ce qui me dérange est plus la démarche, qui est de construire les rapports "à la main" cf http://fablain.developpez.com/tutori...ting-services/ où tu expliques (bien) comment créer des graphes à partir d'une base de données.

Ce que je veux justement faire c'est cela, mais via le code (C# par exemple), et je finis par me dire que les systèmes de reporting ne sont pas vraiment conçus dans cette optique.

Si l'on regardde les 3 étapes que tu décris dans "II-B. Conception d'un report", on voit que finalement tout est statique (ce n'est en rien un reproche, juste une constatation), alors que pour moi l'interet enorme du reporting serait par exemple de s'adapter à du monitoring pour sortir regulierement des rapports mis à jour, dont les champs dépenderaient de l'application qui genere le code du rapport.

Par exemple mon application serait à même de décider en le type de graphes et les champs de la base de données qui correspondent, ceci de façon autonome et régulière, il me faudrait alors être capable de générer les rapports que tu montres dans ton tutoriel, mais sans passer par la GUI de VS bien évidemment.

Peut être ne suis pas clair... mais je vais poursuivre mes recherches et en tout cas merci!

SI j'ai bien compris....tu veux que l'utilisateur puisse créer/modifier un report comme il le souhaite avec l'affichage qu'il souhaite, les données qu'il souhaite, etc. en gros tu veux réinventer un outil de reporting ????

Bonne chance :D

:D

Tu as peut être raison en fait .... Je vais revoir mes spec un coup et je reviens...

Bonjour,

Gorguda :

- Ou bien vous définissez des rapports en dur dans votre appli .net et dans ce cas nul besoin de reporter : un simple grapheur suffit (certains sont libres)

- Ou bien vous décidez d'intégrer la définition d'un rapport dans une application de reporting tierce (définition des champs, des types de graphes, des modes d'affichage et de la mise en forme ...) et dans ce cas vous effectuez l'appel du rapport pré-défini depuis votre application métier (ex : une Url), avec un éventuel passage de paramètres.

Une combinaison des deux peut être effectuée : effectuer l'appel vers tel ou tel rapport en fonction d'une succession de tests, de process...

En tout état de cause, la réponse doit être adaptée à votre besoin.
La première solution est simple mais aisément mise en oeuvre. La seconde solution, plus puissante, permet une maintenance et une évolution beaucoup plus souple de vos restitutions.