Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 15 Oracle Analytics Lounge
- 214 Oracle Analytics News
- 43 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 78 Oracle Analytics Trainings
- 15 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Impact of data modification in s_nq_job table

Hello Experts,
I want to know that what will happen if someone modify the table.column "s_nq_job.user_id" related to agents.
Table Name:- s_nq_job
Column data modified:- user_id (example if user1 name is present as data and someone run the script and update the information of user1 to Test1).
Will the agent will have any impact and it will throw any error while we run ?
Kindly guide.
Thanks & Regards,
Abhi
Answers
-
First question before any others is why are you trying to do this? If User A ran a job, why would you want to change it to User B?
0 -
Why would you ever want to do that? The metadata tables are OFF LIMITS to manual intervention if you don't fully comprehend the impact.
The GUI for all the se settings writing back into these tables are there for a reason.
0 -
Hello All,
Thank you for your reply and sorry for my late reply.
Requirement is to mask the data as the GDPR regulation.
We have user-id which are present over there who has scheduled the report in agent and we have to mask the user-id.
I know that if we change the user_id to some masked id then it will give the error as authentication failed user_id/password invalid.
Kindly let me know if there is a way that we can mask the user_id information present under s_nq_job.
Thanks & Regards,
Abhi
0 -
I would consider using an Oracle Database feature called Oracle Data Redaction that is part of Oracle Advanced Security that is licensed separately.
https://docs.oracle.com/cd/E11882_01/network.112/e40393/redaction.htm#ASOAG594
0 -
Hmmm that "GDPR requirement" is questionable to say the least. That simply isn't the point of or the way GDPR works.
Once more: Those are system tables and no one should ever access them via SQL to begin with!
0