首先，这不是我的专业领域，所以我提前为我在这个领域缺乏直觉和天真而道歉。我只是想帮助一位同事。另外，如果这更适合 DBAdmin StackExchange 站点，请告诉我。尽管有道歉和免责声明......
在 2008 商业智能开发工作室 (BIDS) 创建报告期间，我一直在观察我的一位非编程同事在他的数据集和项目中无休止地与硬编码连接字符串作斗争。它已经达到了这样的程度，即他维护了绝对一切的三个版本(一个用于我们的每个环境，每个环境都有特定的连接硬编码)。在过去的几天里，他冒险升级到 VS 2012 的 SSDT BIDS。
编辑添加:
他有一个报表服务器实例，其中他为连接到它的每个环境提供了所有内容的三个版本，他没有为每个环境创建一个报表服务器。因此，为了正确发布所有内容，他必须维护三个相同的(除了连接字符串)项目和数据集，并在需要更改时修改所有这三个项目和数据集。他希望能够做的，不是必须维护三个报告项目，而只是更改设置并为该环境重新部署他的报告。我认为我们在这个问题上逆流而上，愿意考虑重新设计我们报告的架构。
来自网络领域，我最初的盲目想法是:如果您使用的是 Visual Studio，为什么不将连接字符串存储在配置文件中并在发布时使用 SlowCheetah 转换它们？转换任何类型的配置文件？从 IDE 返回的答案是:没那么快，因为连接字符串存储在用户界面中，在对象本身的属性窗口中。
通过无休止的网络搜索，我发现了另一种称为 Expression-based Connection Strings 的技术。 (页面底部)，但这对我未经训练的人来说似乎有点不安全，但这就是我一直在寻找的吗？
我明白这不一定是典型的 SO 问题，但如果有人有任何知识可以传授如何在 BIDS 中进行转换部署，以便我们可以将重复减少三倍，我将永远感激不已。
最佳答案
如果您尚未使用共享数据源，您是否考虑过为您的报告使用这些资源？
这样您就可以为每个环境定义一次数据源，然后在将报告部署到不同的环境时，只要数据源始终命名相同并且与报告位于相同的相对位置，您就不应该这样做每次都需要担心更新连接字符串。
有一些挑战可以通过不同的方式解决(例如，通过报表管理器上传新报表会使现有数据源引用无效)，但这是一种非常标准且可扩展的方法。
评论后添加:
感谢更新。
鉴于您有一个具有多个部署的实例，基于表达式的连接字符串是不错的选择。
唯一的问题是您需要某种方式来选择数据源，例如参数。如果您很高兴让用户选择这个(或通过您能想到的任何其他机制)，这将是一个不错的选择。
就安全性而言，这与任何其他静态数据源没有什么不同；你选择你喜欢的任何凭证，例如Windows 身份验证、存储的凭据...这些都被完全相同地对待，因此这里没有额外的考虑。
您可能会考虑的另一种选择是通过 rs Utility 部署您的报告。 .您可以参数化部署脚本以将所有报告部署到服务器上的多个文件夹之一，并将报告指向服务器上多个数据源之一。
脚本运行后，您甚至可以将其包装在每个环境的一个批处理文件中，只需运行该批处理文件即可部署和配置您的报告。
总结
如果可能，我仍然会选择单独的实例并通过 BIDS 控制部署，并构建具有不同实例目标的配置(开发、发布等)。如果您有一些 SQL Server 开发许可证，这可能是一个选项。
如果做不到这一点，其他任何一个选项也应该起作用——基于表达式的连接字符串将复杂性转移到报告和/或调用应用程序中，或者将其排除在报告之外，现在将一些精力投入到一些部署脚本中应该通过相当强大的批处理文件部署报告。
关于reporting-services - 部署报表时是否可以转换连接字符串？ (针对 VS 2012/SSRS 的 SSDT 出价)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16485646/