PY Refresh from PD DB Backup

JMast

Reputable Poster
Good Morning All,

We are running JDE E1 on Windows SQL Server. When we were on 9.1, I could refresh PY with PD by restoring a full backup of PD. When we moved to 9.2, it became a little more complicated. The new UDO architecture has tables in the JDE920 database with pathcode specific references which need to be considered for the refresh. I am looking for the list of tables in the JDE_CRP/JDE_PRODUCTION database that has data linked to JDE920 or for a script/process for restoring PD to PY while maintaining links. Here is the process I used in 9.1 and would like to continue in 9.2.

- identify tables in JDE_CRP that need to be preserved with PY data

- copy these tables out to a 3rd "utility" database for holding

- drop the JDE_CRP database

- restore the JDE_PRODUCTION backup as JDE_CRP

- update table owners / logins

- restore the saved tables back into the "new" JDE_CRP database

So, in my investigating the UDO tables, there are tables in JDE920 for OMW purposes (I believe), that have unique info for each environment saved in the same table. One option would be to try and copy/update records in those tables. As JDE920 is the system database, I would prefer to not be doing custom updates to that database.

My plan would be that the UDOs and any other tables that fit this description would remain as they were in PY.

This process of restoring from backup is extremely efficient, once the initial scripts are created, allowing PY to be refreshed with between 2 and 3 hours of downtime which means it could even be done during the day if needed. It allows us to refresh more frequently as the business needs change.

Thank you for your time,

Jeremy
 
UDO detail for each environment resides in Central Objects so as long as you aren't restoring that, you should be ok. Review the following doc for more info - E1: OMWWEB: Frequently Asked Questions On User Defined Objects (UDOs) (Doc ID 2068939.1).
 
Thanks for the response, David. Did I cross some wires?

I have notes from that document in my UDO details, but your response made me look at it again to see the comment about being in the pathcodes database.

Our upgrade from 9.1 to 9.2 was more rushed than we expected and we didn't get UDOs off to a good start. When I was under pressure trying to sort out issues we had with UDOs in the different environments after the upgrade, I came across connections with tables in JDE920. I was convinced the other side was in the Business Data not Pathcodes. Of course, I didn't take detailed notes as it was a sidebar to what I was really needing to solve so I don't have table detail.

That would be great news to know that there are no tables in Business Data that have corresponding links to records in JDE920.

Jer
 
Jeremy,

I don't understand the concern with the data in JDE920. In the majority of cases that database is shared across all environments. Are you trying to separate everything? not just DTA/CTL?

P.S. Our approach to a SQL Server refresh/copy to CRP/TEST from PROD is automated with the following main steps in the process:

1. Take a snapshot of all the permissions (grants, etc) in PRODDTA/CTL but translate PROD to CRP (or TEST). Permissions stored in a SQL File to be executed later.

2. Restore last full backup of JDE_PRODUCTION over JDE_CRP (or JDE_DEVELOPMENT). Set Recovery Mode to Simple.

3. In the destination database change the Schemas from PROD to CRP for all the objects (tables, views, triggers, procedures, functions, synonyms)

4. Execute the permissions sql generated in Step 1

5. Miscellaneous cleanup
- Change all email addresses to something safe
- Remove all F00165 references to File Media Objects
- Truncate some work tables
- ...
 
Hello Larry, thanks for the reply. I am not looking to do anything custom in JDE920. As I replied to David, this question is based on a side observation, obviously incorrect, during rushed research on how UDOs work.

Your reply is what I wanted to hear in that you do similar refreshes in 9.2 without concern around UDOs or other processes. I do like your idea of changing email addresses themselves. We have been using a custom From address in PY that the email server reroutes to avoid sending emails.

Thank you both for helping me even though I violated forum and my own rules by not coming to the post with definitive detail. Turns out, it saved me a good chunk of time researching only to find out I was wrong anyway.
 
Back
Top