Version Transfer not working correctly

jdcmwilson

Well Known Member
JDE List,

I am working with a client that is having the following problem:

B73.3.2 with an AS/400 Enterprise Server. COs are on the Deployment Server.

Cannot do a version transfer (Using Object Transfer) from DEV to PROD but we
can from DEV to CRP. If we do an Record Copy we can get the Versions to
PROD but the Processing Options are gone.

I have looked at the F983051 in PROD and the versions are not there until I
use the Record Copy function.

Your quick response is much appreciated.

Thanks,
James
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com



All views are expressly my own and in no way reflect those of my employer.
 
James,

1 - Are you getting any errors in Object Transfer? Or in the jde.log or
jdedebug.log? I'm assuming this is not a database rights problem, since you
can do the record copy. To be sure there isn't some sort of rights issue
with the central objects files (which are not being hit in the record copy),
you should try signing onto prod and adding a version to any ube and
checking it in. If the check in fails, then you definitely have a
permissions problem with the prod central objects database.

2 - Is this a problem for both interactive and batch versions in object
transfer? The only time I know of that ot does not transfer the version is
if the base object (appl or ube) is not already in the destination pathcode.

3 - Be very careful using record copy to move batch versions around. It
only copies the f983051 record...not the specs. So your batch version will
appear to be in prod, but will not function because it has no specs. Object
Transfer is the only way to move versions between pathcodes.

If you'll get back to me on the above questions, I can probably give some
direction.


>From: jdcmwilson <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: Version Transfer not working correctly ~~0:1585
>Date: Wed, 22 Nov 2000 09:02:04 -0800 (PST)
>
>JDE List,
>
>I am working with a client that is having the following problem:
>
>B73.3.2 with an AS/400 Enterprise Server. COs are on the Deployment
>Server.
>
>Cannot do a version transfer (Using Object Transfer) from DEV to PROD but
>we
>can from DEV to CRP. If we do an Record Copy we can get the Versions to
>PROD but the Processing Options are gone.
>
>I have looked at the F983051 in PROD and the versions are not there until I
>use the Record Copy function.
>
>Your quick response is much appreciated.
>
>Thanks,
>James
>_____________________________________________________________________________________
>Get more from the Web. FREE MSN Explorer download :
>http://explorer.msn.com
>
>
>
>All views are expressly my own and in no way reflect those of my employer.
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=1585
>*************************************************************
>This is the JDEList One World / XE Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com



