Reporting services 部署报表时是否可以转换连接字符串？（SSDT对VS 2012/SSRS的投标）

首先，这不是我的专业领域，所以我为我在这个领域缺乏直觉和天真而提前道歉。我只是想帮助一位同事。另外，请让我知道这是否更适合DBAdmin StackExchange站点。尽管有道歉和免责声明

我一直在看着我的一位非编程同事在创建报告的过程中，在2008年商业智能开发工作室（BIDS）的数据集中和项目中，不断地使用硬编码连接字符串。它已经达到了这样的程度：他维护了绝对所有东西的三个版本（一个用于我们的每个环境，每个环境中都有硬编码的特定连接）。在过去几天里，他冒险升级到SSDT竞标VS 2012

编辑以添加：

---

他有一个单一的报表服务器实例，其中他为每个连接到它的环境提供了三个版本的所有内容，但他没有为每个环境提供报表服务器。因此，为了正确发布所有内容，他必须维护三个相同的（除了连接字符串）项目和数据集，并在需要更改时修改这三个项目和数据集。他希望能够做到的是，不必维护三个报表项目，而只需更改一个设置并为该环境重新部署报表。我认为我们在这个问题上处于上游状态，愿意考虑重新设计我们报告的体系结构。

---

来自web领域，我最初的盲目想法是：如果使用Visual Studio，为什么不将连接字符串存储在配置文件中，并在发布时使用转换任何类型的配置文件来转换它们？IDE给出的答案是：没有那么快，因为连接字符串存储在用户界面中，存储在对象本身的属性窗口中

在无休止的网络搜索中，我发现了另一种叫做（页面底部）的技术，但对于我未经训练的眼睛来说，这似乎有点不安全，但这就是我一直在寻找的吗

---

我理解这不一定是典型的SO问题，但如果有人知道如何在BIDS中进行转换部署，以便我们可以将重复减少三倍，我将永远感激。

如果您还没有使用共享数据源，您是否考虑过为您的报告使用这些共享数据源

这样，您可以为每个环境定义一次数据源，然后在将报表部署到不同的环境时，只要数据源的名称始终相同，并且位于报表的相同相对位置，您就不必担心每次都会更新连接字符串

有一些挑战可以通过不同的方式解决（例如，通过报表管理器上载新报表会使现有数据源引用无效），但这是一种非常标准且可扩展的方法

在评论后添加：

谢谢你的更新

如果有一个实例具有多个部署，基于表达式的连接字符串不是一个坏选项

唯一的问题是您需要某种方法来选择数据源，例如参数。如果您愿意让用户选择这个（或通过您可以想到的任何其他机制），这将是一个很好的选择

就安全性而言，这与任何其他静态数据源没有什么不同；您可以选择您喜欢的任何凭据，例如Windows身份验证、存储的凭据。。。这些都是完全一样的，所以这里没有额外的考虑

<> P>您可以考虑的另一个选项是通过您可以参数化部署脚本，将所有报表部署到服务器上多个文件夹中的一个，并将报表指向服务器上多个数据源中的一个

脚本运行后，您甚至可以为每个环境将其包装在一个批处理文件中，并通过运行批处理文件来部署和配置报告

摘要

如果可能的话，我仍然会选择单独的实例，并通过具有不同实例目标的投标和构建配置（开发、发布等）来控制部署。如果您有一些SQL Server开发许可证，这可能是一个选项

如果做不到这一点，其他两个选项中的任何一个也会起作用-基于表达式的连接字符串会将复杂性转移到报表和/或调用应用程序中，或者将其排除在报表之外，现在将一些精力放在一些部署脚本中，这些脚本应该通过相当健壮的批处理文件来部署报表

在这里，我在QA中创建了一个名为“prod_data_source”的数据源，然后在 QA中的连接字符串如下所示

数据源=xxxx；初始目录=xxx

产品环境。数据源名称应相同（包括大写/小写）

在PROD中，数据源将指向您的PROD DB并使用PROD凭据

在QA中，数据源将指向您的QA DB并使用QA凭据

部署报表时，不要部署数据源。仅部署报告。希望这是一种可能性

仅部署报表时，报表将在当前环境中查找数据源（“prod_data_source”），该环境将具有相同的数据源名称，但将在后台连接到正确的数据库。）

在每个环境中创建相同的数据源（连接配置）。你可以给它起任何名字。在我的示例中，我将其命名为“prod_data_source”。每个环境将具有相同的数据源，但它们将指向不同的数据库

---

谢谢你，伊恩。我在问题中添加了一个编辑，我认为这可以澄清问题