I'm attempting to align an index with a partitioned table, but the partition key column is nullable in the table definition.
In order to align the indexes I have to make this field not null, but when I attempt to alter the column on the table I receive an error saying that the table depends on that field.
You will need to remove the partition scheme from that table, correct the data issue, then repartition.
Or, create a new, properly partitioned version of the table with the right constraints and put your data into it from the old table.
Related
I'm trying to change an in-memory table column type from INT to BIGINT on SQL Server 2017. Actually, this column are the PK from table.
For a regular table, the common path is to drop the PK constraint, change the data type and recreate PK, but when I've tried in my in-memory table I got the following error:
ALTER TABLE dbo.InMemTbl
DROP CONSTRAINT PK_InMemTbl
The memory optimized table 'InMemTbl' with DURABILITY=SCHEMA_AND_DATA
must have a primary key
I'm not an expert in memory-optimized tables so is there any workaround to solve it without recreate the whole table using the new data type?
In a Stored Procedure we are using partition function. The job runs based on the period like '202001','202002' etc. For previous periods the SP was executed and now due to some data issues we are thinking to execute the SP for previous periods.
We are actually loading data into a Work Table and using partition we are switching data from Work table to main table
ALTER TABLE db_table_Work switch
TO db_table partition $PARTITION.db_table_PFPerPost(#PeriodKey);
If we execute the SP now again for past period, will it cause the data to insert again for existing rows? Or will it insert the newly updated data?
SWITCH will err if the target partition is not empty. Furthermore, the non-partitioned source table must have a check constraint on the partitioning column to ensure all rows fall within the target boundary.
If data will exist in the primary table partition during reprocessing, you'll need to ensure data in the replaced partition is not changed during reprocessing of previous periods to avoid data loss. If that is not possible, a MERGE is needed to insert/update/delete rows instead of the more efficient SWITCH.
Consider partitioning the work table using the same partition scheme as the target table to avoid the need for a check constraint. This will also facilitate moving the partition into the work table and switching back after reprocessing. Below is an example of this technique, which assumes it is acceptable for the primary table partition to be empty during reprocessing of the period:
--switch primary table partiton into work table for reprocessing
ALTER TABLE db_table
SWITCH PARTITION $PARTITION.db_table_PFPerPost(#PeriodKey)
TO db_table_Work PARTITION $PARTITION.db_table_PFPerPost(#PeriodKey);
--reprocess data here
--switch reprocessed data back into primary table
ALTER TABLE db_table_Work
SWITCH PARTITION $PARTITION.db_table_PFPerPost(#PeriodKey)
TO db_table PARTITION $PARTITION.db_table_PFPerPost(#PeriodKey);
I have a table which contains MyColumn1 with user defined datatype of CustomDatatype INT NOT NULL. I need to change this column to a VARCHAR(5), but I am getting the following errors:
Msg 5074, Level 16, State 1, Line 12
The object 'CustomDatatype' is dependent on column 'MyColumn1'.
Msg 4922, Level 16, State 9, Line 12
ALTER TABLE ALTER COLUMN MyColumn1 failed because one or more objects access this column.
This does not seem to be related to an index or foreign key reference which I would omit to drop before altering the column datatype, this seems to be directly related to the originally used custom defined datatype CustomDatatype on this column.
How can I change MyColumn1's datatype without dropping the CustomDatatype because that could create apocalyptic scenario in my system or dropping the table?
Thanks
Update (2018-07-31): I found a response to the same question in different forum where it states: "...This is the problem with UDT columns. You will need to drop all the columns of this type first in all tables (and may be in functions / SPs, views), then delete the type and create correct type, then re-create all the columns..." (Naomi 2011) from Microsoft (August 2, 2011) web: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b7bf0f04-dee8-4751-803b-4c3e1f7f7c70/how-to-change-column-nametype-of-user-defined-table-type?forum=transactsql
So far the only viable solutions I came up with are to:
Create a copy of the table (script it out with all
dependencies i.e.: triggers, indexes, keys, etc.) Drop the original
table (which is ok to do even though custom datatypes are specified) and then recreate the table again with the new datatype column.
If the table cannot be dropped (for some reason) rename the old
datatype column, create a new column with the original column name
with the right datatype. Move the data from the old (renamed) column
into the new one (make sure to mind the triggers,etc.). Then force
to recompile all the Sprocs and refresh all the views which are
dependent.
Can you check if there is any Index added for those column?
If yes,
you will need to drop and recreate the index.
once you drop the constraints and index , you can alter the column.
alter table Table1
alter column MyColumn1 varchar(5);
Then re-create constraints and index.
So far the only viable solutions I came up with are to:
1) Create a copy of the table (script it out with all dependencies i.e.: triggers, indexes, keys, etc.) Drop the original table (which is ok to do even though custom datatypes are specified) and then recreate the table again with the new datatype column.
2) If the table cannot be dropped (for some reason) rename the old datatype column, create a new column with the original column name with the right datatype. Move the data from the old (renamed) column into the new one (make sure to mind the triggers,etc.). Then force to recompile all the Sprocs and refresh all the views which are dependent.
I am trying to change datatype of a column in SQL Server from INT to BIGINT.
ALTER TABLE Table1 ALTER COLUMN ID BIGINT
However, it is giving me below error:
ALTER TABLE failed because the following SET options have incorrect settings: 'ANSI_WARNINGS'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
I checked the Table1 and there is just 1 computed column (i.e. cost * quantity kind off). There are no indexes on this particular column. Neither there is any index on ID column. The ID column of Table1 is not referred elsewhere in any other table. I tried changing ANSI_Warnings ON and OFF but still gives same error.
So I am not sure where the problem is. Any help appreciated!
I was doing the same thing the OP - alter the PK from INT to BIGINT on 2 tables. In first table it went smoothly, in second table I got same error as OP:
ALTER TABLE failed because the following SET options have incorrect
settings: 'ANSI_WARNINGS'. Verify that SET options are correct for use
with indexed views and/or indexes on computed columns and/or filtered
indexes and/or query notifications and/or XML data type methods and/or
spatial index operations.
Running SET ANSI_WARNINGS ON or OFF is not helping.
The steps are:
drop indexes
drop PK constraint
drop persisted columns
run ALTER TABLE [table] ALTER COLUMN [id] BIGINT
create persisted columns, indexes, PK constraint back as they were
To get rid of the error, there's one thing I had to do differently in step 1:
in first table it was OK to drop just indexes using the changed column, keep other indexes
in second table I had to drop all indexes, even those not using the column
Probably because your column is the Primary Key and indexed as the CLUSTERED index, then used by every NONCLUSTERED indexes...
So drop NONCLUSTERED indexes and the PK, execute the ALTER TABLE and then add the PK and all NONCLUSTERED indexes that you have dropped.
I'm trying to clean up a database table and I'd really like to drop two columns as they should no longer be being used.
'Property' table
- Unable to modify table.
The index '_dta_index_Property_7_669245439__K1_K9_K8_K24_K4_2_5_6_13_22_25_26_29' is dependent on column 'AveragePriceMta'.
The index '_dta_index_Property_7_669245439__K1_K9_K8_K24_2_4_5_6_7_13_22_25_26_29' is dependent on column 'AveragePriceMta'.
ALTER TABLE DROP COLUMN AveragePriceMta failed because one or more objects access this column.
I've gone and looked at the indexes for this table found the particular columns I want to delete in a greyed out field of "Included columns". Obviously I don't want to just drop these indexes - but is there a way to refresh the index so that I can remove the columns in question out of the non-editable included columns field?
Using SQL Server 2008 but database is 2005.. in case that matters.
Thanks for your help! :)
You can't add or remove columns to an Index. You will have to drop the index and the re-create it.
You can you use Create Index along with the Drop_Existing clause to do this.
MS Help on Create Index