只是看一下新项目的要求，我想确保这个用例是合理的：
SQL Server是否能够以这种方式解析邮件附件？有这种方法的任何警告吗？
使用Outlook作为提交技术的吸引力在于，如果用户离线，则用户的流程相同。然后Outlook会在重新联机时自动同步。用户必须有一些方法在离线状态下填写表单，“提交”它们，然后在下次联机时自动与服务器同步。
编辑：澄清一下，我不是在寻找一种从server-＆gt;客户端缓存表单数据的方法。我希望缓存已完成的表单。建立一个单独的应用程序来缓存客户端上已完成的报告不是一种选择。
答案 0 :(得分：2)
我不会使用您在上面概述的方法。在我看来，有几种方法比让SQL Server查看Exchange邮箱更令人满意。您提出的要点和重要要求是允许InfoPath表单在脱机模式下工作。我会将项目的“离线模式”和“数据传输”部分视为两个截然不同的部分：1）表单和数据应存储在客户端上，直到可以连接到Internet并且2）一旦连接可用，表单和数据应该传输到服务器。
您可以将InfoPath表单设置为直接提交到SQL Server并完全绕过Exchange“中间人”。在设计表单时，InfoPath中的设置非常简单：1）为连接启用“提交数据”，2）配置提交选项。这个article包含有关如何执行此操作的详细信息。此外，您可以设置与SQL Server的连接以供脱机使用，如本article中所述。这种方法唯一需要注意的是，您可能需要更改数据库模式以支持它。
另一种方法是将InfoPath表单提交给SQL Server 2005 HTTP端点。 InfoPath客户端只是一个美化的XML编辑器，HTTP端点基本上是Web服务的不同名称。您将HTTP端点上的表单数据接收到临时表中，其中数据以XML格式存储，然后您可以从该临时区域解析该数据。您仍然需要设置InfoPath连接以供离线使用。这种方法的主要警告是，Microsoft将弃用SQL Server 2008中的HTTP端点，转而支持WCF。
我想建议的另一种方法是使用WCF本身从InfoPath客户端接收XML表单数据。此方法需要您在设计时将表单的数据源连接到WCF Web服务，然后还要设置表单以供脱机使用。
我希望这对你有用，至少让你朝着正确的方向前进。
答案 1 :(得分：2)
更高版本的SQL Server能够在其中运行.NET代码，因此您可以从SQL Server轮询邮箱并处理InfoPath表单。但是，我不确定我会这样做。
考虑编写一个能够完成这项工作的Windows服务可能会更好。 Windows服务将启动，检查“服务帐户”的邮箱，读取邮件，提取附件，处理xml，最后将数据写入SQL。如果发生业务规则或验证错误，它也可能会在确认或错误的情况下响应该邮件。
我不确定我是否已将上述所有逻辑都放入SQL中 - 首先，我怀疑您的帐户存在问题（必须让SQL帐户运行才能访问Exchange邮箱）帐户）。
您的里程可能会有所不同，您应该对此进行原型设计以确定哪种方法最适合您，但我会尝试将代码保留为使用Exchange作为与SQL分离的“工作队列”，并仅将处理的代码放在将数据写入SQL中的表。
答案 2 :(得分：0)
我见过类似的项目，在客户端上使用Express版本，在Express中保存infopath（或应用程序数据）并使用Service Broker交付到中心，因为SSB与邮件的保证交付语义。这使您可以更轻松地向IT销售所有SQL解决方案，并且您不需要在服务器上进行轮询。此外，您不必处理MIME解析，这是所有直接的XML处理。但是，对于胆小的人而言，让SSB正常运行是一项挑战。 如果您决定使用邮件传递，外部服务将更容易构建，调试和故障排除。你应该得到一些更好的问题： - 您将如何保持邮件出列操作和表写操作的一致性？您的组件必须使Exchange读取/删除和SQL插入到一个分布式事务中。 - 您的逻辑是否准备好处理无法正常运行的infopath文档？邮件传输绝对不保证交付顺序，因此您可能会在“订单创建”文档之前看到“订单删除”文档 - 您如何检测丢失的文件（不是通过邮件发送）？您是否要实现发件人序列号并最终在邮件上重新发明TCP？ - 您的处理是否允许并行处理相关文档？如果线程1选择了doc 1，而线程2从同一个发送者中获取了doc 2，而doc 2与doc 1相关（即引用相同的业务事务），那么在数据库写入会发生什么？它是否会陷入僵局，是否会松动更新，是否会被退回？
前面的桥下有很多龙......