• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

N/A E1 Tool Release 9.2.5.0 GA was on 11/04/2020

ice_cube210

VIP Member
A lot of you might have seen this at InFocus but here are some new CNC friendly :) features to look forward to in tools 9.2.5

Virtual Batch Queues and Batch Job Resubmission
OMW from the Web Client
Package Build from the Web Client
Simplified Development Client
- (Local Oracle DB removed)
- Portable development (move from work station to work station for non BSFN objects)
 

craig_welton

Legendary Poster
Are there any details of the "Development Client Simplification" in the 9.2.5.0 announcement? Removing the local database is all I can see. So where does an object go when you check it out and make changes?
 

ice_cube210

VIP Member
Are there any details of the "Development Client Simplification" in the 9.2.5.0 announcement? Removing the local database is all I can see. So where does an object go when you check it out and make changes?
There are a new set of User Spec Repository (USR) Tables that will reside in the Central Objects Datasource. The Key on these tables will be USER ID, so each user will have their own spec records. There might be some sort of temp folder and physical footprint on the actual Development Client while you are working with the various Development Tools (FDA , RDA etc), but it will save changes back to the USR. When you do a check-in it will move from the USR to the CO Tables. Will have more details once we test this out.
 

craig_welton

Legendary Poster
There are a new set of User Spec Repository (USR) Tables that will reside in the Central Objects Datasource. The Key on these tables will be USER ID, so each user will have their own spec records. There might be some sort of temp folder and physical footprint on the actual Development Client while you are working with the various Development Tools (FDA , RDA etc), but it will save changes back to the USR. When you do a check-in it will move from the USR to the CO Tables. Will have more details once we test this out.
Thanks! Any place you found documentation for that?
 

ice_cube210

VIP Member
Thanks! Any place you found documentation for that?
Hi Craig, no published documentation yet, just from the virtual Infocus sessions I attended. If you have a quest membership you should be able to listen to the session replay. I think the official documentation should make its way to learnjde soon.
 
We tried to upgrade our JDE 9.2.2.6 instance to 9.2.5.0 yesterday. But got stuck after just updating the SM console and agents.

Deployment Server instance is stopped and didn't came up.
WARNING: Failed to start service 'JDE B9 Client Network' for instance 'DeploymentServer'.

Apparently there would be new service on DEP server in 9.2.5.0 "JDE B9 Client Network" which allows the Enterprise Server package to send messages to the Deployment Server to build the client package and send logs.
 

craig_welton

Legendary Poster
Yeah, this works like you described. When you request specs for an object, it looks first at the F987*US tables for the user. If they don't exist it pulls from the regular CO table.
 

BOster

Legendary Poster
There are a new set of User Spec Repository (USR) Tables that will reside in the Central Objects Datasource. The Key on these tables will be USER ID, so each user will have their own spec records. There might be some sort of temp folder and physical footprint on the actual Development Client while you are working with the various Development Tools (FDA , RDA etc), but it will save changes back to the USR. When you do a check-in it will move from the USR to the CO Tables. Will have more details once we test this out.
What if a Developer uses multiple development PCs? I would hope the key would be USER ID/Host.
 

craig_welton

Legendary Poster
Hi Brian,

It should only be one user/workstation at a time, since it's basically a check out. My concern is the serialized objects. If they don't exist locally, the developer's changes would be shared with others as he/she works.

Craig
 

BOster

Legendary Poster
Hi Brian,

It should only be one user/workstation at a time, since it's basically a check out. My concern is the serialized objects. If they don't exist locally, the developer's changes would be shared with others as he/she works.

Craig
I guess I will need to see it in action. Got to thinking after I posted that NOT having workstation/host as part of the key is probably the intent. I can move among multiple workstations and always have my current work in process on which ever workstation I use. I would hope that would be the only change and that otherwise it would work just like it does today, i.e. that users only see changes when those changes are checked in.
 
Top