我对 SQL Server 2008 的 FILESTREAM 功能有一些疑问。

1. 使用 FILESTREAM 功能返回从 SQL Server 2008 流式传输的文件与直接从共享目录访问文件在性能上有什么区别？

2. 如果 100 个用户在 10 秒的窗口内请求 100 个 100Mb 的文件（通过 FILESTREAM 存储），SQL Server 2008 的性能会不会慢到爬行？

我正在测试一个处理文件的应用程序（使用 存储在 SQL Server 中FILESTREAM）。它是一个 Delphi 32 位应用程序。

打开存储在数据库中的 XLS 文档（最初使用 Office 2003 保存）在 Excel 2010 64 位中出现错误。Office 2010 64 位与 32 位应用程序是否存在一些已知的兼容性问题？

错误消息和工作流程

打开文件时，Excel 会给出以下错误消息之一：

• 由于内容问题，无法打开文件 FILE

• 无法打开文件，因为某些部分丢失或无效

使用 Office 2007 在计算机 A 上打开文件会毫无问题地打开该文件。使用 Office 2010 在计算机 B 上打开相同文件会产生错误消息。在机器A上再次打开也有错误信息！在所有这些步骤中，我只是从数据库中读取，而不是写入。那么为什么会发生这种情况呢？

如何打开文件？

