Hi guys, does anyone know if SQL Server 2019 is “certified” by Epicor to run with 10.2.400?
We are planning to upgrade our SQL platform from 2008R2 and need to decide whether to go with the 2017 or 2019 release.
Thanks in advance!
Hi guys, does anyone know if SQL Server 2019 is “certified” by Epicor to run with 10.2.400?
We are planning to upgrade our SQL platform from 2008R2 and need to decide whether to go with the 2017 or 2019 release.
Thanks in advance!
It is not. Server 2019 is supported but not SQL Server 2019.
Same specs in 10.2.500 install guide. no SQL2019 yet…
Thanks for the feedback guys, I appreciate the input!
It was only released 4th November 2019 so we would not retrospectively certify for previous versions. It will be part of 10.2.600 regression testing processes and we do not expect any issues with prior versions using SQL 2019.
We use 2019 to test BPM/BAQ in different versions of ERP (AFAIR starting with 10.2.200).
No DB-related issues found.
Good to hear Sergey, thanks for letting us know. We have decided to move forward with the 2017 version but I’m still keeping an eye on SQL 2019 for the near future.
Cheers!
Jaime, don’t miss that we don’t test product as a whole, so it is hard to say that there are no issues at all. But in the tested areas we have no problems.
I wouldn’t run my ERP on a SQL version that’s not fully supported by Epicor. I’m sure E10 would run fine on SQL Server 2019. But I wouldn’t recommend it until it’s officially supported by Epicor. Going with 2017 was a good choice IMO.
I was told by an Epicor Tech that as long as the DB version is kept at 2017 (or appropriate supported version), then that is fine.
That’s a good point Mark, you can always downgrade the Compatibility level to whatever older version is needed - thank you!
Might we get confirmation from @Edge or @aidacra ?? because this would be really nice to know for sure.
My opinion is this. Whilst you can run the database in compatibility mode, if it does not explicitly state that in the implementation or certification documentation that you can run the database in compatibility mode, I would not do it (at least not in a production environment).
A good example some of the subtleties of versions is the introduction of the TRIM function in SQL 2016. Clicking on the TRIM() string function in a calculated field in a BAQ returns the following SQL ltrim(rtrim()). So whilst you perhaps might get some better performance out of the database engine you won’t get any benefit from any coding enhancements baked into the later version of SQL. To that point I’ve never tested if you could perform the TRIM function on a database running in pre 2016 mode.
The joys of developing and maintaining for multiple environment configurations. To be honest, I still scratch my head at the effort that would have been needed to maintain E9! I applaud Epicor for sticking to their guns with regards to certified environments.
From an Administrative standpoint. A lot of us like the new and shiny (I know I do). When it comes to the software that you run your business on, stick to the rules that the vendor supports. Just because you can, doesn’t mean you should. If it’s a new install then go for the latest to future proof yourself, and remember SQL versions have pretty long end of life dates. Checking for SQL 2017 it’s October 2027! Who knows what the Epicor certification will look like then (VR, Cloud, AI, ML, and 100% shop floor automation!)
I’m with you @Hally, believe me. Been doing SQL a long time (I recall the TRIM() issue very well) and never am I out of spec on a production system. I know a lot of new functions are added and we all want them, but out of spec is a black hole as far as I’m concerned.
I was really just looking for a definitive ‘ruling’ on the subject from Epicor. I get a lot of knowledge from tech support over the years (and I trust @markdamen implicity) but as you’ve said, does not sound like good advice.
It would be nice to have the documentation to be a bit more explicit around the issue of the use of “Compatibility Mode”.
I can see the argument for wanting to use SQL 2019 when a purchasing decision is involved.
I’m happy to reach out to the Epicor UK Tech who gave that advice, and see if he’s willing to put his name to it
I think I actually heard him say it during a break out session at an EUG UK event, and spoke to him after to confirm.