Data/Environment Refresh questions

kitsants

Member
Hi,

Our functional analyst has asked me to refresh the PY environment from PD to troubleshoot an issue. This is the first time that I'll be doing this task so I want to understand first some concepts behind data/environment refresh before doing it and I have a few questions which I know that you great guys here in JDE List can enlighten. Actually, I have created a case with Oracle but I'm really not satisfied with their answers so I have to run to the real experts.
smile.gif


Here are my questions:

1.) Is it possible to refresh just the data (business data) in PY from PD and not refreshing the entire environment (data + objects)? Can I accomplish this by refreshing just the Business Data tables (using R98403|XJDE0021) or after refreshing business data, do I also have to refresh Control Tables (using R98403|XJDE0022) to prevent any possible integrity issue(s)? Is there any caveat for E1 812 TR 8.96.1.1 ?

2.) What is the main difference between Load Demo Data and Load Production Data. The meaning of these load options are a bit confusing based on a couple of documents from Oracle. See these articles below:

From SOLUTION 20104733:

*Do Not Load Data -- This option does not create any tables nor does it load any data for the environment being upgraded or installed. This option is not used to upgrade typical environments.

*Load Production Data -- This option loads JD Edwards EnterpriseOne configuration and control data. Created application transaction tables, such as Accounts Payable tables, remain empty. This is the default option for all environments except Pristine, Development and Production.

*Load Demo Data -- This option loads JD Edwards EnterpriseOne demonstration data into the control and application tables that are created. Use this option if you want to add sample data (such as mock inventory) to the environment you are upgrading. This is the default option for the Pristine and Development environments but not Production.

From Solution 200783116

Processing option 3 determines whether or not data will be copied. The value you enter here does not really determine if PROD or demonstration data is to be loaded. The value determines whether or not the data from the source location will be copied to the target location. A value of `2' will copy the data. A value of `1' will be cross-referenced with the Copy Data object code value (discussed in more detail later) on the Object Librarian record for the table being processed.

As you can see, Loading Options were defined differently from the 2 Solutions above, specially loading Demo Data.

3.) After running R98403|XJDE0019 to copy Central Objects tables (in a test environment), I found a discrepancy that I suspect is an issue. The PDF output file for the report states there were 11,570 records inserted in the F983051 table in the "Central Objects - PY812" data source. However, after the report ended the PY812.F983051 table only contained 11,537 records. So, the table seems to be missing 33 records based on the information in the PDF output file. Has anyone of you experienced this issue?

Any tips or advise when refreshing data or environement would be greatly appreciated.
smile.gif
Thank you very much in advance for your help.:)
 
1) Yes. You can certainly refresh data and control tables only. I always recommend refreshing both, as there are interdependencies. But "can" you do one or the other, certainly.

2) Not sure why you are in the installation planner area of load demo or load production, but in 8.12, they have no meaning as they have been deactivated. But you really shouldn't be in this area to perform an environment refresh. You didn't mention your platform, but I find the best and cleanest way to perform a refresh is either direct DB copy, or use the R98403. For instance, on the iSeries platform, you need to backup the target business data library and control table library, clear the targets, and copy (or restore from SAVF) from the source to target.

3) Central objects can be handled in the same manner, that is not by using R98403, but by direct DB copy. In 8.12, you'll just need to build a full package on the target after the copy, because of the way packages and CO's are managed in 8.12 differently than in earlier releases. About the only thing you need to remember doing it this way is the field holding the path code (even though the field name is ENHV) needs to be changed from source to target (PD812 to PY812 for example). You'd also need to do some things to the F9861 but there is a UBE to perform this.

If you put your platform on your post, people will give you more detailed answers specific to your platform.
 
Hi Jim,

Thank you for your very informative response - appreciate it. May I ask about these interdependencies you mentioned on my first question? Is it safe to say that I must refresh Control Tables whenever I refresh Business Data as it can cause integrity issues?

