问题标签 [sql-server]

我目前的开发项目有两个方面。首先，有一个公共网站，外部用户可以在其中提交和更新用于各种目的的信息。然后，此信息将保存到 colo 设施的本地 SQL Server。

第二个方面是内部应用程序，员工使用它来管理这些相同的记录（概念上）并提供状态更新、批准等。该应用程序托管在公司防火墙内，具有自己的本地 SQL Server 数据库。

这两个网络通过硬件 VPN 解决方案连接，这很不错，但显然不是世界上最快的东西。

这两个数据库相似，并且共享许多相同的表，但它们不是 100% 相同。两边的许多表都非常特定于内部或外部应用程序。

所以问题是：当用户更新他们的信息或在公共网站上提交记录时，你如何将这些数据传输到内部应用程序的数据库中，以便内部人员进行管理？反之亦然……您如何将员工所做的更新推送回网站？

值得一提的是，这些更新发生得越“实时”越好。并不是说它必须是即时的，只是相当快。

到目前为止，我已经考虑过使用以下类型的方法：

1. 双向复制
2. 双方的 Web 服务接口都带有代码，以便在更改发生时（实时）同步更改。
3. 双方的 Web 服务接口带有异步同步更改的代码（使用排队机制）。

有什么建议吗？有没有人遇到过这个问题？您是否提出了适合您的解决方案？

我编写了一个存储过程，如果记录存在，它将进行更新，否则它将进行插入。它看起来像这样：

我以这种方式编写它的逻辑是，更新将使用 where 子句执行隐式选择，如果返回 0，则插入将发生。

这样做的替代方法是进行选择，然后根据返回的行数进行更新或插入。我认为这是低效的，因为如果您要进行更新，它将导致 2 次选择（第一次显式选择调用和第二次隐式在更新的位置）。如果proc要进行插入，那么效率就没有区别。

我的逻辑在这里合理吗？这是您将插入和更新组合到存储过程中的方式吗？

在过去，我从来不喜欢在数据库表上使用触发器。对我来说，它们总是代表着一些将在数据库端发生的“魔法”，远离我的应用程序代码的控制。我还想限制数据库必须做的工作量，因为它通常是共享资源，我一直认为触发器在高负载情况下可能会变得很昂贵。

也就是说，我发现了几个使用触发器有意义的实例（至少在我看来它们是有意义的）。不过最近，我发现自己有时可能需要“绕过”触发器。我对不得不寻找方法来做到这一点感到非常内疚，我仍然认为更好的数据库设计会减少这种绕过的需要。不幸的是，这个数据库被多个应用程序使用，其中一些是由一个非常不合作的开发团队维护的，他们会对模式更改大喊大叫，所以我被卡住了。

关于触发器的一般共识是什么？爱他们？讨厌他们？认为它们在某些情况下是有目的的？是否认为需要绕过触发器意味着您“做错了”？

System.Data.SqlClient.SqlException: Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed.

有人遇到过这个错误和/或对它的原因和/或解决方案有任何想法吗？

此链接可能有相关信息。

更新

连接字符串是=.\SQLEXPRESS;AttachDbFilename=C:\temp\HelloWorldTest.mdf;Integrated Security=True

建议User Instance=false有效。

我在 SQL Server 中的计划报告不会运行。我检查了日志，发现了失败的工作。日志中的错误消息是：

请求的登录名“NT AUTHORITY\NETWORK SERVICE”的“EXECUTE AS LOGIN”失败。步骤失败。

我正在对报告使用 SQL 身份验证，因此它不应该是数据权限的问题。服务器上不会运行任何定期报告。

我们的 SQL Server 2005 群集上出现零星的随机查询超时。我拥有一些使用它的应用程序，所以我正在帮助调查。在常规的 ol' Perfmon 中查看 % CPU 时间时，您当然可以看到它的变化。但是，SQL 活动监视器只给出一个进程使用的累积 CPU 和 IO 时间，而不是它当时正在使用的时间，或者在特定时间范围内使用的时间。也许我可以使用分析器并运行跟踪，但是这个集群被大量使用，我担心我会在大海捞针。我在吠叫错误的树吗？

有没有人有一些好的方法可以在这种环境中追踪昂贵的查询/流程？

数据库“master”中的 CREATE DATABASE 权限被拒绝。尝试为文件 C:\Documents and Settings\..\App_Data\HelloWorld.mdf 附加自动命名数据库失败。存在同名数据库，或无法打开指定文件，或位于 UNC 共享上。

我找到了这些链接：

• http://blog.benhall.me.uk/2008/03/sql-server-and-vista-create-database.html
• http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=702726&SiteID=1

