Version Check-In Issue.

[DBohner-(db)]

Prior to a recent tools release... at least,... I thought....

Report Version Testing took place in PY - because DV data was so aweful.

In PY -> Open OMW -> Check out a Version -> make correction -> Check in.
The process would check the version into DV, and the projects status could be set to be included in the next build.

This process still works for PO Templates, Applications, UBEs, NERs and BSFNs... when the 'user' attempts to check in a UBE Version - we get the OMW Error 'Check-In Failed' and no real information. The OMW Logs are worthless.

From PY, Check Out (checks out from DV), edit, Check-in (checks into DV)...

Any thoughts why it works for everything other than Versions?

8.12 - Tools 8.98.13

 

[Scott Beebe]

The environment to/from which versions are checked in/out is has always been based on the logged in environment and never the project status code. If you are logged into PY, if you do a check out it is checking out the version specs from PY, not DV even if project status is 21. If you check it back in, it is checking the version specs in to PY central objects. I have never seen it operate differently.

For all other objects, the project status determines to/from which environment the specs are checked in/out.

 

[vmcdaniel]

Dan,

We had an issue with checking in of UBE versions also, in that if we were checking into an environment other than the logged in environment, the check-in failed in the same way you are describing. What we had(and I will spare you the reasons why), a parallel DV environment(call it XDV812), and the activity rules are to check in from local to both DV and XDV from local. The check-in to XDV fails due to a bug in jdeOMW.dll in TR 8.98.1.3. I have attached the one-off(for a windows fat client) that we have, and you are welcome to try it to see if it fixes your issue.

Thanks,
Vernon

 

[jeremey_garcia]

also with the latest tools release you can only have activity rules for versions check-in active on one environment. If there are more then one active the check-in will fail.

 

[vmcdaniel]

Ok...sounds like something we might have to deal with down the road. I believe Dan is on 8.98.13 like us though, and this particular version didn't have that restriction on multiple check-in env's.

 

[DBohner-(db)]

One of our CNC found a SAR/Bug on the KG.

E1: OMW: Unable to Check-In Batch Versions After Upgrading to Tools Release 8.98.1.1 [ID 850411.1]
&
Bug 8937315: Unable Check-In Batch Ver

Seems that there is a 'sorta' work around - and the issue is resolved in tools 8.98.1.4

Note - until the 'fix' is in, you have to set the activity rules to point to the Log-n environment, where the Check-In is occuring.

"As a workaround until the fix is applied, set the activity rules defined for the check-in activity to point to the path code for the log-in environment where the check-in action is occurring. The issue occurs when the activity rule is set to check-in the object to a different path code then the path code for the environment logged into when performing the check-in action.
"
(db)