I have a smalldatetime column that I need to alter to be a datetime column. This is something that will be part of an install process, so it cannot be a manual procedure. Unfortunately, the column has a few indexes and a not null constraint on it. The indexes are performance related and would need to be retained only using the new data type. Is it possible to write a statement that will allow me to retain the relevant information while still altering the column datatype? If so, how can this be done?
相关问题
- SQL join to get the cartesian product of 2 columns
- sql execution latency when assign to a variable
- Difference between Types.INTEGER and Types.NULL in
- What is the best way to cache a table from a (SQL)
- php PDO::FETCH_ASSOC doesnt detect select after ba
The best thing to do is to create a procedure that returns the index script of a given table / column. So you can remove the indexes just from the column being altered and not all indexes from the table, whereas creating indices can be somewhat expensive.
Rebuild the indexes stored in the datatable
You can not change the datatype from smalldatetime to datetime with the indexes, unique constraints, foreign key constraints or check constraints in place. You will have to drop them all prior to changing the type. Then:
Then recreate the constraints and indexes that still apply.
Some different approaches for generating the drop and creates:
1) If you have given explicit names to all indexes and constraints then your installer can run a static script in each environment (dev, test, user acceptance testing, performance testing, etc, production.)
To generate this explicit script you can: a) Use SSMS (or with SQL Server 2000, enterprise manager) to script the create and drop statements. b) Work from you source code repository to discover the names and definitions of the dependent objects and put together the appropriate static script. c) Attempt to run the alter statement. See what it fails on. Look up the definitions and hand write the drop and create. (Personally, this would be great for writing the drop, not so good at the create.)
2) If you have not given explicit names to all indexes and constraints, then your installer will have to query the data dictionary for the appropriate names and use dynamic SQL to run the drops, in the correct order, prior to the alter column statement and then the creates, in the correct order, after the alter column.
This will be simpler if you know that there are no constraints, and just indexes.
There may be tools or libraries that already know how to do this.
Also, if this is a packaged application, you may not be assured that the local DBAs have not added indexes.
NOTE: If there is a unique constraint, it will have built an index, which you will not be able to drop with DROP INDEX.
If you are just changing the size, the Index will still remain on the table.
If you are changing the data type, then you will get an error message stating that objects depend on the column that you are trying to change and therefore you will not be able to change it.
You can script out the indexes in question manually or via script. In SSMS, right click the table and script out the object in question.
If you want programatic index scripting, here is a stored proc that I have been using that I got from an ex colleague of mine.
EDIT: It depends on the original and changed datatype. If you try to alter a column from varchar to nvarchar, it will fail. Whereas, if you alter column from varchar(16) to varchar(32), it will succeed.
If you change the type of a column, then all indexes that use that column will have to be rebuilt.
But unless you have huge volumes of data (or run 24/7), rebuilding indexes is no big deal. Just schedule a maintenance window.