Refresh of CRP Business Data from PROD... R98403 Help?

jgb35

Member
Greetings, I'm trying to copy Production Data back into CRP Environment for
further testing and development. I'm trying to use
R98403, Ver. XJDE0021 to do so. I run the UBE in Proof Mode, but don't
really know how to read the 45 page report which follows.

I believe the problems/risks w. this UBE are associated w. the Processing
Options/Flags. I'm copying Data Source to Data Source not Env. to Env.,
Also, I'm leaving the existing records in CRP intact, rather than
overwriting them as a precaution. Anyone have a known good config. for
processing options, and/or some knowledge on how to know if this process
will work when not in proof mode? Also, I'm concerned that this process may
overwrite OCM Mappings or other critical Tables in CRP Path w. PRD settings
and potentially cause CRP IV's and BV's to map to PRD. Is this a valid
concern? Any assistance much appreciated...
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.
 
The process should not be overwriting any OCMs. It is purely a data xfer. You are right by going data source to data source. I would also overwrite the CRP data. If you are worried about not having a backup then look at the data selection and make a database copy of the tables listed or just backup everything owned by CRPDTA in the database. The processing options are worded poorly and you should look on the KG for the following document and read it carefully.

The Guide is: Environment Database Creation Batch Application (R98403). The name of the actual file is ttdk0027.doc. The key options are #7 and #9.

Allen
 
Several good replies posted on this one...here's my 2 cents...

1. DEFINITELY get a copy of the document on R98403 from the knowledge
garden that others have referred to. This is a must for setting the
processing options. Personally, I do recommend taking the options of
recreating tables, which will wipe out the crp data. Take a good backup
before you start! By leaving existing crp data, you leave a lot of room for
funky results in the applications. Next numbers may be out of whack, the
relationships between records and files may be convoluted by the extra data
that wasn't in prod. The whole point is to get "clean" data for testing.

2. I strongly recommend copying data source to data source instead of
environment to environment. You have more control, instead of relying on
OCM settings to determine what is copied and to where. Copy ds to ds
(business data - prod to business data - crp and control tables - prod to
control tables - crp).

3. As for your concerns about overwriting OCM mappings and other critical
tables...you will not be overwriting OCM mappings (F986101 in the system
data source).

4. A note on versions. Many times clients want to "refresh crp" and expect
prod versions to show up in addition to prod data on the crp side. There
are many consultants out there who will copy prod versions (F983051) to crp
versions (F983051) manually or using a ube (I think R983051) which updates
the location and pathcode information in the records. I personally STRONGLY
recommend against this! Versions are a very special animal, a complicated
cross between data and development. The only way I recommend copying
versions is to copy an entire pathcode. That means copying the production
pathcode with versions to crp. Versions contain specs and this is the only
way to get a complete copy. There is no way to extrapolate versions specs
from the rest of a pathcode's specifications unless you do an object
transfer one version at a time...and that's just insanity.

Good Luck!


>From: jgb35 <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: Refresh of CRP Business Data from PROD... R98403 Help? ~~0:392
>Date: Thu, 2 Nov 2000 22:04:14 -0800 (PST)
>
>Greetings, I'm trying to copy Production Data back into CRP Environment
>for
>further testing and development. I'm trying to use
>R98403, Ver. XJDE0021 to do so. I run the UBE in Proof Mode, but don't
>really know how to read the 45 page report which follows.
>
>I believe the problems/risks w. this UBE are associated w. the Processing
>Options/Flags. I'm copying Data Source to Data Source not Env. to Env.,
>Also, I'm leaving the existing records in CRP intact, rather than
>overwriting them as a precaution. Anyone have a known good config. for
>processing options, and/or some knowledge on how to know if this process
>will work when not in proof mode? Also, I'm concerned that this process may
>overwrite OCM Mappings or other critical Tables in CRP Path w. PRD settings
>and potentially cause CRP IV's and BV's to map to PRD. Is this a valid
>concern? Any assistance much appreciated...
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>Share information about yourself, create your own public profile at
>http://profiles.msn.com.
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=392
>*************************************************************
>This is the JDEList One World Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.
 
