I have build a Reporting Web Application using ASP.NET and SSRS with SQL DB.
Below is my concern :
Report rendering is slower . I need to make the report faster. Does Crystal Reports or some other things helps me to make report faster? Please suggest
I have heard from the experienced people that SSRS deployment will be more complicated to deploy correctly compared to crystal reports?
Can we build the reporting engine without SQL DB ?
May i know the different technologies to build web based reporting engine which is faster, licensed free, easy maintainence...
Thanks in advance
Ad 1, rendering times. You should investigate the cause for the slow rendering. SSRS is not particularly known for its blazing speed (specially with heavy aggregates and large numbers (hundreds) of pages, but should be fast if you use it just as what it is: a reporting tool. If you have problems, analyze the ExecutionLog2 to check if it's the query, the processing, or the rendering that's giving trouble - and optimize accordingly.
Ad 2, deployment. There are a few issues to pay attention to, but in general you should be fine. In any case your question as it stands is too broad for SO, and fishing for opinions. I recommend you search a bit more, and if you still have a question ask it in chat (subjective, opinions) or on SO (objective, practical questions).
Ad 3, no DB. You can connect a multitude of data sources to a report, including object data sources.
Ad 4 "best". I suggest you remove this subquestion, because it's really a subjective question asking for opinions (this is not recommended, as per the stack overflow FAQ).
Good luck building your reporting solution!
As an answer to 3 => If you use crystal reports for instance, you can construct you own dataset in code and pass the dataset to crystal reports which will do the formatting. This way you can omit the need of an sql db.
Related
I have one issue. Actually we have one spring-mvc web based application , for which we want report generation mechanism. I came across Talend ETL. Can anyone tell whether to use talend as report generation mechanism will be fruitful. Can i integrate it with my application ? Or whether i should search for some jar that can help in fast report generation mechanism.
Thanks
The question is vague, but let me try to answer anyway. Talend is not a reporting platform, but an ETL (read: data handling and transformation) tool.
You can embed a TOS job in your application, and it'sadvisable to do if you need to handle data in a medium/complex way without reinventing the wheel (ie. read an Excel file, do some things, save on DB...). But use it as reporting or data visualization platform would be a pain in the neck.
There're better embeddable solutions for these duties. Birt and JasperReports come in mind, but there's plenty of them. The real question for choosing from is: do you need a low-level reporting service, not much more than a framework at the end of the day, or a polished, maybe client-server, solution to query as a service?
I want to make a website. According to the requirements I have many simple as well as complex reports which may have more column to display sometimes. I haven't worked with the reporting in web. I want to know which is best from both of them according to my requirement.
Without actually knowing your requirements - my gut feeling would be to favor SQL Server Reporting Services.
Why?
It comes with SQL Server, so it's basically free (if you have SQL Server anyway)
it's quite capable in terms of rendering and exporting
it's also extensible with .NET code, if you ever need to
you can schedule reports at a given time etc.
Crystal Reports on the other hand
is a separate add-on you have to buy (and it's quite expensive, too)
it's a bit clunky and hard to use at times (in my opinion)
it doesn't integrate nearly as well with SQL Server and ASP.NET
We have an ASP.NET app with SQL Server & it is a photo & video sharing site.
Details of photos and videos are stored in tables & the files are in the file system.
Database has 75 tables and 225 stored procedures. The app will be ready for production deployment within next 6 months.
Due to longer time growth concerns, we decided to switch to NoSQL (MongoDB) database.
We have few questions regarding the best way to approach this:
Is it better to deploy the app with SQL Server backend and migrate to NoSQL later?
OR re-architecture now and rewrite/recreate database, tables, procedures and data layer
How difficult will it be re-architecture/recode with MongoDB? Any tools or BKMs?
EDIT:
Our app is Youtube+Flickr type site where user will share photos and videos with lots of comments, tags and ratings (photo\video & comments).
Is NoSQL a better database to move to? Reason for moving: cost + read query speed
Please help me with you valuable advise.
Thank you very much.
Change is always exponentially more expensive the later it is introduced to a project. This is a core principle of software engineering. You should do this now.
That said, I question your long-term vision. Relational databases, used properly, have a lot of performance in them.
This question raises more questions than answers.
Have you benchmarked your current implementation in terms of requests/responses?
Why MongoDB out of all possible NoSQL databases? (Don't get me wrong, I love Mongo, but love and hype should not weigh in technology choices)
Are you certain you will get the large userbase you're expecting? Why are you so certain?
Using stored procs seems to tip off that you aren't using an ORM? Why not?
Generally, I'm against these types of re-architectures. Firstly, you need to get your whole team acclimated to how Mongo affects development. Secondly, your ops team needs to get acclimated to how to deploy and maintain a Mongo installation. More likely than not, this will prevent you from launching in a timeline you want to launch.
I'd say that you should probably launch as is, fix the ORM part if you aren't using one, benchmark your app, benchmark a prototype of your app backed by Mongo and if the performance advantages are so big that it warrants the pain of re-architecture do it.
To your latter question, there aren't any tools right now, as far as I can tell, that'll automate or semi-automate the database import/export from SQL Server to Mongo. There are barely tools to do that for MySQL.
I've done such a migration a few month ago, during the early developement stage of a website in ASP.NET. It was a hard decision, but I could concentrate on that migration. The reason why I did this migration was the ORM that I couldn't trust anymore and some very slow queries that I had no idea how to optimize.
During coding phase, what I figured out was : I was spending a lot of time with the data model in SQL Server (using Entity) and all the plumbery code.
Now, no more store procedures (C# and Linq code instead), no more 2 layers to maintain (the code is the model).
My small experience says : The earlier the better but don't get me wrong, before migrating you really have to think in Document rather than in RDBMS. This means you may have to partially change the businness DataModel to correctly utilize MongoDB features, otherwise you could get bad performances and Mongo DB is useless for bad models.
Another point is the admin stuff. You'll have to quickly learn Mongo DB admin to be up to speed. And even if the tools are good, they completely differ from SQL Server tools.
In conclusion, If you're convinced MongoDB is your future data store and search database,
(and it was in my case), read documentation, take time to do some Proof Of Concept. Then you can think Document and load test you new model.
Your core question appears to be whether to make the switch to MongoDB now, or deploy on SQL and go to MongoDB in a future release.
You do not appear to be using an ORM (e.g. NHibernate, Entity Framework.) Setting other concerns aside, if you're convinced that you want to go to NoSQL, then I would do it now rather than later. Unless you integrate a Provider model for your data access, changing the underlying data access strategy after it is already established would be difficult.
I agree. Switching now is better, if only to avoid the data migration headache switching post-deployment will require.
I've been doing research on reporting suites for a project my company is about to undertake, and have narrowed the candidates down to Active Reports and Crystal Reports.
During the demo yesterday, it was clarified to me that one of the capabilities our client would like is the ability for the end-user to create custom reports integrated into the Web-Based client. I know that both packages have options for integrating an end-user designer to a WinForms based app, but I can't find a definitive straight yes or no answer for either suite as to whether or not it's possible to attach them to an ASP.Net based app.
My instinct is no, but I was hoping somebody with more experience in reporting suites could give me a solid yes or no.
I can't speak for Active Report, but it's not hard to find someone who loathes Crystal Reports. AFAIK crystal report editing on web requires BOXI which cost allot but includes a much better reporting tool called web intelligence or "webbi", think of it as a web based pivot table.
No mater which produced you end up choosing if you don't have a star schema the end users are going to have a hard and frustrating time creating reports. Even if you have an abstraction layer you are going hit walls.
Curious why did you decide against SSRS? If you already own SQL server you already have a license.
I used to love activereports. Haven't used them in a while. Did you know that visual studio has built in reporting? So does SQL Server.
I agree with jms, it's not hard to find someone who hates crystal reports.
I think many developers know that uncomfortable feeling when users tell them that "The application is slow (again)."
In a complex web application there can be many possible reasons for a degradation in (perceived) performance: slow database response, bandwidth issues, bad caching etc. There certainly are issues which will never occur in a development or staging environment.
Now my question:
Is there a set of tools and/or methods which would provide a comprehensive "live" state on a IIS/ASP.NET/SQL Server production system in a visually way (not just performance counters):
Current HTTP requests (say the last n minutes)
Exceptions / timeouts
Bandwidth data
Number of open database connections / database calls
...
The primary goal is to see at a glance (or after looking closer) what problem is causing the performance problems.
I think the category of software you're looking for is ".net profiler" or ".net tracer". One such tool that you might consider is JetBrains' dotTrace. It gives you runtime stack traces and an array of counters that indicate possible bottlenecks.
Previously mentioned tools will certainly work. At our shop we needed finer information and built our own solution (long story: it was easier to code than to argue about tools and retrievable data).
I used LogParser to flip through the IIS logs and create output reports of those logs (e.g. result code breakdowns etc).
I used a combination of performance counters and WMI values to get the rest - you can read these using some pretty straightforward C# - this gives you full control that you can then dump to .csv etc for viewing/processing in excel or if you are updating a page as a control center.
I would probably also look at IIS.net as a great resource for IIS tools including debugging, security etc.
I followed urig's advice and found this software called SmartInspect.
Does anybody know this logging/monitoring tool? It seems to be a combination of real time console and developer library.
CLR 4.5 will have some new capabilities that will help you monitor ASP.NET performance live - without restarting your app. Basically you can re-JIT your code to include some monitoring-hooks in it, and then inspect time spent in classes/methods etc.
I'm sure dotTrace and other profiling tools will leverage this automatically, but it's worth checking out: C9 - Inside Re-JIT with David Broman