3

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

在 2008 年商业智能开发工作室 (BIDS) 创建报告期间，我一直在观察我的一位非编程同事与他的数据集和项目中的硬编码连接字符串无休止地斗争。它已经达到了这样的程度，即他维护了绝对所有东西的三个版本（我们的每个环境一个，每个都有特定的连接硬编码）。在过去的几天里，他冒险升级到 SSDT BIDS for VS 2012。

编辑添加：

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

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

通过无休止的网络搜索，我发现了另一种称为基于表达式的连接字符串（页面底部）的技术，但这对我未经训练的眼睛来说似乎有点不安全，但这就是我一直在寻找的吗？

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

4

2 回答 2

3

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

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

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

评论后补充：

感谢更新。

鉴于您有一个具有多个部署的实例，基于表达式的连接字符串不是一个糟糕的选择。

唯一的问题是您需要某种方式来选择数据源，例如参数。如果您很高兴让用户选择此选项（或通过您能想到的任何其他机制），这将是一个不错的选择。

在安全性方面，这与任何其他静态数据源没有什么不同；您可以选择您喜欢的任何凭据，例如 Windows 身份验证、存储的凭据...这些都被完全一样地对待，因此这里没有额外的考虑。

您可能考虑的另一种选择是通过rs Utility部署您的报告。您可以参数化部署脚本以将所有报告部署到服务器上的多个文件夹之一，并将报告指向服务器上的多个数据源之一。

一旦你的脚本工作了，你甚至可以为你的每个环境将它包装在一个批处理文件中，并通过运行批处理文件来部署和配置你的报告。

概括

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

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

于 2013-05-10T17:01:40.893 回答
1
  1. 在这里，我在您的 QA 中创建了一个名为“prod_data_source”的数据源，然后在您的 QA 中的连接字符串中，如下所示

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

  1. 产品环境。数据源名称应相同（包括大写/小写）。
  2. 在 PROD 中，数据源将指向您的 PROD 数据库并使用 PROD 凭据
  3. 在 QA 中，数据源将指向您的 QA 数据库并使用 QA 凭据
  4. 部署报表时，不要部署数据源。仅部署报告。希望这是一种可能。
  5. 当您仅部署报表时，报表将在当前环境中查找数据源（“prod_data_source”），该环境将具有相同的数据源名称，但会在后台连接到正确的数据库。)
  6. 在每个环境中创建相同的数据源（连接的配置）。你会命名它任何东西。在我的示例中，我将其命名为“prod_data_source”。每个环境将具有相同的数据源，但它们将指向不同的数据库。
于 2019-12-10T06:52:39.593 回答