Cannot delete column with only null values when BlockOnPossibleDataLoss=true - sql-server

I'm using a blue-green deployment strategy with expand contract database pattern. To achieve that on my database deploy schema I've setted the property BlockOnPossibleDataLoss=true because on Expand phase I can modify my database without any break change with the old version.
I had a column that is not necessary anymore so I followed those steps:
I've changed this column to allow null values
Then my new records don't fill this column anymore
I ran a script that setted null for this column to all table records
Now I need to delete this column, but even with all records with NULL value for this column I can't because I got this error:
Rows were detected. The schema update is terminating because data loss
might occur.'
How can I delete this column even using BlockOnPossibleDataLoss=true?

Create the table with the new schema (without the column you wan't to drop) with a temporary name. Something like tmp_YourTable (Not a temporary table)
Insert all data from the source table, to the newly created table
Drop the source table
Rename the new table, to the old table name. EXEC sp_rename 'tmp_YourTable', 'YourTable';

Related

SQL Server Computed Column that doesn't affect existing data

is that possible to do a computed column without affecting existing data?
I have a unique index column named
"BookingNo"
For newly insert Column I want it to be following this format
(format([CreationTime],'yyMMddHHmmssff'))
I tried used Computed Column but it modified all my existing data.
my existing BookingNo format was
201800123
Is there anyway to generate via database? Or we have insert via code?
You could just add a default constraint:
ALTER TABLE TableName
ADD CONSTRAINT DF_BookingNo DEFAULT(format(SYSDATETIME(),'yyMMddHHmmssff'))
FOR BookingNo
This way you will get the value only for newly created rows.
Please note that if this column has a unique constraint on it some inserts might fail if they are executed at the same time.

SQL Server 2012: ALTER TABLE ALTER COLUMN MyColumn1 fails because one or more objects access this column

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.

Renaming ROWCOLGUID column when table has a FILESTREAM column

I have a table for storing document content with a FILESTREAM column, and another column which is a ROWGUIDCOL column (required when you have a FILESTREAM column). I want to migrate this table with its existing data, into a slightly new structure as part of a code refactor so that 2 different projects can reuse code to manage their document records.
The problem is that I want to rename the ROWGUIDCOL column, so that both projects have the same column definitions for their document tables.
I can't use sp_rename because it doesn't work on ROWGUIDCOL columns.
I can't drop the existing ROWGUIDCOL column (and then add the replacement) because I get an error "A table that has FILESTREAM columns must have a nonnull unique column with the ROWGUIDCOL property."
I can't add the new ROWGUIDCOL column (and then drop the redundant original) because I get an error "Duplicate column specified as ROWGUIDCOL"
Is there any solution to this problem? Do I have to backup all the document content (the FILESTREAM column) and drop this first, then do the ROWGUIDCOL change, and then put the FILESTREAM content back in?
Consider creating the new table with a different name for the migration. Then load with INSERT...SELECT (mapping columns as desired), drop the original table, and finally rename the new table to the original name.

Duplicating column to same table in PostgreSQL

I'm looking to rename a column in PostgreSQL with no downtime. My code will depend on the column name so I'd like to duplicate the column with a new name along with the contents and data type of the existing column, then push the code changes before deleting the original column. Is there a Postgres command for duplicating a column with its contents into the same table?
I found a relatively simple way to do this in two commands:
ALTER TABLE mytable ADD COLUMN "new_column" <DATA TYPE STUFF FROM OLD COLUMN>;
UPDATE mytable SET new_column = old_column;
Didn't realise it would be this easy. I didn't lock the table as that column isn't used too frequently so a small slowdown would be okay.

Finding out the data a row has been inserted into a table

Is there a way to find out the data a row has been inserted (into a SQL Server 2005, 2008 or 2008 r2) database table? Without setting up auditing (either ootb or custom 3rd party product).
Thanks
You can always create a trigger on that table. Like so:
create trigger InsertNotification
on YourTable
after insert
as
-- do whatever you want when an insert happens
go
This can definitely be seen as a form of "auditing", but I'm not familiar with "ootb", nor is this a 3rd party product. Triggers are the way to go.
Well if you want to be notified when the row is inserted make insert trigger to this table.
If you just want to save the information when a specific row was inserted, you could just create a new datetime or smalldatetime column with getdate() as the default value.
Whenever a new row is inserted, this column will be automatically filled with the current date/time.
Advantages:
no trigger or 3rd party tool needed
Disadvantages:
this only works for new tables (or all new records in existing tables). If a table already has existing records, you won't have an insert date/time for them
if you want this for all your tables, you have to insert the column into each table

Resources