when subreports come into play man and when subreport have their own groups and span 1+ pages that’s when it gets nasty.
You are not alone! I like it as well. I agree we are overdue for something better, but I do like it.
One of my self applied rules is, if it actually needs a subreport then SSRS is the wrong solution. Much of the trouble I see people having with SSRS comes from trying to do too much in what is effectively fancy Bartender. They’re both good enough solutions for fixed size printed documents (…all paginated reporting solutions being awful in their own special way). As soon as poorly constrained dynamic elements or graphs show up, it’s time to start questioning one’s life choices.
We are on Kinetic Epicor. We are in the middle of implementing. I am getting ready to start reports. All my programmers are Crystal report experts. Is there a way to connect Crystal Reports to the Azure Kinetic Cloud Database right into Crystal?
Even when Epicor did use Crystal Reports, they never connected to the database.
The Report Style/Report Data Definition combo drops out an XML file and then the Crystal Report runs against the XML file as a data source.
Edit: And while you technically CAN still do this, the real question is SHOULD you. It’s a barely supported, use at your own risk option and you’d be using reports that are probably 10+years old since they’re basically E9 reports.
Are you talking about Crystal or SSRS?
(I’m joking… I don’t know squat about any reporting, so ignore my banter…)
My opinion is that if it ain’t broken, don’t try to fix it… SSRS has been more or less “abandoned” by Microsoft for years now, for the simple reason that it just works. SSRS is a fine reporting platform… Epicor’s stock SSRS reports are the problem, not the platform… Most stock reports are packed up to the gills with decades of garbage, which is what makes them unwieldy.
Besides, given their existing investments with Kinetic, I’m pretty sure the first solution they would consider would be Telerik Reporting. But that’'s VERY expensive, and SSRS is, well, free. So I don’t expect anything will change any time soon…
Nor do I support it either, to be honest…
And don’t get me started with Crystal… If you think SSRS is terrible, you cannot really be rooting for Crystal…
wholeheartedly disagree. Anyone who spends any time using this tool knows it doesn’t “Just Work”
It is riddled with bugs and inconsistencies and the entire tech stack it uses including its “scripting” language is long dead and abandoned.
We’ll just have to agree to disagree here
It has its quirks, but once you know them they are easy to deal with… For example, don’t use headers or footers if you don’t want to have issues with page breaks… Instead use groups that repeat on new pages…
And the scripting language is just VB.NET… Do you think Crystal’s language is better? Honestly?
I’m not saying SSRS is perfect, no tool is… But there is just nothing out there that is objectively better, or cheaper.
I believe the stock SSRS reports are some terrible conversion from Crystal Reports. I doubt Epicor had them rebuilt by hand when they forced us to go to SSRS.
Like others, we do have some quirks with pagination with sub-reports, etc that has been discussed before. So I’d support Epicor leaving SSRS as a default/included reporting tool but also integrating with others. I’d hate it to be an expensive add-on but as long as it was optional it’d let the customer decide which is best for them.
They very much built them by hand I remember the cries at the time from those poor folk that had to do it.
I will say that may be the best example of standardized design and format that I’ve ever seen from them even though usability/practicality was questionable on so many of them that were accounting related.
After messing around with 2024 today here’s my thought.
Now I’m thinking that because the reports are stored in a table then it would be feasible to have another custom report row that stored the report template for whatever REST enabled reporting tool you wanted, then a function that executed when the submit to agent is fired… Cancelling the SSRS execution and fire the other report tool and using the generated data (not totally over the sequence of events)… Effectively replacing Ssrs without really messing to much with the existing reporting process
Best of both worlds.
If we switch tools again we’ll have crystal, ssrs, vNext tool forever into eternity
What I:m thinking is vNext is just a framework to use whatever you want.
I think you will find this current change is to prepare for PowerBI. That’s my guess I am sure @bconner may have some Forward looking statement’s to make
Good ! Still don’t want to rebuild reports yet until we complete Kinetic UI upgrade but having an option in reporting tools would be great.
I am thinking that you not would have to. Keep your Ssrs then any new reports use the new. Over time you could transfer all your custom reports… Sound familiar?