Problem with Package Build after applying latest planner ESU JD17626

We have recently applied the latest planner ESU, JD17626. After applying it to one of our environments, we are encountering an error building an server update package.
We have tracked the error down to the fact that business function N96721 (which is part of the ESU) is set to both client and server. Looking at OBJ7333.F9860 we can see that SIBFLOCN is set to 2.
On another site (which also has JD17626 applied) this business function is client only, SIBFLOCN=1, this is the value JDE seem to think it should be set to.
The ESU seems to have been installed correctly, and affected objects shows an newish update date (9/6/02) for N96721, so I am wondering how this has come about.
Can anyone with previous planner ESU installed (JD14380 I think) confirm that this was set to client and server (in which case the ESU failed to update it)?
If not I guess I have to work out what has corrupted this value.
Any ideas welcome

Futher to this we have just checked the F9860 tables in JD1726.mdb and jdeb7.mdb for record N6721.
SIBFLOCN is set to 1 in JD1726.mdb, but 2 in jdeb7.mdb, ie it seems the jdeb7.mdb has not been updated.

My latest Planner ESU is JD16916 both the JD16916.mdb and jdb7.mdb for N96721 is set to 1, in the previous ESU JD14838.mdb for N96721 is was set to 2. So I think it got changed with JD16916.

More info on this... Between installing the planner ESU on one environment and the next, we applied XU6. Our best guess is that of the newer updates for F9860 in jdeb7.mdb were overwritten by older records in XU6. I am surprised at this but this is our best guess currently. We are currently trying to reproduce on test system.

Re: Problem with Package Build after applying latest planner ESU JD17626 - Help still needed

We uninstalled JD17626 and XU6. I ensured that there were no entries for either in the registry, and changed the UpdateLevel in the registry from 6 to 4.
We then installed JD17626 and then XU6. The following was observed:
After installing JD17626 and applied to our prototype environment, the record in F9860 with SIOBNM=”N96721” was dated (SIUPMJ=) 10/03/02 with location (SIBFLOCN=) 1. This was observed in both OBJ7333 and jdeb7.mdb.
We then installed XU6 and applied it to our prototype environment.
The N96721 record in jdeb7.mdb was dated 4/9/01 with location 2. The record in OBJ7333 was dated 10/03/02 with location 1.
I did not think this was the way that the object librarian merge was supposed to work – I though it only replaced the old records in jdeb7.mdb. I am concerned that if we now apply the planner ESU to any other environments we will get the old record in OBJ7333 as happened before.
We have tried to reproduce this on our test system but the object librarian merge worked as expected, so I guess that it is something to do with our set-up.

Re: Problem with Package Build after applying latest planner ESU JD17626 - JDE\'s response

This is an email I got from JDE on the situation:

QUOTE
When applying a ESU or ASU, the F9860 and F9861 will be copied from the ESU.mdb regardless whether it is newer or older than your existing objects.
Whether it will be merged or not, it will depend on your Net Change table F9672.

In your current situation, it involved ASU/ESU application and the objects might have overlapping. We do not recommend to apply ASU/ESU to a pathcode as per you stated.
The recommended procedure is to apply Planner ESU to all environment then apply the ASU that is the Update 6.
This will take care of the overlapping of objects situation.
UNQUOTE

I did not understand this, asked for, and received the following "clarification":

QUOTE
For ESU, it should not have the same objects exist in two different ESUs which are currently available.
In this case, the sequence of applying ESU should not matter because no object will be overlapping.
But we still recommend to apply a single ESU, test it and then apply it to all environment before apply another different ESU.

If the recommendation procedure have been followed, there should not have any issue when you apply ASU.
ESU and ASU might have the same objects to be merged or replaced, it will handle by the Software Update engine and based on your Net Change Table.
UNQUOTE

Can anybody translate, clarify or confirm?