Report generators?
-
Where would Sander find an IBM 1401 today? Would it even fit into his house office? Could he afford the electricity bill for one of those dinosaurs? (To say nothing of getting tech support via séance...)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Why not try the original[^]?
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
Still better than Crystal Reports!
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Hand-coding PDF margins etc?? :omg: For most reporting, I tend to use HTML. If it's simple enough to use data-bound repeaters / grids, embed them in the page then render them on the server into an HTML string. For more complex reports combine that with external templates. Then shoot the resulting HTML into an HTML -> PDF converter (I use Pechkin, even though it has a bunch of dependencies and is 32-bit; but it generates a good result). That way all I need to do is adjust the HTML template or on-page data controls. Once the PDF is done, hide the data controls and show the page with a link to the PDF, or just redirect to the PDF - depending on requirements.
Yeah, hard-coding, but that's not very different from the HTML to PDF generators I've used. My problem with HTML to PDF is that HTML is not created for a fixed size (A4, in my case). It literally doesn't know pages, so a footer or a header is very difficult. All in all, I didn't like it. Hard coding means you have to tweak once, but at least it won't change as both your hard coding and A4 size remain the same. Unfortunately, the same can't be said about HTML formatting.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I have looked at report generators since the 80's and concluded long ago they aint worth the hassle, because they rarely give you exactly what you want, and from a customer point of view they are difficult to use with no-one wanting to take responsibility for learning them, and even if they do when that person leaves it's back to square one. When designing a solution i try make my reports give all the options i can think, and usually also have a 'dump to csv' checkbox, so as well as producing a pdf, it will create a file the customer can manipulate themselves in excel. If there's really something in there not initially discussed or wanted later as needs change, i quote and charge, unless it's a quick mod to filter data in a certain way as a one off and takes me less than an hour, which i do as part of the support contract. GL Bob
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I've used Crystal Reports Writer (CRW) and ReportBuilder (http://www.digital-metaphors.com/products). ReportBuilder was almost as powerful as CRW, but I found it harder to use. Though I admit this could have just been because I am very experienced with CRW. We have WinForms DevExpress, but have never used it for reporting. I find DevExpress to have so many options, that interact with each other in so many mysterious ways, that it is hard to configure everything correctly. I like CRW. I find it simple to use, and I can quickly spit out almost any report that has been asked for. Caveats: 1. This is Windows desktop development only. 2. All reports are effectively client-side only. The data is retrieved from the server, but the report is local. 3. We have a standard (to us) library that displays CRW reports. We just pass in the path to the RPT file and the parameters. The library displays the report with all the UI options. 4. We use the CRW IDE to create the reports; we don't do that via code.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
We use DevExpress XtraReports in our solution. One of our customers was ready to invest 2 hours in a training (we did the training) to be able to design his own reports. After that they were self-sufficient to create their own reports.
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I didn't realize that Crystal Reports was still around. I have used multiple versions of this software during my career and never liked any of them. You may want to try the Syncfusion reporting product. As a developer you can obtain a community license...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
we used stimulsoft reports (with wpf back in the day) since it needed just limited dot net dll to render and did not need the cr runtime etc and all the mess. and came with a designer you could give the client if he needed to roll his reports.. save the report add to app and run wella and it had multiple export options .since then they have multiple engines and solutions
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I believe our company has a software solution that may pique your interest. I suggest you take a quick look at our product, INSYTE for SQL. Link: www.responsetech.com/insyteforsql. I am the INSYTE Product Manager, which includes the duties of both developer & tech support. If you have questions please contact me directly by email: kevin(at)responsetech.com and simply mention you learned about the software from CodeProject.
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Don't laugh. I have converted several apps that used to use CR to put the output to Excel. More recently I have just used Excel to query the database to replace a CR. Users really like when I do that and going back a year later, I find many of the reports I did have been edited. Everyone works with Excel. Most of the time is it is just secondary calculations. Many get very skilled. Seeing how I did the queries several have even changed the queries. In all cases the reports are now better suit the needs. Using Excel has now achieved the goal(dream) of letting users edit reports.
So many years of programming I have forgotten more languages than I know.
-
Don't laugh. I have converted several apps that used to use CR to put the output to Excel. More recently I have just used Excel to query the database to replace a CR. Users really like when I do that and going back a year later, I find many of the reports I did have been edited. Everyone works with Excel. Most of the time is it is just secondary calculations. Many get very skilled. Seeing how I did the queries several have even changed the queries. In all cases the reports are now better suit the needs. Using Excel has now achieved the goal(dream) of letting users edit reports.
So many years of programming I have forgotten more languages than I know.
Upvoting this big time. Working with a couple of other s/w developers, I have learned that generating files that are consumable by Excel is a gem of an idea. Another variation on this is logging (sort of like a report) - develop a consistent format and do the logging in comma delimited fashion. One guy I work with has legendary excel spreadsheets to diagnose production lines.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Don't laugh. I have converted several apps that used to use CR to put the output to Excel. More recently I have just used Excel to query the database to replace a CR. Users really like when I do that and going back a year later, I find many of the reports I did have been edited. Everyone works with Excel. Most of the time is it is just secondary calculations. Many get very skilled. Seeing how I did the queries several have even changed the queries. In all cases the reports are now better suit the needs. Using Excel has now achieved the goal(dream) of letting users edit reports.
So many years of programming I have forgotten more languages than I know.
michaelbarb wrote:
Don't laugh.
I'm not laughing at all. I've created some Excel reports these last few years and users love them and they're easy for me to make and change. Between Excel and the PDF library (both free libraries to boot), I've covered all my reporting needs :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I believe our company has a software solution that may pique your interest. I suggest you take a quick look at our product, INSYTE for SQL product at www.responsetech.com/insyteforsql. I'm the INSYTE Product Manager, which includes duties of developer & tech support. If you have questions please contact me directly at kevin(at)responsetech.com and simply mention you learned about the software from CodeProject.
-
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Check out a product called : INSYTE for SQL product Link: www.responsetech.com/insyteforsql.
Kevin Kohler
INSYTE Product Manager
Response Technology, Inc.
Kevin@responsetech.com -
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Check out a product called : INSYTE for SQL product Link: www.responsetech.com/insyteforsql.
Kevin Kohler
INSYTE Product Manager
Response Technology, Inc.
Kevin@responsetech.com -
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Check out a product called : INSYTE for Sql product Link: www.responsetech.com/insyteforsql.
Kevin Kohler
INSYTE Product Manager
Response Technology, Inc.
Kevin@responsetech.com -
So I'm editing some Crystal Reports again (excuse my inappropriate language). I have this one project that still uses them. I've searched for alternatives plenty of times, found stuff like DevExpress reporting, and heard good stuff about that one too. Not that I'm going to rewrite all reports for this particular project, but maybe for a future project. However, for other projects I don't even bother anymore and simply use MigraDoc and create PDF files in code manually. Writing stuff like:
frame = section.AddTextFrame();
frame.Width = "12cm";
frame.Left = "10cm";
frame.RelativeHorizontal = RelativeHorizontal.Margin;
frame.Top = "6cm";
frame.RelativeVertical = RelativeVertical.Page;It's not ideal, but it still beats CR (but pretty much anything would). To me, the whole reason to use a report generator like CR is that your clients can create their own reports. Kind of like a no-code solution for your reports. In practice, however, clients don't understand these tools anyway and still ask me to change reports for them. Meanwhile, a bit of code reuse ensures your reports have the exact same headers, footers, etc. while not being all that much harder for me (or even lots easier in case of CR). Thoughts? Generator vs. in-code? Your generator of choice?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
There are other tools out there!!! Including software we use. Contact me back if you are interested!
-
Because of history (thousands of reports) we still use ActiveReports (GrapeCity) to actually generate the report. However for editing reports (end-user) we use DevExpress. It works and has good support. If today we would start fresh we probably would go with DevExpress...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
michaelbarb wrote:
Don't laugh.
I'm not laughing at all. I've created some Excel reports these last few years and users love them and they're easy for me to make and change. Between Excel and the PDF library (both free libraries to boot), I've covered all my reporting needs :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
More than once I have had peers that sneered when I suggested it. One went so far to ask if I needed my diaper changed. But then in the next round of layoffs he was let go and I stayed. My customers kept asking for more Excel spread sheets.
So many years of programming I have forgotten more languages than I know.
-
Got a project with DevExpress. No real opinion on it besides that you should never use it - but that goes for any reporting tool that mess with the database. ;P For anything somewhat serious you need a layer between the user and the database. Luckily we have "somewhat of a layer", so our users are not completely tightly coupled with the database structure. This is more by luck than design as the original developers had no clue you should never do that - I guess that happens when you pride yourself with only employing the smartest people.... but then ignore the lack of experience :doh:. Unfortunately this layer means "try reading everything into memory, then combine it at runtime" if you do not know exactly what you are doing... oh well... Most reports customers create still executes in less than 24 hours.... not all of them though. X| Luckily we have a couple of non-developers who knows there way around the tooling (better than us developers). Sure you could probably do some things with database views to decouple.. but... ehh... it's 2022, can we please start working on top of APIs thank you very much. I hope this nonsense goes away and we can offload to PowerBI and similar in the future. But our customers can't just throw all the data in the cloud, so getting too many on-prem dependencies are also problematic. :(
We use Telerik, calling stored procedures that provide the data. The stored procedure, like a view, isolates us somewhat from the actual table and column names.
