Using PostgreSQL 9.4.12, I created a new database called new_db and before adding any table or any other object to it and probably before registering it (I don't remember if I've registered or not), I dropped it. Now, it still shows in database list in SQLmanager:
and when I attempt to drop it via following query:
drop database new_db;
it says:
database doesn't exist
But when I open 'database registration manager', it lists 'new_db' and shows the register check box as marked:
and when I try to remove the mark and apply the changes it displays an error that isn't relevant to the 'new_db' database.
Following query also results 0 rows:
select oid, * from pg_database where datname like
'new_db';
How can I remove the database from the list in SQLmanager?
SQL Manager creates new_db (asdefault anme) on first connection. After that it registers it. If you just drop database and don't unregister it the "alias" remains. You have to right click on new_db and "unregister database"
Related
In SQL Server Database Engine I have a table named Table A.
I deleted the table using graphical interface, but when I wanted to create a table with same name, the error shows
The object already exists
What is the remedy of this situation?
The following steps should help you track down what is going on and help you create your table:
Right-click on your database and select refresh
Verify that your table does not exist under this database.
If you table is
not shown here, then very likely your table is displayed under the
master database.
To create a table in your selected database,
first select the database and then run your query.
A better
option for number 4, just to be sure you are specifying the correct
database is to run the command use dbname; (where dbname is
the name of your database). Do this on the line above your create table code.
Is it possible to use views with WebSQL? I assume it is because it is basically sqlite which definitely allows it, but I might as well be wrong. I am trying to create a view in my local sqlite database but it fails no matter what I do. Here are some of the things I've tried so far;
create view my_view as select id, name from my_table where active = 1;
--fails: could not prepare statement (1 no such table: main.my_table)
Why does it search for table 'my_table' in the 'main' database? I was not even aware of the 'main' database. I assume it is some system database that is there by default. The database that I open is labeled 'my_database'. All the other sql statements seem to respect that. The 'create view' is the only one that looks like it operates outside of the opened database.
create view my_view as select id, name from my_database.my_table where active = 1;
--fails: could not prepare statement (1 view my_view cannot reference objects in database my_database)
This is what specifically makes me believe that the 'create view' statement operates outside of the opened database.
create view my_database.my_view as select id, name from my_database.my_table where active = 1;
--fails: could not prepare statement (1 unknown database my_database)
This one confuses me the most. How can there be that the 'my_database' database is unknown? I can assure you that I am using this database for quite a bunch of other statements such as select, insert, update, delete and all of them work perfectly fine. It is only for the 'create view' that this database is unknown.
create view my_database.my_view as select id, name from my_table where active = 1;
--fails: could not prepare statement (1 unknown database my_database)
I even tried to run these one at a time before the 'create view':
attach 'my_database.db' as my_database;
--fails: could not prepare statement (23 not authorized)
attach 'my_database.sqlite' as my_database;
--fails: could not prepare statement (23 not authorized)
Any help is greatly appreciated. Thanks.
The default database (the database you opened) is always called main.
You get the error "no such table: main.my_table" because your database does not contain a table called my_table.
On our original design we screwed up a foreign key constraint in our table. Now that the table is full of data we cannot change it without dropping all of the records in the table. The only solution I could think of is to create a backup table and put all of the records in there, then delete all the records, alter the table and start adding them back. Any other (BETTER) ideas? Thanks!
Using MS SQL Server
I'm a bit late, just for reference.
If You are using SQL Server Management Studio, You could generate a DROP and RECREATE script with "Keep schema and data" option.
Right click on the desired DB in object explorer
Tasks > Generate scripts
Select the table you want to script
Then clicking on Advanced button
"Script DROP and CREATE" ->"Script DROP and CREATE"
"Types of data to script" -> "Schema and data"
Hope this helps
Here's some pseudo-code. No need to make a backup table, just make a new table with the right constraint, insert your records into it, and rename.
CREATE TABLE MyTable_2
(...field definitions)
<add the constraint to MyTable_2>
INSERT INTO MyTable_2 (fields)
SELECT fields
FROM MyTable
DROP TABLE MyTable
exec sp_rename 'MyTable2', 'Mytable'
Using SQL Server Management Studio (SSMS), you can use it's table designer to specify the final condition of the table. Before saving the changes, have it generate the change script and save that script. Cancel out of the design window, open the script and review it. SSMS may already have generated a script that does everything you need, fixing the primary-foreign key relationship while preserving all existing data. If not, you will have a script, already started, that performs most of what you need to do and should be able to modify it for your needs.
This is your only solution.
Create the backup table, empty the original one, modify the table and then insert step-by-step until you find a violation.
Update All Schema Database Old by new Schema Database .
Create script (Right click on the desired DB in object explorer Tasks > Generate scripts -> select option select specific database objects and tables ->next -> advanced-> option Type of data to script Data only -> ok ->next ->next.) to data only and backup Database to old database
Drop database old and create new database and make new DB is empty .
Excute script of Old Data only on new database .
I have a temporary table, that isn't going away. I want to see what is in the table to determine what bad data might be in there. How can I view the data in the temporary table?
I can see it in tempdb. I ran
SELECT * FROM tempdb.dbo.sysobjects WHERE Name LIKE '#Return_Records%'
to get the name of the table.
I can see it's columns and its object id in
select c.*
from tempdb.sys.columns c
inner join tempdb.sys.tables t ON c.object_id = t.object_id
where t.name like '#Return_Records%'
How can I get at the data?
By the way, this doesn't work
SELECT * FROM #Return_Records
One way of getting at the data in a low-level and not particularly easy to manipulate manner is to use the DBCC PAGE command as described in a blog post by Paul Randal:
http://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/10/625659.aspx
You should be able to find the fileid and page number of the first page in the object by querying on sysindexes .. the last time I did this was on SQL Server 7.
If the data is in the database, then DBCC page will be able to dump it.
pjjH
SQL Server limits access to Local Temp Tables (#TableName) to the connection that created the table. Global temp tables (##TableName) can be accessible by other connections as long as the connection that created it is still connected.
Even though you can see the table in the table catalog, it is not accessible when trying to do a SELECT. It gives you an "Invalid Object Name" error.
There's no documented way of accessing the data in Local Temp Tables created by other connections. I think you may be out of luck in this case.
This is something that seems like you obviously tried, but since you didn't mention it I though I would mention just in case:
Did you try "SELECT * FROM #Return_Records"?
Like José Basilio says, that's a temporary table belonging to another connection. If it's there for a long time, it must belong to a connection that has been open for a long time. Check Maintenance -> Acitivity Monitor; you can sort by Login Time.
Check if the Login Time, or Last Batch Time, matches with the create date of the temporary table. That can be retrieved with:
select crdate from tempdb.dbo.sysobjects WHERE Name LIKE '#Return_Records%'
You can shoot down suspect connections (right click and Kill Process.) If the table is gone after killing a process, you've found the culprit.
To just remove the table, restart the SQL Server service. You can attach SQL Profiler right after with a filter to start looking for the connection that creates the temporary table.
I need to rename the database but when I do in
PGAdmin : ALTER DATABASE "databaseName" RENAME TO "databaseNameOld" it told me that it cannot.
How can I do it?
(Version 8.3 on WindowsXP)
Update
The first error message : Cannot because I was connect to it. So I selected an other database and did the queries.
I get a second error message telling me that it has come user connect. I see in the PGAdmin screen that it has many PID but they are inactive... I do not see how to kill them.
Try not quoting the database name:
ALTER DATABASE people RENAME TO customers;
Also ensure that there are no other clients connected to the database at the time. Lastly, try posting the error message it returns so we can get a bit more information.
For future reference, you should be able to:
-- disconnect from the database to be renamed
\c postgres
-- force disconnect all other clients from the database to be renamed
SELECT pg_terminate_backend( pid )
FROM pg_stat_activity
WHERE pid <> pg_backend_pid( )
AND datname = 'name of database';
-- rename the database (it should now have zero clients)
ALTER DATABASE "name of database" RENAME TO "new name of database";
Note that table pg_stat_activity column pid was named as procpid in versions prior to 9.2. So if your PostgreSQL version is lower than 9.2, use procpid instead of pid.
I just ran into this and below is what worked:
1) pgAdmin is one of the sessions. Use psql instead.
2) Stop the pgBouncer and/or scheduler services on Windows as these also create sessions
Unexist told me in comment to restart the database and it works! Restarting the database kill all existing connection and then I connect to an other database and was able to rename it with my initial query.
Thx all.
Instead of deploying a nuke (restarting the server) you should try to close those connections that bother you either by finding where are they from and shutting down the client processes or by using the pg_cancel_backend() function.
When connected via pgadmin, the default database will be postgres.
ALTER DATABASE postgres RENAME TO pgnew;
This will not work.
You need to right click on server in pgadmin and set Maintenance DB to some other DB and save. Then retry and it should work if no other connections exists.
For anyone running into this issue using DBeaver and getting an error message like this:
ERROR: database "my_stubborn_db" is being accessed by other users
Detail: There is 1 other session using the database.
Disconnect your current connection, and reconnect to the same server with a connection that doesn't target the database you are renaming.
Changing the active database is not enough.
ALTER DATABASE old_database RENAME TO new_database;
old_database means already existing database.
new_database means need to modify this name.
Example: ALTER DATABASE profile RENAME TO address;