Table with Filestream column recreated in migration script
scratchyback
Posts: 5
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?
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?
