首先，这不是我的专业领域，因此我对这个领域缺乏直觉和天真表示歉意。我只是想帮助一个同事。另外，请让我知道这是否更适合DBAdmin StackExchange网站。抱歉，免责声明...
我一直在看着一个非编程的我的奋斗同事，他在创建报告的过程中用他的数据集和项目中的硬编码连接字符串在2008 Business Intelligence Development Studio（BIDS）中不断地寻找着我。到现在为止，他维护了绝对所有内容的三个版本（一个针对我们每个环境，一个特定的连接被硬编码到每个环境中）。在过去的几天里，他经历了大跌，并升级到了VS 2012的SSDT BIDS。
编辑添加：
他有一个报表服务器实例，在该实例中，他为所连接的每个环境提供了所有版本的三个版本，而对于每个环境他都没有一个报表服务器。因此，为了正确地发布所有内容，他必须维护三个相同的项目（连接字符串除外），并在需要更改时修改所有三个项目和数据集。他想要做的就是不必维护三个报告项目，而只需更改设置并针对该环境重新部署他的报告即可。我认为我们在这个问题上处于上游，并且愿意考虑重新设计报告的架构。
来自网络领域，我最初的盲目想法是：如果您使用的是Visual Studio，为什么不将连接字符串存储在配置文件中，并在发布时使用SlowCheetah转换它们以转换任何类型的配置文件？从IDE中返回的答案是：不是那么快，因为连接字符串存储在用户界面中对象本身的“属性”窗口中。
通过无休止的网络搜索，我发现了另一种称为Expression-based Connection Strings的技术（页面的底部），但是对于我未经训练的眼睛来说似乎有点不安全，但这是我一直在寻找的东西吗？
[我知道这不一定是原型SO问题，但是如果有人有任何知识可以传授如何在BIDS中进行转换部署，从而使我们的复制减少三倍，我将万分感谢。
如果尚未使用报告，是否考虑使用Shared Data Sources作为报告？
这样，您就可以为每个环境定义一次数据源，然后在将报表部署到不同的环境时，只要数据源始终与报表相同的名称和相对位置，就不需要了每次都担心更新连接字符串。
有一些可以用不同方式解决的挑战（例如，通过报表管理器上传新报表会使现有的数据源引用无效，但这是一种非常标准且可扩展的方法。
在评论后添加：
感谢更新。
鉴于您有一个具有多个部署的实例，基于表达式的连接字符串并不是一个不错的选择。
唯一的问题是您需要某种选择数据源的方法，例如参数。如果您乐于让用户选择此选项（或通过您可以想到的任何其他机制），那么这将是一个不错的选择。
就安全性而言，这与任何其他静态数据源没有什么不同；您可以选择所需的凭据，例如Windows身份验证，存储的凭据...这些完全一样，因此这里无需额外考虑。
您可能考虑的另一个选择是通过rs Utility部署报告。您可以参数化部署脚本，以将所有报告部署到服务器上多个文件夹之一，然后将报告指向服务器上多个数据源之一。
一旦有了脚本，您甚至可以针对每个环境将其包装在一个批处理文件中，仅通过运行该批处理文件即可部署和配置报告。
摘要
[如果可能，我仍然会去寻找单独的实例，并通过BIDS控制部署，并构建具有不同实例目标的配置（开发，发行等）。如果您拥有一些SQL Server Development许可证，则可以选择。
否则，其他任何一个选项也应该起作用-基于表达式的连接字符串将复杂性移入报告和/或调用应用程序中，或者将其排除在报告之外，并且现在将精力放在应部署的某些部署脚本中通过相当强大的批处理文件来部署报告。
数据源= xxxx;初始目录= xxx