Central Objects - Enterpise vs. Deployment Server

sashton

sashton

Reputable Poster
Ok,

The CNC consultant who originally installed OneWorld, put the Central Objects on the Deployment Server using SQL. Now there is talk among management that they want to move them to the Enterprise Server which is on an AS/400. Does anyone have any bias one way or the other here? One reason they want to move them is that those computers that are not on the domain, then have to have a drive mapped to the deployment server in order to connect to the COs. Also, will having a published app on Citrix having drive mapping issues by having the CO's on the deployment server?
 
These days you should always have your central objects on the enterprise server - then you'd be able to get rid of the second database.

Originally the AS/400 couldn't handle 32k blob sizes - which is a requirement for JDE - but this was overcome in V4R5

The transfer should not be difficult for experienced CNC consultants.
 
It has been my experience that when the Central Object DB is in the AS/400 that access to these (re: Package Builds) are very slow.

As Jon stated, the as400 was unable to store these until V4R5, but even then JDE still used BLOB chaining, which broke the BLOB into chunks smaller than 32k. Hence the longer build times.

With E1 8.9 and V5R2, JDE has taken advantage of native BLOBs on the AS/400. If this is your config, then I would move them to the AS/400. If you are not one 8.9, but don't care about package build times, then go ahead and move them. It does make backup and recovery easier.


Andy
 
I think you have some confusion about how the Central Objects are accessed. You will not eliminate the need for the mapped drive by moving the COs. The COs are accessed through an ODBC connection that is independent of the mapped drive.

I think the COs should reside where it makes most sense for each organization. Personally, I have my COs on the deployment server for three reasons.
1) I am more familiar with SQL.
2) The disk space is cheaper.
3) Shorter Package Build times.

There was one other thing that struck me as odd. Why does management care where the COs are? They should not be concerned about the configuration of the software as long as it does what they need it to.
 
They(Management) is looking at it on a performance basis. Are longer package build times hurting performance more than performance of having all objects on the 400?
 
Performance is a huge topic with many different areas to consider. Without knowing your specific setup, I cannot tell you if moving the Central Objects will help your performance problems. I would suspect not. In the configurations I have seen, the Central Objects are not really accessed by the end users. In my configuration, the only things that users access in Central Objects are user overrides. Developers on the other hand will use everything in Central Objects.
 
As a side note, there are two different CO connections. One connection is required to your \\Deployment\B7334 for the developers to be able to access source files. Another connection is require via ODBC to access the spec files. The only situation where you would require a network map for non-developers would be if your ODBC protocol is set to Named-Pipes. The correct protocol of TCPIP-Sockets would not require the drive mapping authentication.
 
Back
Top