If I rename SQLite Tables/Columns/Rows after indices have been created, will the old indices still be functional?
Thanks!
If you're using ALTER TABLE with RENAME TO to rename a table, then as described on this page (from the sqlite docs) the indices will still work:
The ALTER TABLE command in SQLite allows the user to rename a table [...] If the table being renamed has triggers or indices, then these remain attached to the table after it has been renamed.
But note there's no renaming of columns allowed. This is one of the SQL features not implemented by sqlite:
Only the RENAME TABLE and ADD COLUMN variants of the ALTER TABLE command are supported. Other kinds of ALTER TABLE operations such as DROP COLUMN, ALTER COLUMN, ADD CONSTRAINT, and so forth are omitted.
Rows don't have names (except in the sense of having a PK) so there's not really a way of renaming them.
I highly recommend using Rails ActiveRecord migrations to maintain your database. This can be done outside of Rails. So you app doesn't need to be a Rails app to use rake tasks
See here for an excellent blog on how to do this http://exposinggotchas.blogspot.com/2011/02/activerecord-migrations-without-rails.html
Yes, the old indices will still be functional.
Be aware, that sqlite doesn't care about the names for the indexes. Initially when an index is created usually they are named after the table and field, so when you rename the table, the indexes will still have the name of the old table in it. This can cause problems, when you for example:
dump the table
rename the old table:
sqlite3 "$DB" "PRAGMA busy_timeout=20000; ALTER TABLE '$TABLE' RENAME TO '$TABLE"_backup"'"
reimport the dumped table
This will cause an error, that the indexes already exist.
Solution: Rename the indexes too, or delete them in the renamed table before you reimport the original (see this answer).
Related
I want to alter all varchar columns in my database to nvarchar, using a T-SQL script.
There are a lot of dependencies (keys, constraints, and views) that cause problems when trying to alter.
The object 'X' is dependent on column 'Y'. ALTER TABLE ALTER COLUMN 'Y' failed because one or more objects access this column.
My unsuccessful attempts: forcing a change with PowerShell, and creating a generate script for the whole database and using that to create a copy with all the changes I need. These attempts didn't work, because I lost the table data and the generate scripts were too big for any program to handle.
How does one create all DROP and CREATE scripts of the objects that cause problems when trying to alter to make the changes and recreate the database schema like it was before altering?
I recently used - EXEC sp_rename '<source table name>', '<destination table name>' to rename an existing table and want to execute the same on one of our live server. Is there any issue in using this procedure to rename a table?. I am asking this because one of our DBA says there will be problems in using this procedure on live server.
Is nothing referencing the table you're renaming? That would be the only instance where I would think renaming the table would not have an impact. If the table was not referenced by anything however, what would be the purpose of the table?
you can read more about sp_rename here:
http://msdn.microsoft.com/en-us/library/ms188351.aspx
Specifically note the following:
Renaming an object such as a table or column will not automatically
rename references to that object. You must modify any objects that
reference the renamed object manually. For example, if you rename a
table column and that column is referenced in a trigger, you must
modify the trigger to reflect the new column name. Use
sys.sql_expression_dependencies to list dependencies on the object
before renaming it.
There is no major issue with renaming the table using that procedure. The only thing you need to remember is that while that command is being executed, the locks that are applied on that table won't allow you to query the data, but that should only take only a couple of milliseconds, so you should be fine.
P.S. Don't forget to modify your views, procedures, functions etc :)
Below is the only caution as described inthe microsoft official web site.
Changing any part of an object name can break scripts and stored procedures. We recommend you do not use this statement to rename stored procedures, triggers, user-defined functions, or views; instead, drop the object and re-create it with the new name.
More details at : http://msdn.microsoft.com/en-us/library/ms188351.aspx
EXEC sp_rename is recommended only when we sure that all the depended SP, View function are not get affected. Make sureyou changed or deleted the depended objects.
Perhaps your DBA can share the details of his/her concerns. Renaming a table will of course be a breaking change for any objects that reference the table so you'll need to perform due diligence to ensure dependent objects are changed to use the new name. The rename operation will also require a short schema modification lock and void existing referencing cached plans, so be aware of this if the table is heavily used.
Database: Oracle 11g R2
Tool: TOAD for Oracle 10.6
I wanted to take backup of a table. Hence, I used the below query:
CREATE TABLE table_backup AS (
SELECT *
FROM table
);
I would require to make some changes to the table and restore it to the previous version after verifying the changes.
For that, I would DROP the table and restore it from its backup using the above query again.
My question is, when I do it, do all the grants, indexes, partitions, etc. remain in the restored table or not?
Also, is there a better way to achieve my requirement.
The documentation says:
Dropping a table invalidates dependent objects and removes object privileges on the table. If you want to re-create the table, then you must regrant object privileges on the table, re-create the indexes, integrity constraints, and triggers for the table, and respecify its storage parameters.
Noen of the grants, indexes, partition etc. are moved or copied when you do you create table as ... select statement. There is no relationship between the original and copied tables. When you drop the original table all its grants etc. are lost. Renaming the backup table to the original doesn't magically restore them.
Other options include:
export the original table including grants. After making your changes, drop the table and re-import it.
rename your original table, which will retain the grants etc.; then recreate the table with the original name (maybe as a select from the renamed one). When you're done, drop the new table and rename the old one back to its original name. But be careful - don't get carried away and drop the real table by mistake. If your verification needs any of the grants etc. then you'd have to apply those to the new table; indexes would need different names which might complicate this.
duplicate the table in a different schema (e.g. with export/import) and test you changes there, then throw it away. Again being careful about which copy you're working on/dropping. You can duplicate related tables if necessary to maintain integrity.
drop the original table, recreate it, modify it and verify, then drop it again; and use flashback drop to restore the original table. You need to be sure your flashback it set up to support this - so it has to be big enough to hold both dropped tables, for example. Fast but import/export might be safer.
revert your individual changes one by one, which is risky if you're testing the changes - easy to miss something.
You also need to consider any referential constraints (PK/FK) and whether they would be affected by a rename or drop/recreate/export/import.
After dropping the table, found that the index created on the columns of the dropped table is gone. I just want to know what happens after that. Could someone please explain?
What all are the others getting dropped along with table drop?
In Oracle when dropping a table
all table indexes and domain indexes are dropped
any triggers defined on the table are dropped
if table is partitioned, any corresponding local index partitions are dropped
if the table is a base table for a view or if it is referenced in a stored procedure, function, or package, then these dependent objects are invalidated but not dropped
In Postgres
DROP TABLE always removes -
1. any indexes
2. rules
3. triggers
4. constraints
that exist for the target table.
MySQL also drops table indexes when tables are dropped.
For more info, see Does dropping a table in MySQL also drop the indexes?
By default, MS Sql Server also drops indexes when a table is dropped.
(Observed in version 13.0.4206.0.)
I would like to rename an index. I've looked at the alter table documentation, but I can't figure out the syntax to simply rename an index. When doing it through the MySQL GUI, it drops the index, and creates a new one. While this works, I would like to avoid rebuilding the entire index just to change the name of an index.
[ADDITIONAL INFO]
In the alter table documentation it states
Alterations that modify only table
metadata and not table data can be
made immediately by altering the
table's .frm file and not touching
table contents. The following changes
are fast alterations that can be made
this way:
* Renaming a column or index.
However, when I tried to rename the index by editing the .frm file (on a test database) and restarting the server, it now states "Could not fetch columns" in the UI when trying to list the columns, and when trying to run a query, it returns the error "Unknown table engine ''". The .frm file has a lot of binary content. Is there a good tool for editing the binary info.
I answered this question in 2009. At that time there was no syntax in MySQL to rename an index.
Since then, MySQL 5.7 introduced an ALTER TABLE RENAME INDEX syntax.
http://dev.mysql.com/doc/refman/5.7/en/alter-table.html says in part:
RENAME INDEX old_index_name TO new_index_name renames an index. This is a MySQL extension to standard SQL. The content of the table remains unchanged. old_index_name must be the name of an existing index in the table that is not dropped by the same ALTER TABLE statement. new_index_name is the new index name, which cannot duplicate the name of an index in the resulting table after changes have been applied. Neither index name can be PRIMARY.
Earlier versions of MySQL, e.g. 5.6 and earlier, support no syntax in ALTER TABLE to rename an index (or key, which is a synonym).
The only solution was to ALTER TABLE DROP KEY oldkeyname, ADD KEY newkeyname (...).
There is no ALTER INDEX command in MySQL. You can only DROP INDEX and then CREATE INDEX with the new name.
Regarding your update above: perhaps the documentation isn't precise enough. Regardless, there's no SQL syntax to rename an index.
An index is a data structure that can be rebuilt from the data (in fact it's recommended to rebuild indexes periodically with OPTIMIZE TABLE). It takes some time, but it's a commonplace operation. Indexes data structures are separate from table data, so adding or dropping an index shouldn't need to touch the table data, as the documentation says.
Regarding the .frm file, MySQL does not support editing the .frm file. I wouldn't do it for any reason. You are 100% guaranteed to corrupt your table and make it unusable.
For MySQL 5.7:
ALTER TABLE tbl_name RENAME INDEX old_index_name TO new_index_name
For MySQL older versions:
ALTER TABLE tbl_name DROP INDEX old_index_name, ADD INDEX new_index_name (...)
See http://dev.mysql.com/doc/refman/5.7/en/alter-table.html
This question was asked ages ago, and was last updated over half a year ago.
Still I feel the need to add this tip:
If the indexed column is used elsewhere as a foreign key, you may encounter an error related to that. Doing this may help:
SET FOREIGN_KEY_CHECKS = 0;
ALTER TABLE tbl DROP INDEX index_name;
ALTER TABLE tbl ADD INDEX new_index_name (indexed_column);
SET FOREIGN_KEY_CHECKS = 1;
Hope someone finds this useful.