I'm pretty new to DBeaver and was wondering if it had an option to revert queries that were previously ran? For instance I ran
ALTER TABLE case_arrest_forms DROP CONSTRAINT cri_arrest_dispositionsid_fkey;
From the top menu it says it's on auto-commit. Is there a way for me to roll this back or would I have to add the constraint again? Any other suggestions?
Nope, DBeaver doesn't have such kind of functionality. Can't revert query in auto-commit mode.
Also, it is not possible to return the row deleted from the table.
But to avoid such situations, you can change the level of transactions.
Related
Is it possible to automate the creation of triggers in Oracle SQL, like if a drop table command is ran, not all of your triggers have to be recreated? I didn't find anything online to solve this problem.
Thanks in advance for your answers
Put simply, no. When a table is dropped, everything associated with it goes away, including all indexes, triggers, and etc. If the table is then recreated, all the triggers must be recreated. This is hard-wired into the database, and there's no DDL statement for DROP TABLE XYZ123 EXCEPT FOR ALL THE TRIGGERS WHICH YOU CAN JUST LEAVE FLOATING AROUND IN SPACE UNTIL AND IF THE TABLE IS RECREATED;
As someone else mentioned, you might want to consider using TRUNCATE TABLE, which blows the data away but leaves everything else intact. Another option is to use a global temp table - see this article at Oracle-Base
Is there a way to prevent DROP TABLE in SQL Server somehow, simply by using SSMS and its features?
Don't give users permissions to drop tables.
You might think a DDL trigger can prevent this. It does, in a way: it lets the drop happen, then it rolls it back. Which is not quite preventing it, but I suppose it might be good enough.
Check this , There are two methods basically
The first one is based on creating a view on the table with option
SCHEMABINDING. When the SCHEMABINDING option is used the table cannot
be modified in a way that will affect the view definition, as well as
it cannot be dropped unless the view is dropped first.
The second method is using the new DDL triggers in SQL Server 2005.
Defining a trigger for DROP_TABLE with rollback in the body will not
allow dropping tables.
I have an SQL table, from which data is being deleted. Nobody knows how the data is being deleted. I added a trigger and know the time, however no jobs are running that would delete the data. I also added a trigger whenever rows are being deleted from this table. I am then inserting the deleted rows and the SYSTEM_USER to a log table, however that doesnt help much. Is there anything better I can do to know who and how the data gets deleted? Would it be possible to get the server id or something? Thanks for any advice.
Sorry: I am using SQL Server 2000.
**update 1*: Its important to find out how the data gets deleted - preferably I would like to know the DTS package or SQL statement that is being executed.
Just a guess, but do you have delete cascades on one of the parent tables (those referenced by foreign keys). If so, when you delete the parent row the entries in the child table are also removed.
If the recovery mode is set to "Full", you can check the logs.
Beyond that, remove any delete grants to the table. If it still happens, whomever is doing it has root/dbo access - so change the password...
Try logging all transactions for the time being, even if if it hurts performance. MS offers a mssql profiler, including for express versions if needed. With it, you should be able to log transactions. As an alternative to profilers, you can use the trace_build stored procedure to dump activity into reference files, then just 'ctrl-f' for any instance of the word 'delete' or other similar keywords. For more info, see this SO page...
Logging ALL Queries on a SQL Server 2008 Express Database?
Also, and this may sound stupid, but investigate the possibility that what you are seeing is not deletes. Instead, investigate if records are simply being 'updated', 'replaced if already exists', 'upserted', or whatever you like to call it. In Mysql, this is the 'INSERT ... ON DUPLICATE KEY UPDATE' statement. I'm not sure of the MSSQL variant.
What recovery model is your database in? If it is full Redgate log Rescue is free and works against SQL2000 which might help you retrieve the deleted data. The Overview Video does appear to show a user column.
Or you could roll your own query against fn_dblog
Change all your passwords. Give as few people delete access as possible.
What is the difference between drop and delete database?
Difference between DELETE and DROP commands
Delete: The DELETE command is used to
remove rows from a table. A WHERE
clause can be used to only remove some
rows. If no WHERE condition is
specified, all rows will be removed.
After performing a DELETE operation
you need to COMMIT or ROLLBACK the
transaction to make the change
permanent or to undo it. Note that
this operation will cause all DELETE
triggers on the table to fire.
Drop: The DROP command removes a table
from the database. All the tables'
rows, indexes and privileges will also
be removed. No DML triggers will be
fired. The operation cannot be rolled
back.
Simply: a DELETE command removes matching rows, a DROP command removes the entire table.
I know this is an old post, but I was looking for the answer myself, and since I believe the OP has asked about dropping or deleting the database, rather than tables or content, I thought I'd chip in.
Both will delete the database, but both could involve more than one step if you want to completely remove the database and associated artefacts.
DELETE
If you are using SQL Server Management Studio, you can delete the database by right clicking on the database and selecting Delete. The resulting dialog offers a couple of checkboxes :
'Delete backup and restore history information for databases'
'Close Existing connections'
If you don't tick 'Delete backup and restore history..' , those files will remain on the server unless you manually get rid of them.
'Close Existing connections' is a good idea, otherwise you may get an error telling you the database is still in use (even if it's just you, while you're trying to delete it)
DROP
The SQL Command 'DROP' alone will not remove everything. You will still need to also remove the backup history, and set the database to 'single user mode' - or it may complain the database is still in use, as above.
--Remove backup history
EXEC msdb.dbo.sp_delete_database_backuphistory #database_name = N'YourDBName'
GO
USE [master]
GO
--close all the open connections to your database
ALTER DATABASE [YourDBName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
USE [master]
GO
--remove the actual database
DROP DATABASE [YourDBName]
GO
Delete removes content and drop the structure of a database.
Delete removes content of table.Drop removes content and structure of table.Delete can be rolled back but Drop can not be rolled back
Suppose you are using MS SQL
Then if you want to delete the whole Table then you would use:
DROP TABLE MyTable
This would delete the whole table and its constraints
To delete any specific row you would use:
DELETE FROM MyTable WHERE id=5
This would delete the row with the id = 5
If no conditions are matched it would delete all rows
DROP removes the entire table and associated objects from the catalog, requiring you to create all the indexes and constraints from scratch.
Drop in a function that physically removes and particular table or a column. The table struction remails same. If you want to see the structure, you can write this
desc tablename; and the structure will be same after dropping the table.
Delete function permanantly deletes the table or a column, the structure of the table also.
Is there a simple way to drop a group of interrelated tables in SQL Server? Ideally I'd like to avoid having to worry about what order they're being dropped in since I know the entire group will be gone by the end of the process.
At the risk of sounding stupid, I don't believe SQL Server supports the delete / cascade syntax. I think you can configure a delete rule to do cascading deletes (http://msdn.microsoft.com/en-us/library/ms152507.aspx), but as far as I know the trick with SQL Server is to just to run your drop query once for each table you're dropping, then check it worked.
I'm not sure, if Derek's approach works. You haven't mark it as best answer yet.
If not: with SQL Server 2005 it should be possible, I guess.
There they introduced exceptions (which I've not used yet). So drop the table, catch the exception, if one occurs and try the next table till they are all gone.
You can store the list of tables in a temp-table and use a cursor to traverse it, if you want to.
A diferent approach could be: first get rid of the constraints, then drop the tables in a single shot.
In other words, a DROP CONSTRAINT for every constraint, then a DROP TABLE for each table; at this point the order of execution shouldn't be an issue.
This requires the sp___drop___constraints script you can find at Database Journal:
sp_MSforeachtable #command1="print 'disabling constraints: ?'", #command2="sp_drop_constraints #tablename=?"
GO
sp_MSforeachtable #command1="print 'dropping: ?'", #command2="DROP TABLE ?"
GO
NOTE this - obviously - if you meant to drop ALL of the tables in your database, so be careful
I don't have access to SQL Server to test this, but how about:
DROP TABLE IF EXISTS table1, table2, table3 CASCADE;
I ended up using Apache's ddlutils to perform the dropping for me, which sorted it out in my case, though a solution which worked only within sql server would be quite a bit simpler.
#Derek Park, I didn't know you could comma separate tables there, so that's handy, but it doesn't seem to work quite as expected. Nether IF EXISTS nor CASCADE are recognised by sql server it seems, and running drop table X, Y, Z seems to work only if they should be dropped in the stated order.
See also http://msdn.microsoft.com/en-us/library/ms173790.aspx, which describes the drop table syntax.
The thing holding you back from dropping the tables in any order are foreign key dependencies between the tables. So get rid of the FK's before you start.
Using the INFORMATION_SCHEMA system views, retrieve a list of all foreign keys related to any of these tables
Drop each of these foreign keys
Now you should be able to drop all of the tables, using any order that you want.