2011 年 CRM 中自定义实体、字段的资本化
在迁移到 CRM 2011 的过程中，我们发现不同的开发人员使用了不同大小写的自定义实体和自定义字段。这给使用早期绑定方法的自定义编程带来了麻烦。 http://msdn.microsoft.com/en-us/library/gg327844.aspx 。有没有办法在迁移之前（或之后）标准化实体/字段名称？
In migrating to CRM 2011, we're discovering different developers used different capitalization of custom entities and custom fields. This creates a headache for custom programming using the early bound methods. http://msdn.microsoft.com/en-us/library/gg327844.aspx. Is there a way to normalize the entity/field names before (or after) the migration?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我所知。实现您想要的正确大写的唯一方法是使用适当的名称重新创建实体。
迁移之前或之后主要是升级 CRM 服务器安装并修改数据库架构以反映升级，同时仍保留当前数据和自定义数据。
这就是“支持”的内容。
至于实际的解决方法。如果您无论如何都想升级，我会很想将您当前的 CRM 4 系统恢复到测试域。然后看看在实际的“不可触及的”crm 数据库中更改模式名称是否可行。我相信有一个 MetaDataSchema.Entity 表，它是集中存储的，所以我会测试它，看看它的可用性以及它对 web 服务的影响。
因此，您面临着与我在使用 Dynamics CRM 时多次面临的类似选择。采用支持的方式，或者一点“Yee-Ha”开发。抱歉，这可能不是您想听到的！
编辑：
关于要更改的内容，我不能确定，因为我目前还没有 CRM 4.0 系统，只能及时处理 2011 年的问题。但作为示例，[OrganizationName_MSCRM] 数据库中将有一个 MetadataSchema.Entity 表。其中某些列会跳出。名称、物理名称和逻辑名称。
逻辑名称是 CRM 用户的名称，无论您如何输入，它都默认为小写。
我相信 PhysicalName 和 Name 是您希望更改为小写的名称。
实体的实际“名称”，例如逻辑名称是“帐户”，而在 CRM 中，它以用户友好的方式显示，通过名为 MetadataSchema.LocalizedLabel 的表通过外键“ObjectId”关联，在本例中，该外键为“ObjectId” “EntityId”字段。
这就是我希望进行更改的地方，因为它不应该对其余数据产生影响，因为“逻辑名称”字段是 CRM 可能使用的字段。
就你们这一代的强类型类而言。
如果您使用后期绑定，
那么所有属性和逻辑名称都需要小写。因为这将使用先前在 MetadataSchema 表中标识的“逻辑名称”属性。
然而，使用 SVCUtil 我只能假设它会查看“名称”和“物理名称”属性，以便在生成用于自定义应用程序的文件时提供稍微更用户友好的编码体验。
不过，如果您希望使用早期绑定类生成，那么这应该不是问题，因为生成的定义文件将提供关于属性和属性的正确大小写的智能感知，并且如果您像之前的示例一样使用后期绑定，那么它的值会更低案件。所以更多的是看起来有点凌乱，而不是完全不切实际 =)
As far as I'm aware. The only way to achieve the correct capitalisation you desire is to recreate the entities with the appropriate names.
Before or after the migration is mostly the upgrade of the CRM Server installation and modifying the database schema to reflect the upgrade, while still maintaining the current data and customisation data.
Thats as far as the "Supported" spiel goes.
As for an actual workaround. If your looking to upgrade anyway I'd be tempted to restore your current CRM 4 system to a test domain. Then look at how feasible it is to change the schema names in the actual "untouchable" crm database. I believe there is a MetaDataSchema.Entity table where this is centrally stored so i'd test this to see how usable this is and what impact it has on say the webservice.
So you face a similiar choice that I face on multiple occasions while working with Dynamics CRM. Go with the supported way, or a bit of "Yee-Ha" development. Sorry it's probably not what you want to hear!
Edit:
In regards to what to change I can't say for sure as I haven't got a CRM 4.0 system to hand only a 2011 at this moment in time. However as an example, there will be a MetadataSchema.Entity table in the [OrganisationName_MSCRM] Database. Of which certain columns will jump out. Name, PhysicalName and Logical Name.
Logical name is the one that CRM users which it defaults to lowercase no matter how you enter it.
I believe PhysicalName and Name are the ones you would be looking to change into lower case.
The actual "Name" of the entity, eg logical name is "account" whereas in CRM where it is displayed in a user friendly way is related through a table called MetadataSchema.LocalizedLabel through the foreign key "ObjectId" which in this case would be the "EntityId" field.
This is where I would be looking to do the changes as it shouldn't have an impact on the rest of the data due to the "logicalname" field being the one CRM probably uses.
As far as your generation for strongly types classes goes.
if you use latebound such as
then all the properties and logical names need to be lower case. As this will use the "logicalname" property previously identified in the MetadataSchema table.
Howver using SVCUtil I can only assume it looks at the "Name" and "Physical Name" attributes to give a slightly more user friendly coding experience when it generates the file for use in custom applications.
Though if you are looking to use the early bound class generation it shouldn't be a problem as the definition file generated will provide intellisense on the correct capitalisation of attributes and properties, and if you are using late bound like the example previously it's all lower case. So it's more it will just be a bit untidy to look at than completely impractical =)