我工作的公司有一个使用 SQL Server 2000 后端的旧 Access 2000 应用程序。我们的任务是将后端移动到新服务器上的 SQL Server 2005 数据库。不幸的是，在尝试进行任何插入或更新时，应用程序无法正常运行。我的研究发现许多论坛帖子 Microsoft 不支持 Access 2000 -> SQL 2005，但我找不到任何 Microsoft 文档来验证这一点。

任何人都可以将我链接到一些官方文档，或者有没有人使用过这个设置并且可以确认这应该工作并且我们的问题出在其他地方？

不确定是否重要，但该应用程序是编译成 ADE 的 ADP。

在 C# 源代码或存储过程中保留 SQL 的优点/缺点是什么？我一直在与朋友讨论我们正在开发的一个开源项目（C# ASP.NET 论坛）。目前，大部分数据库访问是通过在 C# 中构建 SQL 内联并调用 SQL Server DB 来完成的。因此，我正在尝试确定对于这个特定项目，哪个是最好的。

到目前为止，我有：

代码中的优点：

• 更易于维护 - 不需要运行 SQL 脚本来更新查询
• 更容易移植到另一个数据库 - 无需移植

存储过程的优点：

• 表现
• 安全

首先，我知道运行非常大/长时间运行的报告是一个可怕的想法。我知道 Microsoft 有一条经验法则，即 SSRS 报告的执行时间不应超过 30 秒。然而，由于外部力量，例如遵守州法律，有时庞大的报告是首选的邪恶。

在我的工作地点，我们有一个 asp.net (2.0) 应用程序，我们已将它从 Crystal Reports 迁移到 SSRS。由于庞大的用户群和复杂的报告 UI 要求，我们有一组屏幕，可以接受用户输入的参数并创建要在夜间运行的计划。由于该应用程序支持多个报告框架，我们不使用 SSRS 的调度/快照工具。系统中的所有报告均由计划的控制台应用程序生成，该应用程序接受用户输入的参数并使用创建报告时使用的相应报告解决方案生成报告。对于 SSRS 报告，控制台应用程序生成 SSRS 报告并通过 SSRS Web 服务 API 将它们导出为 PDF。

到目前为止，SSRS 比 Crystal 更容易处理，除了我们最近从 Crystal 报表转换为 SSRS 的某个 25,000 页报表。SSRS 服务器是一个 64 位 2003 服务器，具有 32 个运行 SSRS 2005 的 ram。我们所有的小型报告都运行得非常好，但是我们在处理像这个这样的大型报告时遇到了麻烦。不幸的是，我们似乎无法通过 Web 服务 API 生成前面的报告。在生成/导出大约 30-35 分钟后会出现以下错误：

异常消息：底层连接已关闭：接收时发生意外错误。

网络服务调用我相信你们都见过：

奇怪的是，如果使用报告管理器直接在报告服务器上运行该报告，则该报告将运行/呈现/导出。为报告生成数据的 proc 运行大约 5 分钟。大约 12 分钟后，报告在浏览器/查看器中以 SSRS 原生格式呈现。通过报告管理器中的浏览器/查看器导出为 pdf 需要额外的 55 分钟。这工作可靠，并产生高达 1.03gb 的 pdf。

以下是我尝试通过 Web 服务 API 使报告工作的一些更明显的事情：

• 在报表服务器上将 HttpRuntime ExecutionTimeout 值设置为 3 小时
• 在报表服务器上禁用 http 保持活动
• 增加了报表服务器上的脚本超时
• 将报告设置为在服务器上永不超时
• 在客户端调用时将报告超时设置为几个小时

从我尝试过的调整中，我很高兴地说任何超时问题都已消除。

根据我对错误消息的研究，我相信 Web 服务 API 默认情况下不会发送分块响应。这意味着它会尝试在一个响应中通过线路发送所有 1.3gb。在某个时刻，IIS 认输了。不幸的是，API 抽象了 Web 服务配置，所以我似乎找不到启用响应分块的方法。

1. 有谁知道在不降低总页数的情况下减少/优化 PDF 导出阶段和/或 PDF 的大小？
2. 有没有办法为 SSRS 打开响应分块？
3. 关于为什么它在服务器上运行而不是通过 API 运行，还有其他人有任何其他理论吗？

编辑：阅读 kcrumley 的帖子后，我开始通过获取文件大小/页数来查看平均页面大小。有趣的是，在较小的报告中，数学计算得出，每页大约为 5K。有趣的是，当报告变大时，这个“平均值”会增加。例如，一份 8000 页的报告平均超过 40K/页。很奇怪。我还要补充一点，除了每个分组中的最后一页之外，每页的记录数都是设置的，因此某些页面的记录数不是比另一个页面多的情况。