What are the challenges you face when working across database platforms? Take the survey

Table with Filestream column recreated in migration script

scratchybackscratchyback Posts: 5
edited November 9, 2016 8:31AM in SQL Source Control
I posted this post a while back in the SQL Source Control 4 forum, but seeing we by now have upgraded to 5 and still have this problem, I will post it in this forum as well.

We have a table in our database with a filestream column. Whenever we make a change to the database and create a migration script, this table gets completely recreated again (which takes quite some time considering the amount of data involved). Even with the smallest stored procedure changes, we get a drop and recreate of this huge table as a bonus.

Is there a way to stop Source control from doing this (this is not a workable solution on our production database)? We now manually delete this part form the migration script, but the chance of error is just too big.


We by now have upgraded to version 5 (which cost us a bunch, we only upgraded to get rid of this problem).... however this problem seems to still exist. At the strangest changes (for example simply changing a function that queries a table that has a relation to another table with a filestream column) a migrationscript will be created that drops the WHOLE related filestream table and recreates it. I don't care if migrationscripts do this even if it isn't really needed for other tables, just to make sure all possible changes are accounted for but for a filestream table really NOT. Especially when a release contains multiple changes (and migration scripts) to the database and each change results in a drop and recreate of this table, then we'd need ages to run the migration script.

Can anyone confirm that indeed this issue reappeared in 5 even though the release notes of 4 say it was resolved?
Sign In or Register to comment.