• 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!

transfer object via OMW

CHo

VIP Member
We are on Xe SP 15.1. Since we don't do a lot of development work, we use two pathcodes, PY and PD.

I want to transfer some custom reports from PY to PD. However, when I transfer the project status from 41 (PY) to 40 (PD), the objects won't transfer. The OMW logging indicates that it has transferred, but the F9861 table is not updated.

I have set up the transfer rules for moving objects (UBE, UBEVER) from status 41 (PY)to 40 (PD).

I've gone to PD to check if it has transferred and they have not.

Can someone please help me?

C Ho
Intermediate Programmer/Analyst
Xe SP 15.1 AS/400 V4R3 coexistant
CO on SQL 7.0 SP2 + hotfix
 

KBohn

Active Member
Hi Catherine,

What owners do you have defined in the project? You may need to ensure that
you have Supervisor or Manager or PVC Administrator. We have had some
problems like this occur when we did not have the correct owners in the
project.

Good luck & Cheers,
Kimberley Bohn
QNX Software Systems Ltd., Canada
Xe U1 SP15 on NT
SQL 7.0 SP2 + hotfix
 

CHo

VIP Member
Re: RE: transfer object via OMW

Because we don't do much development, we have a user called "Superuser" which is able to do everything under the sun. Thanks for your help.

Hi Catherine,

What owners do you have defined in the project? You may need to ensure that
you have Supervisor or Manager or PVC Administrator. We have had some
problems like this occur when we did not have the correct owners in the
project.

Good luck & Cheers,
Kimberley Bohn
QNX Software Systems Ltd., Canada
Xe U1 SP15 on NT
SQL 7.0 SP2 + hotfix



C Ho
Intermediate Programmer/Analyst
Xe SP 15.1 AS/400 V4R3 coexistant
CO on SQL 7.0 SP2 + hotfix
 

Carl_Fisher

Well Known Member
Stupid question: Have you modified the Objects in question? OMW checks the date stamp on an object before running a transfer, if the Object in the TO environment is Newer than the Object in the FROM environment, you do not get an error, just no transfer.

Use the UTB to look at F9861 and the Date Modified for the Object in question - compare PY with PD

You can fix this in two ways:

1) Check Out / Check In the Object in PY (this will update the date stamp)

2) SQL the OL table F9861 to change the Modified Date of the PD Object to pre the PY Object. Just depends on why you are doing the transfer and whether you want to keep the current Modified date on the PY object, this can be useful if it is a standard JDE Object and you wish to apply an ESU (as this too checks the Modified date and uses it to select Objects to update!).

OW733.3 Xe SP 14.2
Enterprise Server - Intel NT + Oracle 8.0.6
Client - Citrix TSE + 4 NT PC's for development
 

CHo

VIP Member
The objects that I'm transferring are custom objects. Some of them have been newly created which have no corresponding PD record in F9861. Some of them are updated custom objects, but the PD record in F9861 have an earlier date modified (from B7322 upgrade) than the ones in PY.

I will be very angry if I have to check out and check in all custom objects before transferring them. We have two full-time report analysts who are creating and modifying reports templates and versions everyday. If I have to check out and check in all of their objects, then the act of transferring their objects will be a full-time job for me.

C Ho
Intermediate Programmer/Analyst
Xe SP 15.1 AS/400 V4R3 coexistant
CO on SQL 7.0 SP2 + hotfix
 

zola25

Member
Catherine

We had a few reports that wouldn't transfer via OMW from DV7333 to PY7333 or from PY7333 to PD7333. Like you we had objects in PD7333/PY7333/DV7333 with Specs Upgraded from B732 and for some reason the Upgrade procedure appeared to create numerous 'redundant' spec records. When we came to change a project from Programming to QA status and thus move the specs into PY7333, OMW produced a Spec Mismatch Error stating the number of PY7333 specs did not match the DV7333 specs. JDE reported that the numbers do not have to match when the Target Environment has less than the Source Environment. I.E. The DV7333 object has more spec records than the PY7333 environment. If your developers enter RDA in DV7333 and upon exiting it get the Validation Event Rules text appearing with numerous entries then they will have encountered the same 'redundant' specs. These have to be removed before RDA will let the object be properly saved - the problem then is OMW won't promote the object. I did get round this eventually though :))