owguru (at least I'm trying :)
>all versions
>all platforms
 
I am also at the client with James. I can answer your queries.

1. Nothing, Nada, Butkis,. The Logs(jde, jdedebug, OWT) all indicate a
successful transfer. Versions can be created, checked in, checked out, and
deleted for the PROD environment.
2. Yes and Base objects have been confirmed to be in the destination
pathcode.
3. We are aware of that. Object Transfer is working just fine for base
objects. It is only Version Copy that is not working. We needed a quick
work around and fell back to RC in order to get versions into the PROD
pathcode. The pathcode has to be changed in each record and PO re-entered.
It is cumbersome, but the versions we are bringing from DEV have programming
changes so processing options are the least of our worries there.
4. One more bit of additional information: We also cannot Transfer Version
OUT of PROD. When a Transfer OUT is attempted we receive and Error (Fetch
from F983051 failed) We can UTB and browser the file. Security has been
checked on the AS400 for the Library and F983051 object and is the same as
for other pathcodes.


Roger Powell
Consultant - Consulting and Services Group
Data Systems International
 
Re: RE: Version Transfer not working correctly

Roger & James,

First, if you haven't already, I would strongly suggest a quick search of sars on the knowledge garden. I don't know which version of ow you are working with, but there are usually serveral fixes for the transfer program in each release. In particulare I saw one at the B733 level that sounded like what you are experiencing.

Second, I peeked into the event rules in P98604. I would put this into er debug on the Transfer toolbar button on the transfer versions form. If it seems to progress through all the tests there and passes, the move onto the bsfn that it calls to do the transfer.

The bsfn is B9800104. I would test with an interactive version (much less complicated!). So set your breakpoint at the beginning of the function, TransferAPPLVersion. Then try to transfer an interactive version and step through this code. There are several things that could be off here, so you just have to see what happens. Things to watch for:

1 - If the following functions aren't successful, then there may be an issue with what the system thinks is your environment and pathcode setup. Unfortunately the function calls go into system code, so you can't debug any deeper. If you are transferring from dev to prod and it succeeds on the first call, but not the second, I would poke around in utb with the environment tables (F0094, F00942, etc) just to see if I could catch anything that looks too different between the dev and prod environment or pathcode records. This is especially true if you have customized environments or pathcodes or had to "fix" the typical ones manually.

if(jdeRetrieveOLDatasourceFromPathCode (hUser, NID_F983051, lpDS->szPathCodeFrom, szF983051DS_Source, sizeof(szF983051DS_Source))== RDBAPI_PASSED)
{
if(jdeRetrieveOLDatasourceFromPathCode (hUser, NID_F983051, lpDS->szPathCodeTo, szF983051DS_Target, sizeof(szF983051DS_Target))== RDBAPI_PASSED)

2 - If the above two calls succeed, the function will continue and fetch the F983051 record from the source data source and attempt to update the destination F983051 with the record.

Sorry I can't give a simple "here's your problem" type of answer, but I hope this gives you some direction. Please let me know what you find.

owguru (at least I'm trying :)
>all versions
>all platforms
 
I would review OCM settings for F983051 and any other CO related files..

Next... Did it work before? If it has worked, what has changed? Does
it fail for multiple users? Does it work for some objects or fail for all?




AS400@V4R4, B733.2, SP10USER2, NTSQL7DPLY
 
James, Dan and I where called in on a rescue mission on this one and the
project manager cannot inform us as to any previous attempts to transfer
versions into production. F983051 OCM mapping is to datasource Versions -
PRODB733 - DNT. As far as I am aware no other tables are involved in a
versions transfer. A random sample of versions indicates that the problem
is universal.


Roger Powell
Consultant - Consulting and Services Group
Data Systems International
 
RE: RE: Version Transfer not working correctly

Thanks. I will forward to the resource still on site.


Roger Powell
Consultant - Consulting and Services Group
Data Systems International
 
Roger,

The tables involved actually depend on the type of version. If it is an
interactive version the only table involved is the F983051. If it is a batch
version the RDA spec tables are also involved. I believe the tables are the
F98760 and F98761. You can verify this by using UTB to view your local rda
spec files. I am not sure whether the GBR specs are involved on a batch
version transfer. The only way to be sure is to do a transfer in debug and
look at the tables it uses.

Paul Ross
OneWorld Hired Gun
[email protected]
Phone: (513) 984-3093 x3097
 
Paul,

You are correct, but incomplete...

Interactive Versions:
F983051

Batch Versions:
F983051
F98760 (rdaspec)
F98761 (rdatext)
*F98740 (gbrlink)
*F98741 (gbrspec)
*F98743 (dstmpl)

*records exist only if specific version overrides exist

Using UTB to view the central object files (F987*) will display the files,
but not all the information. These files contain blob fields, and this
information is not readable using UTB.

You can use UTB to view your local spec files (rdaspec, rdatext, etc.) by
adding a line to the jde.ini file under the [Interactive Runtime]
section...TAMMenus=Show. With this setting, you can run UTB and go to
File|Open Local TAM. (Note, do not use Open Remote TAM. It doesn't work in
most instances the way you expect.) This utility will open a file such as
rdaspec and show you the blob information in a readable format. While this
can be quite interesting reading, it's rarely helpful! Even if you do
figure out that there is a spec problem or what it is, there is no way to
"fix" it directly.


>From: paul ross <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: RE: Version Transfer not working correctly ~~1585:1768
>Date: Tue, 28 Nov 2000 06:44:10 -0800 (PST)
>
>Roger,
>
>The tables involved actually depend on the type of version. If it is an
>interactive version the only table involved is the F983051. If it is a
>batch
>version the RDA spec tables are also involved. I believe the tables are the
>F98760 and F98761. You can verify this by using UTB to view your local rda
>spec files. I am not sure whether the GBR specs are involved on a batch
>version transfer. The only way to be sure is to do a transfer in debug and
>look at the tables it uses.
>
>Paul Ross
>OneWorld Hired Gun
>[email protected]
>Phone: (513) 984-3093 x3097
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=1768
>*************************************************************
>This is the JDEList One World / XE Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com



owguru (at least I'm trying :)
>all versions
>all platforms
 
Back
Top