Is Your EnterpriseOne SQL Database Version Current and Supported?

Underlying every EnterpriseOne system is a database.  Technically a Relational Database Management System (RDBMS), most simply refer to it as 'the database'.  The database sitting under E1 is either Microsoft SQL Server, Oracle database, or IBM DB2 and just as EnterpriseOne must be kept up to date, so too must the database software.

Oracle's Minimum Technical Requirements (MTR's) specify certain versions and editions for EnterpriseOne databases.  Oracle's support (or lack of support) for a version is driven by their policy on 3rd party software which states: "The general JD Edwards EnterpriseOne support policy is to withdraw support for a platform component when the vendor withdraws its primary or mainstream support." (EnterpriseOne Statement of Direction).  This means that when Microsoft stops supporting a certain version of SQL Server in its Mainstream Support, Oracle may stop supporting that version for EnterpriseOne...and most likely will.

Information about Microsoft's current (and importantly, future) support levels for all SQL Server versions and editions can be found in the Microsoft Product Lifecycle Search.  For example, you can see in the results table that support for SQL 2000 ended in April 2008 as did support for SQL 2005 SP1.  Consequently, Oracle no longer supports those database versions for EnterpriseOne.  Also you may notice that Microsoft no longer offers Mainstream Support for SQL Server 2005.  This means that Oracle's support for SQL 2005 as an EnterpriseOne database is at an end.

Support for SQL 2008 SP1 will end in October 2011.

As of early October 2011, the only SQL Server database version that will be supported for EnterpriseOne is SQL 2008 SP2 (and 2008 R2).


To find out if you are on a version of SQL Server that is supported, first determine your exact SQL Server version and edition by running the following SQL script:


--SQL Script Begin
SELECT SERVERPROPERTY('productversion') AS "Version Number",
SERVERPROPERTY ('productlevel') AS "Product Level",
SERVERPROPERTY ('edition') AS Edition
--SQL Script End


The results should look something like this:

Version Number	Product Level	Edition
10.0.2789.0	SP1	Standard Edition (64-bit)

The version number correlation is as follows:

7.00 = SQL Server 7.0
8.00 = SQL Server 2000
9.00 = SQL Server 2005
10.00 = SQL Server 2008
10.50 = SQL Server 2008 R2

To find the exact version from the version number you can look in the SQL Server Version Database.  Once you know the exact version, use Oracle's Minimum Technical Requirements then the Microsoft Product Lifecycle Search to determine Microsoft's future support end dates.

If your SQL Server version is lower than SQL 2008, you are not currently supported by Oracle with EnterpriseOne.  Lower than SQL 2008 SP2 and you will not be supported come October.

The fact is that it's time to move to SQL Server 2008 R2 to ensure support for your EnterpriseOne system.  Besides simply ensuring support from Oracle, it is best to improve your system stability and performance by utilizing the most current code possible.  Microsoft is continually updating bugs and adding features to SQL Server and every new version is faster than the old one.

The Karamazov Group offers a complete SQL Server upgrade package, including project planning, project management and a minimal downtime cutover.  We have over 11 years of EnterpriseOne SQL Server expertise and have already completed multiple flawless SQL Server upgrades.  Contact us to discuss your SQL Server Upgrade.

Oracle to De-Support Windows 2003 in August 2010

The statement from Oracle is: "Oracle plans to withdraw support for Windows Server 2003 and Windows Server 2003 R2 effective July 13, 2010. JDE E1 8.98.3 is the last supported tools release with Windows Server 2003 and Windows Server 2003 R2."

This will probably come as a surprise to more than a few Windows shops since W2K3 is still seen as a mainstay of their operations and many organizations had no intention of changing that...until now. 

Microsoft still supports Windows 2003 in extended support, but this means a different thing to Oracle.  For Microsoft, moving a product into extended support simply means that you don't get no-charge incident support, there will be no more design changes nor new features and no more warranty claims.  To Oracle though, the movement of Windows Server 2003 out of mainstream support is cause to withdraw platform support, which apparently means that they may choose not to support your ERP system if it is running on that platform.

Oracle says in their EnterpriseOne Statement of Direction: "The general JD Edwards EnterpriseOne support policy is to withdraw support for a platform component when the vendor withdraws its primary or mainstream support." 

Global Support's statement on the issue is this: "Oracle Global Software Support will still attempt to assist customers running any version of E1 software, even though a customer may be on an older  release of the software, or on an older platform that does not meet our current MTRs, so long as the E1 installation was at the time (even if it is not now) compliant with our MTR certifications."

This is reassuring in that Oracle is not going to completely abandon customers that do not meet current MTR's as long as the EnterpriseOne system was MTR-compliant at one time.

The caveat they offer for withdrawn support is very similar to their support statement concerning virtual machines: "We will try to troubleshoot the issue from the E1 side and verify that the software is configured correctly, but if it gets to the point at which troubleshooting from the E1 side does not resolve the issue, and we cannot reproduce it on a comparable installation which meets our current certifications, then we may need to close an SR with an action plan that you need to upgrade to a currently certified platform for us to continue troubleshooting, if we need to go to Oracle Development."

This means that they will attempt to troubleshoot the item from an E1 perspective while assuming that you are running on an MTR-compliant system.  If they cannot find the issue to be E1-related they will require to you to move to a system that is MTR-compliant in order to move forward.  They also will require you to become compliant if you find an E1 bug and they must go to development.

I suppose that, given the alternative of no support whatsoever for a system that is not (but once was) in compliance, this is not too shabby of a deal.