Had the same problem and it could be due to your service not being able to create the socket (check with netstat -an | grep 27017 if you have it up properly)
What I did:
Create a properly placed data/db on System/Volumes/Data/data/db, with
sudo mkdir -p /System/Volumes/Data/data/db
sudo chown -R `id -un` /System/Volumes/Data/data/db
And, then, add that ...
VIEW DEFINITION is a way to explicitly GRANT or DENY metadata visibility, but it's not the only way a user gets metadata visibility.
Users implicitly get metadata visibility without the VIEW DEFINITION permission on objects they own or have some other permission on:
The visibility of metadata is limited to securables that a user either
owns or on which the ...
There is a security consequence to setting SQL92_SECURITY to false.
The configuration option SQL92_SECURITY specifies whether table-level
SELECT privileges are required to execute an update or delete that
references table column values. If this option is disabled (set to
Other than the obvious solution (grant select on data.xtest to app;), you can revert to the old behavior by setting SQL92_SECURITY to FALSE. In 11.2, its default value was FALSE, but in 19c, its default value is TRUE.
alter system set sql92_security=false scope=spfile;
Then restart the database, as this parameter can not be changed online.
Use sp_help_revlogin procedure to safely script SQL logins and their passwords (and Windows-authenticated Logins as well), so you can re-create all those logins on secondary replica with exactly same SIDs, as they have on primary replica
You can input by following:
SELECT * FROM pg_roles;
and you will get
rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcanlogin | rolreplication | rolconnlimit | rolpassword | rolvaliduntil | rolbypassrls | rolconfig | oid
maybe here you will think that there are too many roles, and this time, you can use WHERE to select what role you want ...
After a bit of hunting I realized that maybe I am getting this error because I am adding a condition to delete. Which means the database is probably selecting those records. And I hadn't granted select on the table to the user.
Grant select: grant select on table to username
And it worked.
You do not have the admin option yourself on my_role_1, so you cannot grant the role to other users. Get your DBA to grant the admin option for my_role_1 to you and you will be then be able grant the role to ktest1.
That is not how you grant privileges on a directory.
SQL> create or replace directory KIR_DOKUMENT as '/tmp';
SQL> select owner, object_type, status from dba_objects where object_name = 'KIR_DOKUMENT';
Is KIR_DOKUMENT a part of the data dictionary or did someone at your company create it? I assume that this is something that was written at your company. When the package gets executed, it is probably not using sys privileges. You probably have it set up to be run with invoker rights. If that is the case then ktest2 needs rights to do everything that the ...