Sharepoint：列表导入后查找字段的完整性
我有一个关于导入数据时查找字段的行为的问题。我想知道当查找字段指向的列表被替换/导入时，查找字段的行为如何。为了解释这个问题，我将在下面提供一个简单的示例：
例如，假设我们有这两个共享点列表：
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
在我的场景中，产品列表包含生产 Sharepoint 平台上的生产数据。它充满了业务用户的数据。 然而，产品类型列表包含相当静态的数据，并由开发人员维护。
现在，经过一个开发周期后，开发人员想要部署新的 Web 部件和新数据（产品类型列表）。开发人员执行以下过程：
- 在开发计算机上：使用 stsadm 导出“产品类型”列表
- 在生产计算机上：删除“产品类型”列表中的所有项目 在
- 生产计算机上：使用 stsadm 导入“产品类型”列表
这意味着我们基本上替换了生产服务器上的“产品类型”列表，同时保持“产品”列表不变。
现在的问题是：
- 这安全吗？在某些情况下查找引用会中断吗？
- 这种进出口程序有什么缺点吗？
- 如果有人在导入过程中访问“产品”会发生什么？ （现在无效）引用是否会清除其自身内容（变成空值）。
- 如果“产品类型”列表的架构发生更改（新列），会发生什么情况？这会带来什么麻烦吗？
感谢所有反馈和建议！
更新1 导入的“产品类型”项目与之前删除的项目具有相同的 ID。
更新2 开始赏金以获得更多反馈/意见。
I got a question about the behavior of lookup fields when importing data. I wonder how the lookup fields behave when the list they point to is being replaced/imported. To explain the issue, I will provide a quick example below:
As example, assume we have these two sharepoint lists:
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
In my scenario, the Products List contains production data on the production Sharepoint platform. It is filled with data by the business users.
However the Product Types list contains rather static data and is maintained by the developer.
Now after a development cycle, the developer wants to deploy his new webparts and his new data (product types list). The developer performs the following procedure:
- On the dev machine: Export "product type" list using stsadm
- On the production machine: Delete all items in the "product type" list
- On the production machine: Import the "product type" list using stsadm
This means we basically replace the "product type" list on the production server while keeping the "product" list as it is.
Now the question:
- Is this safe? Will the lookup references break under certain circumstances?
- Any downside of this import/export procedure?
- What happens if someone accesses a "product" during the import? Will the (now invalid) reference clear its own content (become a null value).
- What happens if the schema of the "product type" list changes (new column)? Will this cause any troubles?
Thanks for all feedback and suggestions!
Update 1
The imported "product type" items have the same IDs as previously deleted ones.
Update 2
Started a bounty to get some more feedback/opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们以前也遇到过这种完全相同的情况。这有点棘手，具体取决于您将如何处理它。
1) 通过 UI 删除并重新创建产品类型列表
如果您通过 UI 删除并重新创建查找列表（在您的情况下是产品类型），那么您将失去连接，因为列表的 id GUID 将在重新创建时更改。所以不要走那条路。
2) 通过功能删除并重新创建产品类型
如果您使用
feature.xml文件创建了产品类型列表> 元素，那么如果您删除该列表，然后使用相同的功能重新创建它（基本上 ListInstance 的 Id 属性保持不变，列表项的数量，即|
附带说明一下，这是更好的方法，因为如果您必须在很多服务器上进行升级，那么功能停用和激活是更值得推荐的解决方案，而不是通过 stsadm 进行列表导出导入。我们就是这样做的。
3)从产品类型中删除所有列表项并添加新列表项（列表永远不会被删除）
如果您将查找字段（在产品列表中）链接到查找列表（产品类型）的 ID 字段，则必须 请记住，ID 是自动递增的，因此如果您删除所有项目然后添加新项目，那么它们的 ID 将会不同。假设列表中有 5 个带有 ID 的项目（在数据表视图中编辑时，ID 字段不会显示在 UI 中）1-5。如果删除它们并添加新项目，它们的 ID 将从 6 开始，而不是从 1 开始。因此，如果您的查找字段链接到 ID 为 1 的项目，则此方法将不起作用，因为“产品类型”列表中不再有 ID 为 1 的项目。因此，在使用此方法进行生产之前，您可能想真正尝试一下。
4）就地编辑列表
如果列表不是特别大，并且您只需对一两个实例进行此更改，您是否可以直接在产品服务器上的数据表视图中编辑列表？在数据表视图中编辑时，不要删除该项目，而只是覆盖其列的值。如果需要，您还可以添加更多项目。这将确保您的身份证件有效。
我主要谈论的是向列表中添加新项目。现在，如果您要删除现有项目，那么您的查找字段将受到影响，因为假设您通过 ID 链接字段，则由于该项目已被删除，该 ID 不再存在。基本上，无论您使用什么方法，维护您的 ID 都是至关重要的。
现在关于您的疑虑/问题：
我不太确定列表的 stsadm 导出导入（我自己从未这样做过），但 stsadm 可能很棘手，因为某些操作仅适用于某些范围。因此，您最好在开发环境中尝试您的具体场景。
导入过程中发生的事情再次变得棘手，具体取决于确切的时间。我确信 SP 有自己的并发机制，但您无法得到明确的答案，因为它可能会根据导入阶段的不同而有所不同。如果可能，建议的方法是在计划的停机时间内进行导入。
关于更改列表的架构，列表架构的更改不会影响现有的列表实例（大多数情况下）。如果您通过 UI 执行此操作，我相信 SP 会直接更改内容数据库。我不确定您打算如何执行此操作，但如果您要使用功能将列添加到现有列表，则执行此操作的方法是在功能激活期间通过向列表添加新内容类型并添加新列到此内容类型。通过这种方式，您可以添加列，但不会影响现有的列表项。
祝你好运...
We have had this exact same scenario before. This is a little tricky, depending upon how you will approach it.
1) Delete and Recreate Product Type list through UI
If you delete and recreate the lookup List(Product Type in your case) through UI, then you will lose the connections because the List's id GUID will change upon recreation. So do not go that route.
2) Delete and Recreate Product Type through a Feature
If you had created the Product Type list through a
feature.xmlfile using the<ListInstance>element, then if you delete that list and then recreate it using the same feature (basically Id attribute of ListInstance remains the same, number of list items, i.e. the number of<Row>elements, may change), the association would be maintained. So if you were adding 5 more product types, then if you had created the list using a feature, you could just delete the list and provision the new one using the same feature with extra info for new items and everything would just work!As a side note, this is the better approach because if you have to do the upgrade on a lot of servers, then rather than doing list export import via stsadm, feature deactivation and activation is a much more recommended solution. This is how we did it.
3)Deleting all list items from Product Type and adding new ones (list is never deleted)
If you are linking the lookup field (in Product List) to the ID field of the lookup list(Product Type), you have to remember that ID is auto-incrementing, so if you delete all items and then add new ones, then their ID's would be different. Say you had 5 items with ID's (ID field is not shown in UI while editing in Datasheet view) 1-5 in the list. If you delete them and add new items, their ID's would start from 6 and not 1 again. So if your lookup field had link to the item with ID 1 in it, then this method is not going to work because there is no item with ID 1 in the Product Type list anymore. So you might want to really try this out before going to production with this method.
4) Editing the list in place
If the list is not extraordinarily huge, and you only have to make this change to one or two instances, could you not just edit the list directly in the datasheet view on the prod server? When editing in datasheet view, do not delete the item, but just overwrite the values of its columns. And you can add more items if you want. This will make sure your ID's are valid.
I have mostly talked about adding new items to the list. Now if you were deleting existing items, then your lookup fields will be affected because assuming you linked the field by ID, the ID is not present anymore since the item has been deleted. Basically, any method you use, maintaining your ID's is critical.
Now regarding your doubts/questions:
I am not too sure about stsadm export import for a list (never done it myself), but stsadm can be tricky as some operations will work on certain scopes only. So you better try out your exact scenario on a dev env.
What happens during an import is tricky again depending on the exact timing. I am sure SP has its own concurrency mechanisms, but you cannot have a definitive answer as it might probably be different based on the stage of the import. If possible, recommended approach is to do the import during a planned downtime.
Regarding changing schema of the list, a change in the schema of a list will not affect the existing list instances (for the most part). If you do this through UI, I believe SP makes changes to the content DB directly. I am not certain how you intend to do this, but if you were to add a column to an existing list using a feature, the way to do this is during feature activation by adding a new content type to the list and adding your new column to this content type. This way you add the column but do not affect the existing list items.
Good luck...
特定查找有两个组成部分：字段和字段值。字段值仅包含其引用的项目的 ID 和显示字段。如果没有该字段，该信息就没有意义，该字段指定要查看哪些列表以及使用哪个字段作为显示字段。
There are two components to a particular lookup: the field, and the field value. The field value only contains the ID of the item(s) it refers to, and the display field. This information is meaningless without the field, which specifies what list to look at and what field to use as the display field.