What are the top 5 things every CNC gets asked to do regularly? I bet you’ll say security, and maybe package builds, followed by ESU installations or maybe restarts… but I KNOW data refreshes are in there somewhere, too! We’ve all done hundreds (or perhaps thousands) of data refreshes over the years, and we know the drill. But there are a few gotchas that are good to keep in mind, for even the most experienced CNCs. Here are three scenarios to keep an eye out for, off the top of our collective heads:
1) Email Addresses
You probably know if your company or client has the SMTP server configured in the jas.ini for Production, so you know that transactions or jobs run in PROD could potentially send out emails. But are you SURE about that jas.ini setting for PY? Some organizations test emailing in PY, or they turned it on for a project like PO Approval implementation and never turned it off. What’s the big deal? Well, a data refresh *can* be a big deal here. During a refresh from PD to PY or DV, the F01151 is of course among the tables copied from PRODDTA. The email addresses are stored here, along with the Messaging Indicator (EHIER) that controls whether email is sent to each stored email address. If set = 1, emailing is active, and if you copy those EHIER = 1 records down from PROD and the SMTP is on in the jas.ini, testing transactions could fire off emails to employees, vendors, or even customers. Not good!
Best practice: Either run a quick update query to set the EHIER = 0 on all F01151 records, or just clear out the F01151, depending on whether the users need the email address data or not.
2) BI Publisher Templates and Report Definitions
Often, people forget that the BIP templates from F95600 and the report definitions from F95620 (along with all of their other F956* friends) are stored in the Control tables. And if, during a data refresh, you copy PRODCTL down to DV or PY, you can accidentally blow away weeks or months of BIP development work (or testing configuration) that will then have to be recreated. Yikes!
Best practice: Backup ALL tables in the target database before you begin, both in case of any problems and to enable a restore of these specific tables after a refresh from PD. If you choose not to selectively restore the tables, ensure your developers have saved off their template and RD work and/or can easily recreate it!
3) Media Objects
Yes, data refreshes can impact Media Objects! When you refresh F00165 from PROD to PY, you are also copying the link to the MOBJ files that are stored on the deployment server/fileshare. This means that any modifications or deletions to those MOBJ in PY while testing…will modify or delete the file that is also used in PROD. Granted, this is a specific scenario, but I’ve run across it more than once. It should be noted that 1) text MOBJ are fine, as they are stored as a BLOB in F00165 and 2) MOBJ stored in the database (9.2 +) are also fine. But beware if you are using the old/legacy configuration of MOBJ, storing file attachments on the deployment server or a fileshare; a data refresh *could* have you saying ouch!
Best practice: Either delete all records from F00165 after a refresh, or selectively delete the records where GTMOTYPE <> 0. (0 = text MOBJ, and those are fine to stay.)
These are just a few of the special considerations or gotchas around data refreshes; as always, there are more things to consider than we have blog space to write about! We hope this will give you a few new tips or things to think about, or if you already knew these scenarios, maybe you’ll think of some new ones. Or, better yet, maybe you’ll come up with some out of the box ways to handle these scenarios, or even automate them as part of your data refresh process. We’re all about continuous improvement – especially for routine tasks like these!