The Future of Microsoft SQL Server Express with EnterpriseOne....

altquark

altquark

Legendary Poster
...there isn't any.

Thats the official line from Oracle now.

After moving from Microsoft Access files for a local database type to MSDE and finally a choice between Microsoft SQL Server Express and Oracle Express, Oracle has been steadily phasing out SQL Server Express support in favor for Oracle Express Edition.

We questioned Oracle on the fact that SQL Server Express 2005 was the only MTR for EnterpriseOne 8.98.4.3 - yet SSE 2005 requires .NET 2.x, which has been phased out of support in favor of .Net 3 and 3.5. In a specific VDI environment - the use of SSE 2005 causes issues with the .NET setup. When we asked Oracle about SSE 2008 support, of course we got the "it'll never be supported. ever" line.

Yup - according to GSS, the next tools release will not even have SSE support in it :
[ QUOTE ]

Regarding SQL Server 2008 Express, it is NOT supported for Client and Deployment machines, as it is not in Client/Deployment server MTRs document.

You can also take a look at the Statement of Direction document (Note 749393.1), which contains the software supported by current releases of E1 and also indicates Oracle's plans for adopting platform components in future releases.


[/ QUOTE ]
when you look at the document 749393.1, you will see the following note under "Planned Withdrawals" :
[ QUOTE ]

Microsoft SQL Server 2005 Express as the local
database for deployment server and development
client. Future releases will use only Oracle
Database for the local database.


[/ QUOTE ]

So, start moving to Oracle Express Edition as soon as possible. Given the fact that the latest E1 Standalone uses Oracle Universal Installer to install everything (you install the Oracle Express database first, then the E1 client) - it makes perfect sense that theres no room for SSE anymore. But its probably a rude awakening for a lot of installs out there

I for one am quite glad that Oracle is standardizing on a single "local" database platform.

This has, of course, no affect on the Database Server support direction (SQL Server 2008 is and will continue to be supported).

But it does show that Oracle is continuing to push THEIR tools wherever possible.
 
How cool it would be if the Deployment Server will be available on Linux. Then JDE will be all ORACLE stack. DB,OS, Application server and clients. Though I do not think it will available soon.

Dan.
 
[ QUOTE ]
How cool it would be if the Deployment Server will be available on Linux. Then JDE will be all ORACLE stack. DB,OS, Application server and clients. Though I do not think it will available soon.

Dan.

[/ QUOTE ]

They're working on that.
 
Hi,

Deployment running on Linux = FAT clients running on Linux.

FAT Client (and Deployment) heavily relies on MS
Windows APIs and components, so its code should
be rewritten from scratch to run natively on Linux.

I don't think we'll see a Linux FAT client or
Deployment Server in the short term.

On the other hand, I think that Oracle's priority
should be to free JDE Web users from IE dependency
by rewriting its infamous ActiveX components in Java.
 
[ QUOTE ]
Hi,

Deployment running on Linux = FAT clients running on Linux.

FAT Client (and Deployment) heavily relies on MS
Windows APIs and components, so its code should
be rewritten from scratch to run natively on Linux.

I don't think we'll see a Linux FAT client or
Deployment Server in the short term.

On the other hand, I think that Oracle's priority
should be to free JDE Web users from IE dependency
by rewriting its infamous ActiveX components in Java.

[/ QUOTE ]

The Deployment Server is basically a file server that also runs a fat client.

Trust me, they're working on it.
 
Hi,

In that case, I'd be very interested in testing a Linux
Deployment server.
Would you know, please, what distribution they chose?
Thanks for the information
 
[ QUOTE ]
[ QUOTE ]
How cool it would be if the Deployment Server will be available on Linux. Then JDE will be all ORACLE stack. DB,OS, Application server and clients. Though I do not think it will available soon.

Dan.

[/ QUOTE ]

They're working on that.

[/ QUOTE ]

They've been working on that for frikkin years. In the meantime, if you really want your deployment server on Linux, install SAMBA, create a file share, and copy everything from a windows fileshare over to the samba ! Presto - "deployment server" running on Linux !

The planner and workbench MIGHT be convertible to run entirely in HTML - theoretically any of the JDE tools (package build, user ID etc etc) could run on a JAS server. I'm sure thats the piece they're trying to get working. Get that working, and no more windows....!
 
[ QUOTE ]
theoretically any of the JDE tools (package build, user ID etc etc) could run on a JAS server.

[/ QUOTE ]

I'm not sure you could run FDA and RDA in a non-fat client environment and also keep the WYSIWYG functionality. Not saying the fat client has to be windows, but I don't see those 2 tools running in HTML.
 
I've been waiting for Java versions of the design tools. Anyone know if that is in the works?

To Jeremy's point, that is required if you want to break the Windows requirement.

Craig
 
[ QUOTE ]
They've been working on that for frikkin years. In the meantime, if you really want your deployment server on Linux, install SAMBA, create a file share, and copy everything from a windows fileshare over to the samba ! Presto - "deployment server" running on Linux !


The planner and workbench MIGHT be convertible to run entirely in HTML - theoretically any of the JDE tools (package build, user ID etc etc) could run on a JAS server. I'm sure thats the piece they're trying to get working. Get that working, and no more windows....!

[/ QUOTE ]

I theory. But you still need the deployment server to do the initial install. And like Jeremy and Craig mentioned FDA and RDA are Windows only. So we are quite stuck for now
frown.gif


Dan.
 
[ QUOTE ]
I've been waiting for Java versions of the design tools. Anyone know if that is in the works?

[/ QUOTE ]

The Java Client was actually a client that worked up until about 2003/4 or so, when JDE completely removed it. I liked the Java Client - it worked really well, but it was just as chatty as the windows client, so Development killed it. That would have been the right client to have developed into the toolset.

I don't think theres really an issue with the requirement of using Windows for the little amount its used for. The deployment server is not mission-critical (unless you configure it incorrectly), and the developers need Microsoft windows anyway to develop with.

I would like to see JDE become completely autonomous from microsoft - it'd be awesome to see JDE developers sitting on macs, for example, but the reality is that its not really likely - wheres the profit ? Wheres the business justification ?
 
Back
Top