Report generators?
-
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
-
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 used and would use Devexpress again. Why? Because of actual functioning support.
Wrong is evil and must be defeated. - Jeff Ello
-
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
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. :(
-
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. :(
lmoelleb wrote:
No real opinion on it besides that you should never use it - but that goes for any reporting tool that mess with the database.
Funny comment. :doh: It's not like as if you can't use it with a model instead of a database.
Wrong is evil and must be defeated. - Jeff Ello
-
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
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
-
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
Why not try the original[^]?
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
lmoelleb wrote:
No real opinion on it besides that you should never use it - but that goes for any reporting tool that mess with the database.
Funny comment. :doh: It's not like as if you can't use it with a model instead of a database.
Wrong is evil and must be defeated. - Jeff Ello
Could be - in our project they "saved time" by using the same model across all tiers - so model and database is pretty much the same crap. There probably is a better way to build it with DevExpress reporting, I am not going to look for it though - it will be booted out instead of being corrected.
-
Could be - in our project they "saved time" by using the same model across all tiers - so model and database is pretty much the same crap. There probably is a better way to build it with DevExpress reporting, I am not going to look for it though - it will be booted out instead of being corrected.
Seems to me that your problem isn't Devexpress, but the implementation of it. Anyway... Sometimes the best solution is to start over, and when you do, use the tools you know best.
Wrong is evil and must be defeated. - Jeff Ello
-
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 SSRS still for a lot of our reports, but that is because we are cheap bastards with the reporting. We do have plans to stop using SSRS in place of another product at some time. SSRS is ugly but it works and it is fully compatible with VS and Sql Server, etc.
-
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
You can find some open-source reporting tools here: best-open-source-reporting-tools[^] FastReport looks interesting ...
-
Seems to me that your problem isn't Devexpress, but the implementation of it. Anyway... Sometimes the best solution is to start over, and when you do, use the tools you know best.
Wrong is evil and must be defeated. - Jeff Ello
Planned to start later this year. Yes, implementation is a bigger problem than DevExpress. But let's just say I am not impressed with libraries that use catch {} (hours of my life I will not get back), nor am I impressed with ORMs that defaults to deferred deletion so in-experienced developers start using it without understanding how it is implemented (that was fun getting a large in-production database cleaned up). It does of course help the people writing the ORM at least knows how a guid is sorted by various databases... oh wait... they don't (or at least didn't on the version I looked at it).
-
Planned to start later this year. Yes, implementation is a bigger problem than DevExpress. But let's just say I am not impressed with libraries that use catch {} (hours of my life I will not get back), nor am I impressed with ORMs that defaults to deferred deletion so in-experienced developers start using it without understanding how it is implemented (that was fun getting a large in-production database cleaned up). It does of course help the people writing the ORM at least knows how a guid is sorted by various databases... oh wait... they don't (or at least didn't on the version I looked at it).
Never knew there was more than one way to sort a GUID. :omg: Googled it. :wtf:
Wrong is evil and must be defeated. - Jeff Ello
-
Never knew there was more than one way to sort a GUID. :omg: Googled it. :wtf:
Wrong is evil and must be defeated. - Jeff Ello
Wow! I had the same revelation. Actually it never occurred to me to sort GUIDs. In my mind they were the epitome of randomly assigned, meaningless numbers. Why sort them? :confused:
Mircea
-
Wow! I had the same revelation. Actually it never occurred to me to sort GUIDs. In my mind they were the epitome of randomly assigned, meaningless numbers. Why sort them? :confused:
Mircea
They are generated sequential because random data is horrible for efficient indexes in large databases. Earlier versions of guids where constructed with the mac address + timestamp + a random component. Due to security concerns of leaking mac addresses (real or not) and the increase of software generated mac addresses this was changed. But some databases do - for compatibility reasons - keep the ordering based on the bytes that used to contain the timestamp.
-
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
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.
-
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 haven't had any reporting needs for years now, but back when, I grew so tired of Crystal Reports that I converted everything I could and used this one instead: Perpetuum Soft Report Sharp-Shooter[^] As far as I recall, it was much easier to work with than Crystal...
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
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
For most of my 23 years programming, I've used Seagate/Crystal Reports/Crystal Decisions/Business Objects for reports in both desktop and web development. Lately, we have switched over to DevExpress which I really like. No ORMs for either one, just feed them a datatable, parameters, and formula fields. I'll also use straight up HTML for reports when the paging is somewhat predictable. :)
"Go forth into the source" - Neal Morse "Hope is contagious"
-
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
The only reason I would use a reporting tool is to simplify my code. Giving "users" access to the database is a support nightmare..... Oh, wait. I'm a consultant and paid for support - never mind ;)
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.
-
They are generated sequential because random data is horrible for efficient indexes in large databases. Earlier versions of guids where constructed with the mac address + timestamp + a random component. Due to security concerns of leaking mac addresses (real or not) and the increase of software generated mac addresses this was changed. But some databases do - for compatibility reasons - keep the ordering based on the bytes that used to contain the timestamp.
I think my logic and database logic are slightly different. Good thing we don't meet very often :D If you need "sequential GUIDs" why not just use a counter? Peano's Axioms basically say: if you've got enough bits, I've got enough numbers. If you want to make them unique over a number of different computers just add a computer GUID. In essence that's what version 1 and version 2 GUIDs do, except that they use a supposedly unique MAC address. Now I'll go my merry way trying to keep away from databases as much as I can :)
Mircea
-
I think my logic and database logic are slightly different. Good thing we don't meet very often :D If you need "sequential GUIDs" why not just use a counter? Peano's Axioms basically say: if you've got enough bits, I've got enough numbers. If you want to make them unique over a number of different computers just add a computer GUID. In essence that's what version 1 and version 2 GUIDs do, except that they use a supposedly unique MAC address. Now I'll go my merry way trying to keep away from databases as much as I can :)
Mircea
I inherited the project designed this way. One of the reasons given was a request to be able to clone the database and update it in different locations (no, the whole world does not yet have internet), but obviously that was never realized - and the problems that would need to be solved to support data merge are so huge that dealing with integer ids at the same time is not exactly making it a lot worse. X| The projects where I was responsible for the initial data design use integer ids - though if there is a specific use case that is served by using a guid as primary key in a low volume table I will of course do it. Typically anything above the data layer I simply lie and claim the ID is a string (or a struct of some kind) no matter what it is in the database. I do not want a UI to break because of something as trivial as changing primary key format in a table. Sure, gives a bit more conversion, but nothing that compares to the time spend waiting for data from the database.