Jamie

XE SP15 AS/400 V4R4. NT Deployment Server.
 

DBohner-(db)

Legendary Poster
CHO,

Sorry to say...but the steps for promotion in OMW require a check in... at least here they do.

The process of checking in (PY) moves the specs from your local machine to the PY environment. The promotion moves the specs from the PY environment to the PD environment. Once logged into the PD environment, you'd have to go into OMW and do a GET - to bring the specs local(Local to your PD environment -OR- do a package build/deploy). You should not be able to deploy objects that have not been checked in.

One other way to accomplish is to use a save environment. From PY - SAVE your object. Log into PD and do a restore.

Hope this helps... If there is another way (best practices), please provide a heads up...



Daniel Bohner
drbohner@existinglight.net
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
 

CHo

VIP Member
Sorry, I should have made my post more clearer. These objects have already been checked in by their perspective owner. I am trying to transfer them now.

It seems like I have to recheck them in again before they will transfer. I have to transfer them right after I do the checkin.
It looks like OMW is looking for today's date for the date modified field before it'll transfer the object. I tried it with an object that was checked in yesterday and it did not work.

This is going to be a pain in the butt since we do so many custom reports.



C Ho
Intermediate Programmer/Analyst
Xe SP 15.1 AS/400 V4R3 coexistant
CO on SQL 7.0 SP2 + hotfix
 

swhitmire

Reputable Poster
Are you transferring the same project, or a different project?
If you move the objects to a different project from the one they were
checked in
from and then transfer that project, OMW will advance the status and
silently
not transfer those objects; if you look in the logging, you'll find that it
skips objects not modified by the project you're transferring. The only
way I've found around this is to check the objects out and back in in the
new project prior to advancing the project.

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

DBohner-(db)

Legendary Poster
C Ho,

I think you are having a privs/rights issue... at least that what it sounds
like to me. If you aren't setup correctly in OMW - quite unexpected results
can appear.

When you do a check in, OMW should ignore dates and just move whatever specs
are on your machine to the log'd in environment. Yes - it should overwrite
newer specs with older specs even if the newer specs are on the path code
environment(newer than your local specs)...

The process of promotion will overwrite the destination with whatever specs
you are promoting.

A GET or Checkout will overwrite your local specs with whatever is in the
path code of your log'd in environment....

At least, this is what I am told - Larry, Zoltan, Adr.... Others... am I
working too much on assumption?

When applying an ESU/Update Merge, then the newest object (ESU/Update or
whatever spec is on the pathcode) will rule...

I don't mind corrections...



Daniel Bohner
drbohner@existinglight.net
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
 

ijc

Well Known Member
Catherine,

We have a lot of modifications and don't have to do any additional checks
ins.

I assume the project is changing status. I assume the logging says its
changed status but have you checked the detail for the object (if theres no
detail set your logging to full logging in OMC & try again).

Also double check the setting in OMC "if logging system becomes
unavailable".

Ian







Xe, Oracle 8, NT
 

Larry_Jones

Legendary Poster
Re: RE: transfer object via OMW

I think Scotti has it right.

What was logical and simple in the OL days is not obvious and is convoluted in the OMW environment ... :(



Larry Jones
ljones@wagstaff.com
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 

CHo

VIP Member
Re: RE: transfer object via OMW

I've done some testing. Scotti, you are correct. The object has to be both checked in and in the same project that it was modified in. Theortically, that's great in Denver, but it doesn't work for us.

Thanks for everyone's help.



C Ho
Intermediate Programmer/Analyst
Xe SP 15.1 AS/400 V4R3 coexistant
CO on SQL 7.0 SP2 + hotfix
 
One thing to keep in mind is that OMW is project based not object based. If
someone else checks in the object from a different project than the one you
are trying to advance, it won't transfer the object. If you switch
projects, you will have to check it out and back in again because the system
only checks to see if the project you are advancing has checked it in.

Now if a developer does the work in a project and checks it in there and
then gives you the project name to move, then no extra steps are necessary.


Mike
CNC Administrator
Xe SP 15.1 AS/400 V4R5
 
Top