Modify USER column in Batch Versions

[njcncadmin]

We have a bunch of older interactive and batch versions in Production that have version security set to 1 and the userid in the USER column in BV is a userid that no longer exists. Rather than recreating the necessary userids and going through a bunch of checkouts and checkins, we'd like to use SQL instead.

We know that the USER column is actually the VRUSR0 column in the F983051. Using SQL, we plan on just updating VRUSR0 to a generic userid that will never get deleted. Does anyone see any potential issue with using SQL to do this?

Our new process is to make sure all new versions that need version security set to something other than 0 will be owned by the generic userid prior to migrating to Production.

 

[jstooge]

Suggest backing up the table first, but this should be a harmless change. Done it many times for the same reason you outline. Of course, if you have any SOX auditors watching, you need to be sure to document the process and reason why DB changes are needed, test it adequately in each of your verification environments, get the appropriate sign off's at each level, then perform it at the production level and insert the appropriate FASB GAAP blurbs in your annual report!

 

[SULLY1]

We created a UBE to change the user to the person who runs the UBE after being prompted for object name and version. My two cents.

Patty

 

[njcncadmin]

Thanks for the help.