Comments
Sort by recent activity
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? / comments
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...