A Fine Slice Of SQL Server
Paul Randal takes us through some limitations on copying Filestream data between tables:
I was asked last week whether it’s possible to create a table with a FILESTREAM column and then populate that column by copying FILESTREAM files from another directory in the FILESTREAM data container.
The simple answer is no.
Paul explains why this isn’t possible and then gives you an alternative which does work.
Comments closedGianluca Sartori walks us through an error when combining merge replication with FILESTREAM:
I published tables with FILESTREAM data before, but it seems like there is a particular planetary alignment that triggers an error during the execution of the snapshot agent.
This unlikely combination consists in a merge article with a FILESTREAM column and two UNIQUE indexes on the ROWGUIDCOL column. Yes, I know that generally it does not make sense to have two indexes on the same column, but this happened to be one of the cases where it did, so we had a CLUSTERED PRIMARY KEY on the uniqueidentifier column decorated with the ROWGUIDCOL attribute and, on top, one more NONCLUSTERED UNIQUE index on the same column, backed by a UNIQUE constraint.
Setting up the publication does not throw any error, but generating the initial snapshot for the publication does:
|
This is a rather specific confluence of events, so it probably won’t affect many people. Still, it is a bug.
Comments closedAndy Mallon found a bug with Filestream:
I tracked the problem back to this specific scenario: When you have a database that is part of an Availability Group, and you drop a table that contains filestream data, the filestream garbage collection does not clean up the data container subdirectory that corresponds to that table. Garbage collection will continue to clean up other items (eg, deleted rows), but the dropped table never gets cleaned up.
I’ve logged this as a connect item for your up-voting pleasure.
Go forth and upvote.
Comments closed