I am not able to drop a user created by me which has administrative rights.
I am running below command:
drop user GOVIND CASCADE;
This is the error I am getting:
ERROR at line 1:
ORA-28014: cannot drop administrative users
set _oracle_script to TRUE and execute drop command as below.
alter session set "_oracle_script"=true;
Session altered
drop user APEX_050000 cascade;
User dropped.
Related
I am trying to setup a simple web application with postgres. After I have the application running (no database related code yet).
I added a postgres db addon to app with the command heroku addons:create heroku-postgresql:hobby-dev --app <app_name>
Ran heroku psql heroku pg:psql --app.
Attempted to create a table from the prompt: CREATE TABLE example_table ( a INTEGER );
I see the error:
ERROR: no schema has been selected to create in
LINE 1: CREATE TABLE example_table ( a INTEGER );
Skimming the docs, it looks like users have the permission to CREATE. I am not sure what no schema means for postgreSQL.
Note: I also ran the command DROP OWNED BY current_user CASCADE; (successfully) - it was on top of a setup .sql script to clean, create tables and constraints and add sample data. Unsure if that can affect anything here.
https://dba.stackexchange.com/a/106067/30035
also try first to:
set search_path to "$user", public;
and if it does not help - try granting privs as from link above
It was the command DROP OWNED BY current_user CASCADE;, I reset the database and everything is working as expected. Re-ran the DROP OWNED BY current_user CASCADE; and the problem re-appeared.
Answer would be to avoid that command. Use Heroku reset command instead :
heroku pg:reset --app <app_name>
Extracted code from documentation,
create table sales_catalog(
item_id varchar(10) not null primary key,
item_name_desc varchar(50) not null,
item_desc varchar(50));
Error after using SYSDBA as the user in Firebird SQL3.
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
CREATE TABLE SALES_CATALOG failed
There is no privilege for this operation.
I did some experimenting, and the problem seems to be that if you connect to a database using ISQL without specifying a host name, it will use Firebird embedded to connect to the database (previous versions of Firebird didn't do that on Windows).
Firebird embedded does not require a username and password as it assumes that if you have direct read/write access to the database, that you are allowed to connect to it.
When you connect without specifying a username and password (eg using connect 'database.fdb' instead of connect 'database.fdb' user sysdba, Firebird embedded will use your OS username to connect.
This can be checked because ISQL reports the username when connecting:
SQL> connect 'd:\data\db\fb3\dbofnormal.fdb';
Database: 'd:\data\db\fb3\dbofnormal.fdb', User: MARK
Firebird 3 added new metadata privileges, for example creating a table in a database now requires that you are either the owner of the database (the username used in the create database statement), sysdba (or another admin user), or that you have the create table privilege. See also User Privileges for Metadata Changes. In earlier version any user would be allowed to create tables once they had access to the database.
Now on to the problem: the user (in my example MARK), does not have the create table privilege, so attempting to do so will fail:
SQL> create table testmark ( id integer generated by default as identity primary key);
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-CREATE TABLE TESTMARK failed
-There is no privilege for this operation
There are a few ways to solve this:
Specify a user with sufficient privileges in the connect statement (eg sysdba):
connect 'database.fdb' user sysdba;
Include the host name in the connect statement to connect through Firebird server instead of Firebird embedded, so that you are required to specify user name and password:
connect 'localhost:database.fdb' user sysdba password 'masterkey';
Connect once to your database as sysdba (see first item), and give the necessary privileges to the user (in my case mark):
grant create table to user mark;
From this moment forward this user can create tables (you may need to grant additional privileges, eg create view, create procedure, etc).
I am trying to edit PostgreSQL schema script and make it executable in Oracle (Oracle Express). In PostgreSQL were under the each CREAT TABLE these commands:
ALTER TABLE table_name OWNER TO user;
For example table_name is appuser and user is projectX.
The table is successfully created, but there is an error: ORA-01735: invalid ALTER TABLE option
I have also created another user in my scheme (projectX), but the error is still there. So I am confused. Does this command ALTER TABLE table_name OWNER TO user; even exists in Oracle database?
I'm trying to rename a database in my Redshift cluster.
You cannot rename the database when you're connected to it so I've created a temporary database, reconnected with SQL Workbench to the temporary db and issued:
ALTER DATABASE olddb RENAME to newdb;
I get an error stating ERROR: database "olddb" is being accessed by other users [SQL State=55006]
I've checked who is connected and there appear to be some connections from user rdsdb to the database. I assume this is a service account that AWS Redshift use to perform maintenance tasks etc.
How can I rename the database when this superuser is connected?
Many thanks.
You cannot alter the name of (or delete!) the database that is created during the initial cluster creation. I don't believe this is mentioned in the docs but I've confirmed it with them.
We can change the database name which is already created.
Detailed steps on how to do
Connect to the old database and create a new database if you do not have another one already.
create database databasebasename
In this example, I will call the databasename as 'newdb'.
Connect to newdb using connecting string as, jdbc:redshift://.us-east-1.redshift.amazonaws.com:8192/newdb, with the same password and username of your superuser (or the other eligible users as mentioned above).
Now you can alter the database name. Substitute 'database_name_new' with the desired databasename.
alter database old-db-name rename to database_name_new;
If there are any active sessions, you'll have to kill them. To find the pid of active sessions:
select * from STV_SESSIONS where user_name='rdsdb';
Then to kill a session:
SELECT
pg_terminate_backend(<pid>)
FROM
pg_stat_activity
WHERE
-- don't kill my own connection!
procpid <> pg_backend_pid()
-- don't kill the connections to other databases
AND datname = '<old-db-name>';
Once complete, you can connect back to that new database using the new name in the connection string as
jdbc:redshift://<cluser-id>.us-east-1.redshift.amazonaws.com:8192/database_name_new
You can delete the temporary 'newdb'.
drop database databasebasename
That's possible now -- I just renamed the database that was created during the initial cluster creation.
We had a similar situation.
Step 1: Connect to the database which is not the one you are trying to rename. Check the same by executing SELECT CURRENT_DATABASE();.
Step 2: Execute the query below -
SELECT
ss.*, 'select pg_terminate_backend('||process||');'
FROM
stv_sessions ss
ORDER BY
db_name;
The output of the query will have a column at the end with the select statements. Execute those to kill the sessions.
Step 3(Optional): If you are not the owner of the database try to modify the ownership of the database -
ALTER DATABASE <database to be renamed>
OWNER TO <user which is going to do the rename>;
Step 4: Rename the database
I need to grant access of existing login into my database and change password of other login from a T-SQL script that is run from C++ update program in transaction. It should run against SQL Server 2000 and also against any newer SQL Server version.
CREATE USER FOR LOGIN and ALTER LOGIN WITH PASSWORD are not supported in MSDE and SQL Server 2000 but I'm not able to use sp_grantdbaccess and sp_password either because they fail with error -2147217900
That I think is caused by the fact that these stored procedures cannot be run from user transaction and it can also be deprecated in future SQL Server versions.
Can you suggest any other solution?
Below is the sample of the script that is run in user transaction
CREATE PROCEDURE [dbo].[_PasswordChangeSaveCleanup]
#Meno varchar(50),
#HesloEncrypted varchar(50)
AS
BEGIN
...
return 1
END
GO
--CREATE USER [some] FOR LOGIN [some]
EXECUTE sp_grantdbaccess #loginame='some'
GO
GRANT SELECT ON [dbo].[UZivatelia] TO [ese]
GO
--ALTER LOGIN SOME2 WITH PASSWORD='vreK.BH45'
EXECUTE sp_password #new='vreK.BH45',#loginame='SOME2'
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[SOMESP]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[SOMESP]
GO