小编Ava*_*rkx的帖子

情景

曾几何时，一家参与 ETL 过程的小公司有一个暂存数据库，充当来自多个第三方来源的各种格式文件的接收目录。E 是通过 DTS 包处理的，几乎没有用于审计或控制的控制结构，但被认为“足够好”，并且出于所有意图和目的，它确实如此。

E 部分提供的数据旨在供单个应用程序使用，由少数年轻有能力的程序员开发和管理。尽管缺乏当时数据仓库技术的经验或知识，但他们从应用程序代码中提出并创建了自己的 T 和 L 流程。这些初出茅庐的软件工程师发明了一种外人可能称之为“不太理想的轮子”的东西，但以“足够好”作为永远存在的服务水平，他们能够提供一个操作框架。

有一段时间，紧耦合领域的一切都很好，Staging 目录以十几个第三方的数据为食，反过来又由应用程序提供。随着应用程序的增长，它的胃口也在增长，但是随着熟练的白骑士开发人员对系统的监视，这些胃口很快得到了解决，在许多情况下，甚至很好。

但当然，黄金时代不可能永远持续下去。随着申请成功，生意兴隆，生意兴隆。随着它的发展，Staging 环境和应用程序被迫随之发展。尽管他们保持警惕，少数英雄开发人员无法跟上维护现在庞大的系统的步伐，而消费者已经有权获得他们的数据。这不再是他们需要甚至想要什么的问题，而是民众觉得他们只是应得的，甚至要求更多。

凭借装满赃物的金库，该企业进入市场，聘请开发人员和管理员来帮助支持不断增长的系统。各种精神的雇佣兵涌入公司，但随着这种增长的突增，几乎没有可用的专家指导。新的开发人员和管理员努力理解自制套件的复杂性，直到挫折导致全面战争。每个部门都开始尝试单独解决每一个问题，更多的是相互对抗而不是相互合作。一个项目或计划将以几种不同的方式实施，每种方式都略有不同。事实证明，对于一些白骑士来说，这一切的压力太大了，随着他们的倒台，帝国崩溃了。很快，系统就陷入了混乱，

尽管这些承诺领域已转变为血腥的意大利面条式代码，但该公司还是忍受了。毕竟，这是“足够好”。

挑战

之后又经历了几次政权更迭和招聘热潮，我发现自己在公司工作。伟大的战争已经过去很多年了，但所造成的破坏仍然非常明显。我设法解决了系统 E 部分的一些弱点并添加了一些控制表，同时以将 DTS 包升级到 SSIS 为幌子，现在一些实际的数据仓库专业人员正在使用它们，因为他们创建了一个正常的并记录 T 和 L 更换。

第一个障碍是以不会截断值或更改本机数据类型的方式从第三方文件导入数据，但还包括一些用于重新加载和清除的控制键。这一切都很好，但应用程序需要能够以无缝、透明的方式访问这些新表。DTS 包可以填充一个表，然后由应用程序直接读取。出于 QA 的原因，SSIS 升级需要并行完成，但这些新包包括各种控制键并利用分区方案，更不用说实际的元数据更改本身就足以保证完全有一个新表，所以新表用于新的 SSIS 包。

随着可靠的数据导入现在工作并被仓储团队使用，真正的挑战在于将新数据提供给直接访问 Staging 环境的应用程序，对应用程序代码的影响最小（也称为“否”）。为此，我选择使用视图，将表重命名为dbo.DailyTransactionto并重用视图dbo.DailyTranscation_LEGACY的dbo.DailyTransaction对象名称，这实际上只是选择了现在的所有内容LEGACY指定的表。由于重新加载这些表中包含的年份数据从业务的角度来看不是一个选项，随着新的 SSIS 填充和分区表进入生产，旧的 DTS 导入被关闭，应用程序需要能够也可以访问新表中的新数据。此时，视图会更新以在从新表（例如，dbo.DailyTransactionComplete，例如）当它可用时从旧表中选择当它不可用时。

实际上，正在执行以下操作：

CREATE VIEW dbo.DailyTransaction
AS  SELECT  DailyTransaction_PK, FileDate, Foo
    FROM    dbo.DailyTransactionComplete
    UNION ALL
    SELECT  DailyTransaction_PK, FileDate, Foo
    FROM    dbo.DailyTransaction_LEGACY l
    WHERE NOT EXISTS (  SELECT …

;WITH
cte_Date ( DateCode_FK ) AS (
    SELECT  DATEADD( DAY, 
                1 - ROW_NUMBER() OVER ( 
                        ORDER BY so1.object_id ),
                GETDATE() )
    FROM    sys.objects so1
    CROSS APPLY sys.objects so2 )
SELECT  TOP 10 d.DateCode_FK
FROM    cte_Date d
ORDER BY d.DateCode_FK DESC;

没什么特别有趣的查询，但是如果我使用以下ORDER BY子句运行它，我会收到一条错误消息：

Msg 517, Level 16, State 1, Line 4

向“日期时间”列添加值会导致溢出。

但是，没有ORDER BY子句，它运行得很好。此外，如果我在同一服务器上的同一实例中包含的其他目录上运行查询，无论是否使用该ORDER BY子句，该查询都可以正常运行。

我查看了受影响的目录和查询按预期运行的目录之间的配置选项和兼容性级别，但没有发现任何可能保证差异的内容。有没有其他人遇到过类似的问题？我现在可以解决它，但理想情况下需要能够解决问题，无论它是什么。

潜在提示 - 如果您在目录中有相对大量的对象（> 5000），您 - 可能 - 能够重现该错误......这发生在我最大的目录中，如果我在其中包含一个 TOP CTE，ORDER BY 问题消失了。