By the way, here is my platform:

E1 8.12
Tools Release 8.96.1.1
SQL Server 2000 SP4, Windows 2003 Server R2
WebSphere 6.0.2.13

Thanks again,

Kit
 
[ QUOTE ]

2) Not sure why you are in the installation planner area of load demo or load production, but in 8.12, they have no meaning as they have been deactivated. But you really shouldn't be in this area to perform an environment refresh. You didn't mention your platform, but I find the best and cleanest way to perform a refresh is either direct DB copy, or use the R98403. For instance, on the iSeries platform, you need to backup the target business data library and control table library, clear the targets, and copy (or restore from SAVF) from the source to target.


[/ QUOTE ]

Sorry if my question could be confusing, but I'm not going to use or go into the Installation Planner with reference to "Load Demo Data or Load Production Data" question, I'm only referencing the two conflicting articles from Oracle with regards to how they define "Load Demo Data" processing option. Since these Loading Options are being used in E812 when running R98403|XJDE0019, R98403|XJDE0021, R98403|XJDE0022, I just would like to know what the real deal with "Load Demo Data" option.

Thanks again,

Kit
 
I don't know if the original post was edited afterwards or not, but the platform is listed at the bottom ... we're talking SQL Server 2000.

1) You won't have integrity issues, but you could certainly have validation problems since some values may give you a hard error when you try to edit them due to missing UDCs from unsynced Control Tables. Previous suggestion holds: best to refresh them at the same time. Your Tools Release level should not play into this at all.

2) Agreed that E812 turns off those options in the Installation Planner, however, that processing option value is still in play on the R98403, so it's a legitimate question.

- "Do Not Load Data" is pretty self explanatory.
- "Load Production Data" was originally meant to load an environment so it was "ready for production use." In the context of a fresh install, this means to create tables in the data source, with all of them empty except for a few special ones, like F0008 (Fiscal Year Calendar), the UDCs (F0004 and F0005), menus (F9000-F9005), etc. In the context of running R98403, nothing will happen unless you also set the processing option on the 2nd tab for recreating tables. Then it will recreate empty tables in the target data source.
- "Load Demo Data" was used in the context of loading the DV and/or Pristine environments with Demo Data during initial installation. Used on R98403, this means to copy all the data from every table to the target.

I hope this clears up the meaning.

3) I believe the discrepancy you see in the Version table count consists of versions that people have checked out, but not checked in. If you can do a query on F983051, and do a count by the field VRMKEY, you'll see the vast majority of records that have that field populated by the Deployment Server name. This means that they are checked in. A record populated with any other machine name in that field means that the version is checked out on that machine. I don't believe R98403 copies those records over to the target.

**********
As jstooge points out, doing a data refresh is generally much faster if you can use the native DB tools to do it, rather than R98403. That UBE copies tables on a row-by-row basis, and just takes forever, especially on the big transaction tables. If you're using something like SQL Server and Oracle, this can fill up your transaction log files really quickly.

With SQL Server, I prefer to either backup/restore using SQL Enterprise Manager, or whatever backup utility you use, or dismount the database/copy the files over/and mount the copy as the target database. In either case, I have a script to correct the table owners and make sure permissions are granted back to [Public].
 
Jim and Ken,

Thanks very much for answering my questions - really appreciated. Your answers surely clear things up. I shall take all your advise.
smile.gif


Ken,

If you can send me the script that you mentioned would be great. I will send you a PM with my email address.

Thanks again,

Kit
 
Hi,

Well, I've done a lot of refresh stuff.

I've always followed the below simple steps to refresh PY environment from PD environment.

1) Check that no user is logged into JDE

2) Take a backup of CRPDTA & CRPCTL tables

3) Truncate the tables in CRPDTA & CRPCTL

4) Copy the tables from PRODDTA & PRODCTL to CRPDTA & CRPCTL respectively

Bang........... u r done

cheers

-Max
 
Back
Top