SSDT tries to alter timestamp column in TFS build

Question

We're trying to perform an upgrade test against a copy (backup/restore) of our customer database as target. There are some tables with  timestamp column in the database. The way we do this is by having a database project with a publish profile targeting
that copy of customer database and then with TFS build server is used to build the database but only to generate a publish script (/p:UpdateDatabase=False) set in the build definition - msbuild argument.
Example of table definition:
CREATE TABLE dbo.CodeTable1
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY
,Code CHAR(6)
,[Timestamp] TIMESTAMP NULL);
We would like to have the "Code" column to have CHAR(7), so in the project we modify the table definition:
CREATE TABLE dbo.CodeTable1
(ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY
,Code CHAR(7)
,[Timestamp] TIMESTAMP NULL);
Expecting SSDT build will generate alter script:
ALTER TABLE dbo.CodeTable1 ALTER COLUMN Code CHAR(7);
To our surprise the generated script was:
ALTER TABLE dbo.CodeTable1 ALTER COLUMN Code CHAR(7);
ALTER TABLE dbo.CodeTable1 ALTER COLUMN [Timestamp] TIMESTAMP NULL;
Which will cause error when the script is executed: "Cannot alter column 'TIMESTAMP' to be data type timestamp."
Why is SSDT generating the change script for that timestamp column??
We then try a local build in VS, the issue is not happening, SSDT correctly generates alter script only for the "Code" column to CHAR(7);
Both local machine and TFS Build server are having VS 2013 Update 4- SSDT 12.0.50318.0 installed.
As we tried to troubleshoot further, we found out that it seems it only happens on a restored database from a backup copy of our customer database. It doesn't happen for databases created by SSDT build from scratch or that we manually created. We've tried make
sure all database properties are the same as the database that correctly built. But still if the target database is the one we restored from a customer's copy, SSDT always tries to alter timestamp column (on server build).
Anyone have same experience?
I have posted a bug in ms connect: https://connect.microsoft.com/SQLServer/feedback/details/1266051
Thanks!

Answer 1

Thanks Paul!
However, it doesn't happen when I build the database project locally or if the target database was created by SSDT (or manually for that matter). The issue happens when I change the target database to the one we restored from a backup copy of our customer's
database and run the build through our TFS build server.
So I thought there must be something different with the restored database (which causes SSDT to alter timestamp column) as opposed to the one SSDT/manually created (which doesn't alter the timestamp column). Maybe there is difference on database property/settings?
Whatever it is, I just couldn't find it.
The only thing we will do now as workaround is to get db schema creation script from that of customer's database and run that script to re-create the database from scratch and use that as target database instead, as luck would have it, the issue would be
gone.
Still, why the heck SSDT tries to alter timestamp column in that specific case and not in other case as described above??
Elvin