Versions problem...

[swhitmire]

We're having a problem with batch versions in a custom path code we created.
When someone goes into batch versions and adds a version, the version
shows up in the list, but then can't be checked in. If they copy an
existing
version, the version doesn't show up, and in fact the F983051 record for
it can be found in PY7333 (with P37333, the name of the custom environment,
as VRENHV). Transferring a version from DV7333 to P37333 in OMW also
results in the version record appearing in PY. Does anyone know
what's causing this?

Thanks,
--Scotti Whitmire
XE SP15, AIX4.3.3, Oracle 8.1.6

 

[Zoltan_Gyimesi]

Hi Scotti,

It is a typical OMW (Object Management Workbench) and OMC (Object Management Configuration) related issue.
1.) You have to setup OMW in OMC for you new Path Code / Environment (Statuses, Status Promotions, Status and Transfer Activity Rules, etc.)
2.) You have to create new Project(s) to add versions and promote it to the appropriate status, set up previously.
3.) You have to add versions in OMW under this project (with the appropriate status) through Add/Batch Version instead of using the Batch Versions application.

You can ask why? The answer:
1.) The Batch Versions application works under the User's Default Project.
2.) Generally (shipped configuration) the Status of the the Default Project is 21.
3.) Generally (shipped configuration) the Status 21 is set up for DEV7333 Path Code / Environment, so for example the Target Location for the ChekIn action (Status Activity Rule) for UBEVER (Batch Version) is DEV7333 instead of your custom Path Code, etc.

It is pain to say but working with versions is a "bit" complicated under XE then in the earlier releases. Sorry, we are suffering from it too :-(

Zoltán



B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

 

[swhitmire]

We got the problem solved last night with help from JDE...
There's apparently a problem with how the OCM mapping for
the F983051 is looked up when using the Batch Versions
application. We had recently added a JP37333 Java
environment for the P37333 custom path code to our
system, but had accidentally not changed the OCM mapping
for the F983051, so it still pointed to Versions - PY7333.
This shouldn't have had anything to do with our problem
in the P37333 environment, but apparently the process that
allows check-in to the path code associated with the login
environment from Batch Versions finds the path code, then
looks for the first environment with that path code
and uses that environment's OCM mappings.

--Scotti Whitmire
DeRoyal Industries
Xe SP15, AIX4.3.3, Oracle 8.1.6

 

[Zoltan_Gyimesi]

Re: RE: Versions problem...

Hi Scotti,

Glad to read that your problem have been resolved.

Maybe you didn't read the ott-00-0071 "Configuring Object Management Workbench for Batch Versions in B73.3 Xe" documentation from the Knowledge Garden.
The "Batch Versions and Check-In Location" chapter and the "Controlling Check-In Location" chapter are mainly interesting.

Maybe you have already got these informations. In this case I hope it could be new and usefull for sombody else.

Regards,
Zoltán
P.S.: I greatly recommend everybody to download the mentioned documentation.

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)