Carl_Fisher
Well Known Member
RE: ESU installation Generated package Definition incomplete
The Package created by an ESU should include all the Objects which were
Updated - look at the Merge Report generated by the ESU. This may not be all
the Objects listed under the ESU, for a number of reasons.
1) This is an updated ESU - and you have applied an earlier ESU for the same
Objects, or you have applied Update 1 or Update 2. In these cases, as an ESU
is cumulative it will check Object Modified dates and Only update the
Objects which have changed, so a subset of all the Objects affected by the
ESU. This is fine and should mean that the ESU is correct.
2) You have modified objects your self - again the Modified date will be
later and the ESU will assume that an Update is not required, This can cause
problems - do you want to keep your changes? If you do copy the object then
SQL the OL F9861 to set the Modified date back on the JDE object, load the
ESU - it will update the Object, then look at your copy and reapply your
custom changes. If you do not need your changes and want the latest JDE
Object, just SQL F9861.
Obviously there is the other reason that the ESU has failed to Build
properly, check the Merge reports carefully and look at any logs produced by
the ESU.
We too have had major problems De-ESUing (restoring a backed up ESU). We do
not seem to be able to run the Backup let alone the Restore. We have found
the only way to remove an ESU is to take each object modified by the ESU and
promote it via the OMW from Pristine to the required environment. To do this
you need to fix the Modified date on the To environment (otherwise the
transfer will not happen - you cannot overwirte a New object with an Older
in OMW). that set back the ESU and allows it to be reapplied (or a 'fixed'
replacement) later.
Your Spec merge problems may be caused by Modified dates in OMW being wrong,
we have found that after backing out an ESU, when you reapply some objects
still appear as if modified and do not update, this gives a mix of objects
at different levels and is chaos.
If by your Pristine+ESU then copy, you aim to partially apply the ESU,
DON'T, see other posts on this Forum, this is totally unsupported by JDE,
and never to be recommended, potential disaster lies down that road.
OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
The Package created by an ESU should include all the Objects which were
Updated - look at the Merge Report generated by the ESU. This may not be all
the Objects listed under the ESU, for a number of reasons.
1) This is an updated ESU - and you have applied an earlier ESU for the same
Objects, or you have applied Update 1 or Update 2. In these cases, as an ESU
is cumulative it will check Object Modified dates and Only update the
Objects which have changed, so a subset of all the Objects affected by the
ESU. This is fine and should mean that the ESU is correct.
2) You have modified objects your self - again the Modified date will be
later and the ESU will assume that an Update is not required, This can cause
problems - do you want to keep your changes? If you do copy the object then
SQL the OL F9861 to set the Modified date back on the JDE object, load the
ESU - it will update the Object, then look at your copy and reapply your
custom changes. If you do not need your changes and want the latest JDE
Object, just SQL F9861.
Obviously there is the other reason that the ESU has failed to Build
properly, check the Merge reports carefully and look at any logs produced by
the ESU.
We too have had major problems De-ESUing (restoring a backed up ESU). We do
not seem to be able to run the Backup let alone the Restore. We have found
the only way to remove an ESU is to take each object modified by the ESU and
promote it via the OMW from Pristine to the required environment. To do this
you need to fix the Modified date on the To environment (otherwise the
transfer will not happen - you cannot overwirte a New object with an Older
in OMW). that set back the ESU and allows it to be reapplied (or a 'fixed'
replacement) later.
Your Spec merge problems may be caused by Modified dates in OMW being wrong,
we have found that after backing out an ESU, when you reapply some objects
still appear as if modified and do not update, this gives a mix of objects
at different levels and is chaos.
If by your Pristine+ESU then copy, you aim to partially apply the ESU,
DON'T, see other posts on this Forum, this is totally unsupported by JDE,
and never to be recommended, potential disaster lies down that road.
OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
