我有一个SQL Server 2012数据库,其中包含有关讲座的信息。我需要做一些工作,包括重命名主键字段,这是一个标识。读完这篇文章之后,它看起来很简单,我做了改变。
之后,我发现SQL Server重新编号了所有ID,填补了空白。但是,它没有更新与该表具有外键关系的其他表,导致我的数据完全损坏。
例如,这里是变更之前的数据样本(旧的东西,从早期开始)......
ID Date SpeakerID
9 2005-03-24 00:00:00.000 3
11 2005-05-16 00:00:00.000 26
12 2005-10-24 00:00:00.000 55
13 2005-11-13 00:00:00.000 26
14 2006-01-10 00:00:00.000 1
15 2006-01-09 00:00:00.000 2
如您所见,我们没有ID为10的演讲。
重命名主键后,SQL Server重新编写了讲座,填补了空白。您可以在此处查看相同查询的结果...
ID Date SpeakerID
9 2005-03-24 00:00:00.000 3
10 2005-05-16 00:00:00.000 26
11 2005-10-24 00:00:00.000 55
12 2005-11-13 00:00:00.000 26
13 2006-01-10 00:00:00.000 1
14 2006-01-09 00:00:00.000 2
了解我们现在如何使用ID 10进行演讲?如果查看此处显示的其他两个字段,则会重新编号ID。这一切都发生在整个表格中,所以当我们用ID 2788(最近一次)进行演讲时,它已被重新编号为2760.
这发生在几张表上,正如您所想,已经完全破坏了整个数据库。
任何人都知道这是怎么发生的?我的第一个想法是,因为我重命名了主键,它需要SQL Server删除并重新创建表,所以在重新插入数据时它会按顺序重新编号ID。然而,除了这个想法的纯粹愚蠢,我无法重现它。我已经多次在已恢复备份的讲座表上重命名了主键,并且编号没有受到影响。我所做的其他改变都没有远程连接。他们只是添加新列,或者更改varchar(1000)的类型为varchar(max)。
我真的需要知道这是怎么发生以及为什么发生这种情况,因为我仍然需要做出改变。我们丢失了几天的数据,因为我们没有立即发现这个问题。我不希望再发生这种情况。
感谢您提供任何帮助。
答案 0 :(得分:0)
我怀疑您使用了自定义脚本,因为您无法重命名约束所基于的列。在这种情况下,您需要首先删除约束。
我知道重命名列的自定义脚本通常通过创建具有相同结构的新表,复制数据,删除原始表,最后重命名新表来实现此目的。这是一种完全合法的策略,尤其是对需要逐个分区处理的多列或大型数据集的更改。
也就是说,那些在原始表和新副本之间复制数据的查询显然需要针对您推出的每个更改进行手动更新。我怀疑是否有错误允许目标表通过IDENTITY
约束重新创建值,而不是使用SET IDENTITY_INSERT schema.table ON
并复制旧值。你能调查一下你使用过的脚本吗?