I’m curious what the scope of things you can do with direct SQL access that you cannot do with the Db object in BPM/Function?
It’s definitely not as straightforward as writing an update/add query, but what is technically blocked?
6 Likes
- Queries on the fly in SSMS, including ability to update data if needed without having the overhead of writing an entire function
- Create and schedule stored procedures
- Create views
- Link up the data (view and stored procedures) to power bi and other BI or reporting platforms
- Create SSRS reports outside of the Epicor ecosystem
To name a few.
10 Likes
One of the primary reasons we selected Epicor in 2019 was because we were told Epicor would continue on prem products well into the future with no plans to sunset it and that it would be supported alongside the cloud product. Looks like that has now changed. ITAR / DFARS / and NIST, CMMC are all important in this avenue. Currently there are no Epicor products certified as FedRamp in the FedRamp marketplace. To comply with CMMC that is going to be important.
Additionally, we have many of our own integrations, custom code blocks, external databases, bartender labeling, etc. that will all need to be retooled.
4 Likes
As of right now, you’re right. Access really isn’t the problem. It’s mostly data ransom and upgrade timing control that’s the real problem. Yes, you can argue speed/convenience, but that’s really a poor excuse. @klincecum does some amazing thing and runs in the cloud. So you can’t say that you can’t do advanced things in the cloud.
4 Likes
For us it’s quick queries in SSMS that would take forever to build in a BAQ. It’s not about write access to the dB.
9 Likes
For my use cases / environment it’s not so much about technical blocking as it is using the best tool for the job. I have (read only) integrations that CHURN through a boatload of data and they can run in milliseconds on SQL server with stored procs, etc., and sure I can rewrite them to bubble everything up through the application layer but now it takes minutes to run and can slow the app server when the whole thing is really just a complex series of SQL queries with temp tables all over the place.
EDA (and I believe Grow as well) is also using DB scripts to run the heavy duty queries on the SQL server, it’s not bubbling everything up through the application. That is how I’d prefer to keep the data intensive stuff.
8 Likes
This is why I wrote a LINQ-on-the-fly dashboard, for the ability to write a query on the fly. (works great!)
12 Likes
Performance issues seem a valid concern. Db object is a heck of a lot slower than SQL.
7 Likes
For me its the fact that I have to deal with support. When you do Advance things, you need to attach a debugger sometimes to the IIS process, or completely enable Verbose logging.
We have chased an MRP bug for months once with Raj Tapde, Erik, and I had to install software on the server that pinpointed deadlocks to the millisecond, and show everything else that changed registry, files, disk spins etc… All that data was crucial fixing MRP bugs. (It had to do with disk i/o and Epicors SQL indexes, so they had to adjust fill factors for UD tables). Figuring this out without me pushing them and me doing all the analysis, they would still to this day claim “Its your bug”. Too bad Erik is no longer with us, that dude was sharp.
Among other things. It’s just having access to verbose logging, and other things without having to put in a ticket all the time.
I only want to go to support when I have a bug, that I think is their bug. Until then I want to pinpoint that its not me, myself, at an instant notice… If I have to wait 24 hours for them to give me the OS Event Viewer Logs, because Epicor Logs dont always show everything, that doesn’t help.
There are times where we need to even install an IIS proxy to sniff the traffic inbound/outbound to determine whats happening.
Custom Assemblies.
It helps understand the system, for example:
When Epicor RDD sends data to the SSRS Temp DB, using SQL Tracing revealed issues, and also helped us understand how it works in-depth, Epicor wont ever teach you this… They dont even know… I have emails from Epicor Employees that worked on the ICE Framework, asking me how to fix something, wtf.
Especially now that @Rich @Bart_Elia and others are no longer at Epicor, and more are retiring – your interns need to learn 10 years to really understand Epicor.
If you want my support for full SaaS, bring back Bart, Rich, Dmitry, sad, do not bring back Wilby, and have them make a we will work until we die commitment. Todd Cash better not retire, who is to say that Brian Connor wont leave, does he have a 20yr contract? Again, we end up dealing with ping-pong tickets for hours, Webex after Webex. Do you have an insurance policy on Patrick, his key strokes are worth alot. 
Tim is retiring soon, who knows.
Ill just say this, we have been here while your C-Suite has changed 10+ people. C-Suite and PMs (cant even count) come and go, we have been here since 2010+ and we have to live with the decisions of Executives, who are using Epicor sometimes just as a career stepping stone, to go to the next company and double their salary, personally I dont care what the C-Suite wants, in 5 years that whole C-Suite will be replaced by new people, and we suffer [Where is Lawrence, Edge, Himanshu etc… changing execs like socks, where is our 20yr tenure bonus, can we expect for being loyal not to pay Maintenance this year?]
If a Support ticket, takes more than 30 minutes, I will bill Epicor in addition I will just find personal phone numbers for @pferrington @bconner etc and call them at home @JeffLeBert already has a restraining order on me, cant call him anymore at 11:30 pm
There is some sarcasm here, but tldr; we must have rock solid support.
19 Likes
Clear answers without a “Safe harbor” statement.
3 Likes
Jen, I appreciate that you took the time to respond. I want to hit on your quote above and also note that when quoting/tagging people below, I am solely doing it to be constructive. I hope you know I am an advocate for success on both sides.
Given the above, I want to provide an example of what the ability to host our own environment and stay on our own version means to a couple companies of ours. Two of our companies just changed from Vantage to Kinetic in the past 3 years. Whether Epicor believes it was “smart” to stay on a system for that long or not, they were making money using the same technology and feature set for 15+ years (or whatever the time frame was for the last release of vantage). The crazier part… they had better uptime in the last 10 years with vantage than on the first year of Kinetic SaaS.
I know we are not the same as everyone else and maybe not the customer that fits in Epicor’s “strategic rational” that you mentioned above (which I am interested to hear more about as I am sure @MikeGross and others are) but for these companies, core functionality of the ERP matters the most before any AI or other advancement and if that core functionality is not truly there from version to version, release to release, or patch to patch, the ERP system fails to meet the primary need of our companies.
Don’t get me wrong though… with the switch to Kinetic, we got some awesome improvements, like “explorer”, etc., but the fact remains, we need the core functionality to work and be resilient day in and day out, and I think nearly all of us can show you that SaaS doesn’t provide this right now, at least not in the way a stable release of vantage or 10.2 did.
To support this, I’ll quote @hkeric.wci who said the same thing, more or less: he would like to see a focus on ERP, and for him that didn’t mean Epicor Social Enterprise, EVA, or even AI yet.
Maybe we are alone in this, maybe none of your other customers work this way and none of Epicor’s market research supports this rational of what we think Epicor should focus on, but I want to speak up and share our needs which is the need for the core functionality to work day in and day out, from version to version, release to release, and patch to patch and also state that I understand if we fall outside the norm and wouldn’t blame Epicor for adopting a rational that doesn’t align with our own.
15 Likes
These two points do not agree with my experience.
- I have been writing ad-hoc queries directly against the read-only DB (RODB) in Azure Data Studio and/or VSCode (with the MSSQL extension) since the day we purchased the license (I believe we were the third customer to license it). I have used a linked server or openquery when I needed to join Epicor RODB tables to my on-prem MSSQL instance, but otherwise it’s unnecessary.
- Not sure how “big” a “big database” needs to be to start manifesting performance issues, but we’re 5 years in and I’ve had no problems with the RODB performance.
Your last three points are 100% accurate.
6 Likes
While being on the latest version (almost continuously), and being on-premise. I don’t like the message. Although it’s not a surprise to me, the entire road-map is cloud first (focused), and to be honest the same has happened to me with Microsoft Exchange/Skype for Business/SharePoint or Autodesk for example. The biggest change (in my opinion) is that Epicor is still developing the product we can run on premise for 2 more years. I don’t know how the IT landscape does look like in 2030, i don’t know if the available version of Windows (in 2030), can run the classic client. Or the browsers in 2029 still support the Kinetic UI, as it’s being developed today.
I think we need to look ahead, fix the concerns we do have. Ventilate our issues with the solutions brought up. I do trust the fact, that the future 10 years won’t be a replication of the past 10.
Regards
Jos
4 Likes
This is a great discussion – and some admittedly hilarious responses.
We are currently on-prem with ECI M1 and after 10+ years, looking at other options. Epicor being one, hence creating an account and asking how migration is from M1.
One decision that has been made is that our next ERP will be cloud-based. Why? We’re a smaller business and our managers already wear many hats. I have software development experience from my home projects and without me here, we would have lost days of productivity in the last quarter alone. Some issues as simple (to me) as remoting into our server and restarting the VM to resolve. The multi-geographical location with cloud (no more remoting into our local server) is also a major selling point.
We are still pursuing Epicor Kinetic as an option and again, fully cloud no matter what solution we choose.
7 Likes
On our end, we we’re as shocked as everyone. Feel’s like a contract has been broken between us and Epicor.
We’re on prem and classic at the moment, and 2026 is the year we were going to swith to Kinetic. This move changes our game plan. We’ve discussed the technical impact internally and here’s a subset of the list:
- We have a lot of external BAQs that pull data from SQL Views. This is very convenient because we can centralize the query logic in a single SQL View and multiple BAQs can pull the data, so it is much easier to update/maintain. SQL Views are also usefull for complex queries, as it is much easier to build and debug than BAQ. Moving to the cloud forces us to refactor all those external BAQs and SQL Views to regular BAQs. The “Reference query” feature in the Kinetic BAQ designer will be usefull. If Epicor invest in making the BAQ designer more convenient and powerfull, this switch should be manageable. Even better if Epicor comes up with a tool to help in the transition, like making Convert SQL to BAQ much much much more powerfull and flexible than it is at the moment.
- We replicate the production sql database daily for our PowerBI Queries, which pull data directly from this sql database. We don’t want to plug PowerBi directly to the prod database because that seems like a very bad practice. The fees for a replicated sql database in the cloud are way too high. We tested BAQs for PowerBi and it was a global pain in the ass when modifying the BAQ (add field, change calculated fields logic, etc). We like PowerBi, so switching to grow is inconvenient. We don’t have a solution for this, we’ll need to think a little more.
- Not entirely related to the switch to cloud, but we have a lot of complex custom dashboards and workbenches in classic. Kinetic Application studio is not stable nor robust, has very limited functionality, is difficult to debug, break down after an upgrade and slows down our development for those dashboards. This forces us to ship all the logic on the server with BAQs, functions and BPM (this is already the case and a best practice, but Kinetic forces us to double down on this even more). We’ve made the decision to create a completely independent website using Blazor in which we will create all our custom dashboards. Those “apps” will use the API to call BAQs and Epicor functions. This way, we will reduce the risk of something breaking after an upgrade and gives us all the tool we need to provide the best experience for our users. We’re interested to know if any of you guys are going a similar route.
- Accessing server logs and server tools are very usefull. We expect Epicor to provide a much more complete and robust tool set for the transition. The cloud portal is a good start but very limited. The regen data model with cloud portal is awfully slow.
- The ability to use SSMS to debug a SSRS report data definition (using archive period, get the guid, etc) will be lost and I don’t know how to achieve the same result on the cloud.
We also have a non technical concerns:
- How much more will it cost, because it will not be less obviously. And that is my biggest problem here let’s be clear, that pisses me off so bad. Epicor, you guys are following this thread, so please note the following : I expect to be wined and dined before getting f******.
- The 2025.2 update was a disater. Lot a client and server side features broke down. We’ve read the threads here and Epicor support was a mess. We are very anxious about this situation.
We are not looking to change ERP, but we expect Epicor to step up their game if they want us to comply in a positive and constructive way to this forced switch to the cloud
16 Likes
Less useful than you think. Its limited to 10k records in the reference.
8 Likes
Well said Utah, and I doubt you’re alone in that. In fact, we feel the same, the core ERP needs to be solid and it’s not currently. More focus should be on that than chasing fads cough PRISM AI cough.
10 Likes
That doesn’t work as a reporting data source though?
As far as size, how many millions of records do you have in part tran? Or tran glc?
4 Likes
Less useful than you think. Its limited to 10k records in the reference.
Jesus Christ
5 Likes
Ours have millions upon millions. It shouldn’t be that big of a deal if your indexes are set up properly.
2 Likes