Well, OWGuru, as to your point 4: I'd like to share a couple of points:
1. Copying F983051 is completely safe for interactive versions. They are
only stored there.
2. Batch versions are a little trickier - they have at least one record in
F98761 (in central objects), so SQL copying is not an option (well, if you
are brave SQL guru in CRP phase, you may try, we did use it successfully on
a couple of occasions [F98760, F98761, you've being warned]). But JDEdwards
UBE is specifically designed to do the task, so; presumably it is much
faster then copying complete pathcode (you have to stop development for at
least a day, that is if you're lucky). It does have some catches, but once
it runs - I'd vote for it.

Regards,
Vladimir Ponomarev
 
I agree point-for-point and statement-for-statement with everything that
was said. I have lived through the horror of having to clean up problems
that were created with copying the F983051 table with the Business Data and
Control Tables.

Also, I recommend using the XJDE0021 and XJDE0022 versions to copy the
Business Data and Control Tables respectively. You will have to specify
the Data Sources, but all of the other parameters should be set already.

You should also consider creating an OCM to run the R98403 locally.




Adam Clark





owguru
<[email protected] To: [email protected]
om> cc:
Sent by: Subject: Re: Refresh of CRP Business Data from PROD... R98403 Help? ~~392:698
owner-jdelistml@j
delist.com


11/08/2000 09:20
AM
Please respond to
jdelist





Several good replies posted on this one...here's my 2 cents...

1. DEFINITELY get a copy of the document on R98403 from the knowledge
garden that others have referred to. This is a must for setting the
processing options. Personally, I do recommend taking the options of
recreating tables, which will wipe out the crp data. Take a good backup
before you start! By leaving existing crp data, you leave a lot of room
for
funky results in the applications. Next numbers may be out of whack, the
relationships between records and files may be convoluted by the extra data

that wasn't in prod. The whole point is to get "clean" data for testing.

2. I strongly recommend copying data source to data source instead of
environment to environment. You have more control, instead of relying on
OCM settings to determine what is copied and to where. Copy ds to ds
(business data - prod to business data - crp and control tables - prod to
control tables - crp).

3. As for your concerns about overwriting OCM mappings and other critical
tables...you will not be overwriting OCM mappings (F986101 in the system
data source).

4. A note on versions. Many times clients want to "refresh crp" and
expect
prod versions to show up in addition to prod data on the crp side. There
are many consultants out there who will copy prod versions (F983051) to crp

versions (F983051) manually or using a ube (I think R983051) which updates
the location and pathcode information in the records. I personally
STRONGLY
recommend against this! Versions are a very special animal, a complicated
cross between data and development. The only way I recommend copying
versions is to copy an entire pathcode. That means copying the production
pathcode with versions to crp. Versions contain specs and this is the only

way to get a complete copy. There is no way to extrapolate versions specs
from the rest of a pathcode's specifications unless you do an object
transfer one version at a time...and that's just insanity.

Good Luck!


>From: jgb35 <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: Refresh of CRP Business Data from PROD... R98403 Help? ~~0:392
>Date: Thu, 2 Nov 2000 22:04:14 -0800 (PST)
>
>Greetings, I'm trying to copy Production Data back into CRP Environment
>for
>further testing and development. I'm trying to use
>R98403, Ver. XJDE0021 to do so. I run the UBE in Proof Mode, but don't
>really know how to read the 45 page report which follows.
>
>I believe the problems/risks w. this UBE are associated w. the Processing
>Options/Flags. I'm copying Data Source to Data Source not Env. to Env.,
>Also, I'm leaving the existing records in CRP intact, rather than
>overwriting them as a precaution. Anyone have a known good config. for
>processing options, and/or some knowledge on how to know if this process
>will work when not in proof mode? Also, I'm concerned that this process
may
>overwrite OCM Mappings or other critical Tables in CRP Path w. PRD
settings
>and potentially cause CRP IV's and BV's to map to PRD. Is this a valid
>concern? Any assistance much appreciated...
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>Share information about yourself, create your own public profile at
>http://profiles.msn.com.
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=392

>*************************************************************
>This is the JDEList One World Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.




--------------------------
To view this thread, visit the JDEList forum at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=698

*************************************************************
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
*************************************************************
 
Vladamir,

Thanks for the clarification. In my haste, I didn't spell it all out this
time.

You are right on with the interactive versions.

I would still use extreme caution with the batch versions, though. They can
be stored across a number of spec files...those you mentioned plus the
F98740, F98741 and F98743, depending on what type of version overrides were
done. I've done more than my share of "cowboying", but I don't mess with
specs!

BTW, I believe the TC that copies versions is R91983051. Someone can
correct me on that if I'm wrong. And if someone has decent notes on how to
set the properties, I'm sure it would be appreciated. I always have to
muddle my way through.


>From: vap <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: RE: Refresh of CRP Business Data from PROD... R98403 Help?
>~~392:716
>Date: Wed, 8 Nov 2000 12:54:16 -0800 (PST)
>
>Well, OWGuru, as to your point 4: I'd like to share a couple of points:
>1. Copying F983051 is completely safe for interactive versions. They are
>only stored there.
>2. Batch versions are a little trickier - they have at least one record in
>F98761 (in central objects), so SQL copying is not an option (well, if you
>are brave SQL guru in CRP phase, you may try, we did use it successfully on
>a couple of occasions [F98760, F98761, you've being warned]). But JDEdwards
>UBE is specifically designed to do the task, so; presumably it is much
>faster then copying complete pathcode (you have to stop development for at
>least a day, that is if you're lucky). It does have some catches, but once
>it runs - I'd vote for it.
>
>Regards,
>Vladimir Ponomarev
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=716
>*************************************************************
>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 Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.
 
Back
Top