1. SELECT 查询以获取varbinary(max)特定 ID_Document 的“文档”字段。
2. 使用从数据库中提取 TBlobField(sqlQuery.FieldByName('DOCUMENT')).SaveToFile(sDestinationPath + FileUniqueName + .zip');
3. 使用将文件从一个路径复制到另一个路径Windows.CopyFile
4. TZipforge使用组件解压文件
5. FileSetReadOnly使用函数将解压缩文件的属性设置为ROM 。
6. 使用打开文档ShellExecute(0, 'open', PWideChar(FIleName), '', '', SW_SHOWNORMAL);

如您所见，没有任何内容可以写回数据库。一旦文件被提取出来，TBlobField它甚至会在解压缩和打开它之前复制到另一个地方。

可能损坏的安装

Office 已重新安装，现在一切正常，损坏问题是由于与打开的 Office 安装发生冲突，询问“您要修复 Office 安装吗？”。无论如何，问题仍然存在，因为我无法理解发生了什么。如果我将文件提取到文件夹中并从文件夹中打开它而不将任何内容写回数据库，我该如何破坏数据库中的文件？

我有一个带有VARBINARY(MAX)字段的表（SQL Server 2008 with FILESTREAM）

我的要求是，当我去部署到生产中时，我只能为我的 IT 团队提供一组 SQL 脚本，按一定的顺序执行。我在生产中制作的一张新表有这个VARBINARY(MAX)字段。通常对于新表，我会编写CREATE TABLE脚本。而且，如果我有需要处理的数据，我将编写INSERT脚本。不太复杂。

但是VARBINARY(MAX)，我用来生成INSERT语句的存储过程在该表上失败了。我尝试选择该字段，打印它，复制它，转换为十六进制等。我遇到的主要问题是它没有选择该字段中的所有数据。我做了一个检查DATALENGTH([FileColumn])，如果源行包含 1,004,382 字节，我在再次插入时可以获得复制或选择的数据的最大值是 8000。所以基本上它是截断（即无效）数据.....

我怎样才能做得更好？我像疯了一样尝试谷歌搜索，但我一定错过了一些东西。请记住，我无法访问文件系统。这必须全部脚本化。

我在 Windows 7（版本 6.1 Build 7601：Service Pack 1）和 Visual Studio 2010 上有 SQL Server Express 2008 SP1。

我正在尝试使用以下代码创建一个用于将文件插入文件流的存储过程 CLR。

然而，当它到达这条线时：

我得到：

在执行用户定义的例程或聚合“sp_fileController”期间发生 .NET Framework 错误：

谁能告诉我如何解决这个问题？只是我不能用 sql 2008 express edition 以这种方式执行代码吗？

我已经设置了一个支持 FILESTREAM 的 SQL 数据库，并试图通过 WebAPI 将使用 SqlFileStream 从数据库中检索到的文件流式传输到浏览器。

由于某种原因它不起作用，但我没有收到正确的错误消息。浏览器只是中止了连接，Fiddler 也没有显示任何有用的东西，而且在 VS 中似乎没有抛出任何错误。

我怀疑 TransactionScope 提前关闭可能是个问题？不知道为什么我没有收到任何错误消息。

通过 WebApi 流式传输 SqlFileStream 的正确方法是什么？

What is the proper way to handle file sizes when using Sql Server's FILESTREAM feature to store documents in the database?

I know that you can use the TSQL command DATALENGTH() on the filestream column, but regarding to this Microsoft article this might not always be the best idea:

Avoid retrieving the data length of lots of BLOB files in an application. This is a time-consuming operation because the size is not stored in the SQL Server Database Engine. If you must determine the length of a BLOB file, use the Transact-SQL DATALENGTH() function to determine the size of the BLOB if it is closed. DATALENGTH() does not open the BLOB file to determine its size.

I am a bit unclear if the above says that you should avoid DATALENGTH() if possible or if it is the recommended way to retrieve the file size.

If I have to access document sizes often to show it to the user as metadata, what is the recommended way to retrieve them? Store them in a separate field? Or is datalength() fast enough?

我在 SQL Server 2008 R2 上启用数据库镜像，我已经配置了我的服务器，但是在尝试开始镜像时出现以下错误：

我的数据库上什至没有文件，所以我想关闭文件流，我该怎么做？

谢谢

我有一个表 ( myTable)，其中有一个字段标记为 a Filestream，在此服务器上，它是唯一的文件流，它保存到F:\foo

SELECT COUNT(1) FROM myTable结果为 37,314，但文件夹属性为F:\foo36,358 个文件。Filestream 列中的所有行myTable都有数据，这是否意味着 956 是完全重复的？

如果是这样，SQL Server 如何确定什么是重复的，什么不是重复的（它是一个完整的二进制比较吗？因为我认为 SQL 在块差异级别存储数据不值得）？因为我似乎找不到任何信息 SQL Server 合并文件流的重复记录。

此外，当我再次重新保存许多相同的记录（使计数说 45,000）时，F:\foo增加的总文件对我来说表明重复检查（如果有任何这样的事情）并不完美。

SQL Server 是否将文件流中的相似文件合并在一起？是否有可以执行的存储过程使 SQL 重新扫描文件流文件组并寻找进一步的重复项以整合现有空间？

有问题的服务器是带有 SP1 的 SQL Server 2012 Enterprise，但也出现在我们的带有 SP1 框的 UAT SQL Server 2012 标准版上。

使用 LINQ 访问数据库中的 BLOB 文件的工作方式如下：

当我在此表上激活 Filestream 时，LINQ 通过 T-SQL 查询数据库。对于较大的文件，这是一种不好的做法。

根据此站点： http: //www.codeproject.com/Articles/128657/How-Do-I-Use-SQL-File-Stream应该使用SqlCommand, 查询路径然后直接访问文件SqlFileStream.

现在可以以更流畅（更“LINQ-er”）的方式访问文件吗？

我正在开发这个应用程序，我需要将大型数据文件上传到我的 SQL Server DB，并且我一直在使用 FileStream 来更有效地完成它。

我了解这些文件直接存储在我系统的文件夹 (C:\CryptoDB) 中。

问题是，我需要操作这些文件（解密它们），但我无法恢复它们的文件路径。这样做，我将能够直接操作它们，而不必通过 SQL 重新下载它们，这真是一种浪费。

到目前为止我能做的：

我的桌子：

插入：

当我尝试恢复文件路径时：

我得到的结果：

文件实际在哪里：