我只是想了解为什么会发生这种情况，而我的谷歌搜索失败了。我们使用的是 SQL Server 2016 SP1。
情况如下：供应商表通过跟踪每个表的当前值来管理 ID。如果您正在执行插入，则可以调用一个函数来返回一个 ID 块。
所以我们通过使用从真实表中选择来设置一个临时表select into（我们正在克隆一组数据以使用不同的属性集重新插入）。
然后我们调用该函数并获取记录数的新 id（它只返回最大 ID，所以我们做一些数学运算来获取下一个 id）。
然后我们像这样更新表：
update #temp set @nextId = Id = @nextId + 1
期望它将为每条记录增加一并设置ID。
相反，为每 4 条记录设置相同的 ID，然后它会增加，接下来的 4 条获得下一个 id，等等。为什么每 4 条记录？什么地方出了错？
更有趣的是，如果我们在表上放置一个聚集索引，一切都会正常工作。
我确定这与表格堆有关......但不知道为什么。
我问是因为这是我最近才发现的一个较旧的功能。该文档多次提到 DateTime，但没有明确说明其他日期类型是否兼容。
我有一个我相信可以从中受益的数据仓库，但 90% 的重要日期是日期类型，而不是日期时间。我使用的是 SQL 2014，但任何版本的信息都会有所帮助。
刚刚注意到这一点，并且很难找到它的技术原因。
可以使用三部分名称删除表，但视图仅限于两部分名称。
这背后的原因是什么？
这是我要问的一个例子：
明细表：
HeaderId | DetailId
1 100
1 101
2 100
2 101
3 101
3 102
3 103
我正在寻找一种查询策略，该策略将使我获得所有标头 ID，每个标头 ID 都具有相同的详细信息集。
所以在这个例子中，我希望 HeaderId 1 和 2 连接在一起，因为它们有相同的两个详细记录，但 103 不会匹配，因为它在集合中有第三个项目。
到目前为止，我采用的策略是使用该STUFF技术创建一个逗号分隔的详细值字符串，校验该字符串，然后加入校验和结果。它似乎有效，但我不确定如何优化它。在一组大约 7000 个标头中，它会在大约 6-7 秒内返回。
这是查询：
with Details as
(
select distinct t2.HeaderId,
checksum(stuff((
select
',' + convert(varchar(15), t2.DetailId)
from
DetailTable t2
where
t2.HeaderId = t2.HeaderId
for xml path('')
),1,1,'')) as ChkSum
from
DetailTable t1
)
select
*
from
Details t1
join Details t2
on t2.ChkSum = t1.ChkSum
and t2.HeaderId <> t1.HeaderId -- To avoid matching the same record
那么 - 这是正确的方法吗？如果是，我该如何优化？查询计划对我没有任何影响。最大重量分配给工作台线轴。此外，如果有帮助，我正在尝试将其设为函数或过程。
编辑：我开始研究关系划分，我认为这在这里是相关的，但也许与我正在考虑的上下文无关。为了提供更多背景信息，这是我试图解决的业务案例。
我有一组促销活动，其中可以包含任意数量的 UPC。我试图找到其中具有完全相同的一组 UPC 的促销活动。我看到的很多解决方案都依赖于使用count(*). 所以 - 只是为任何正在看这个的人提供一些背景信息。谢谢！
我已经多次遇到这种情况，我确信这是有充分理由的——但我该如何避免呢？
我敢肯定这与周围的怪癖有关isnumeric。在英语中，我有一个过滤isnumeric(somefield) = 1. 然后我尝试int在我的where子句中使用 an 来查询它，并且因为表中的其他一些字段具有字符值，所以整个事情都失败了。
我创建了一个显示错误的SQL 小提琴。
我尝试在cast/convert视图上进行选择，但查询引擎似乎忽略了它。
那么 - 为什么会发生这种情况，有没有一种干净的方法来处理它？
由于我在插入时缺少引号，原来的小提琴有一个非常相似的错误。这不是我试图强调的问题。我通过为所有插入的值添加引号来修复视图。
我有一个事实表，它将在我们早上的处理过程中以适当的计划运行。偶尔，在一天的晚些时候，如果我去查询它，它会有一个非常奇怪的计划。
当查询按日期分区的表时，您通常会看到这样的搜索谓词：
但是由于某种原因，它变成了这样：
是的，我知道上面显示了两个不同的表格。我从类似配置的表中提取了这个好例子，它适当地显示了我期望的搜索谓词。
这两个都是 Clustered Index Seek 运算符。更新统计数据似乎没有帮助，但Ola 的维护脚本的某些部分似乎每天早上都会修复它。
有人见过这个吗？关于如何恢复良好计划的任何提示？
我在我们的数据仓库（SSAS 2014 多维）中有一个客户维度。它被设置为 II 类 SCD，只有开始和结束日期字段来跟踪更改。（空结束日期 = 当前）。
当我们的日常负载运行时，我看到变化正在流入，我有时担心它会在不应该创造新记录的时候创造新记录。
可以运行什么样的脚本来比较每个客户各自的历史记录并确保其发生适当的变化？
另外，我认为我正在触及差距和孤岛问题，有哪些策略可以验证开始日期和结束日期是否都是连续的？
我想确信该表每天都在报告正确的数据，而不会因为某些空检查导致每天创建大量记录而变成野兽。
谢谢你尽你所能的帮助。
现有设置 SQL Server 2005，带有标准 EAV 表，用户希望使用 BI 工具 (Cognos) 对其进行切片和切块。
我们是否有希望将这些数据转换成我们可以报告的格式？谷歌让我相信没有希望。我愿意相信存在某种解决方案。