Dynamics CRM Entity and Field Display Name, Field Schema Name and Field Logical name or Attribute name

In Dynamics CRM there is a difference between CRM Entities and Fields Display Name, Entity/Field Schema Name and Entity/Field Logical name (also known as Attribute name).

Display name is clear. It is the name shown to the CRM user and can have spaces, etc. Then you got these two:

  • SchemaName: Name that will be used to create the database column  for the field. This name can be mixed case. The casing that you use sets the name of the object generated for programming with strong types or when you use the REST endpoint. So it could be something like new_FieldSchemaName
  • LogicalName: This is the name, auto generated based on Schema name but the system sets it to all lowercase letters.

Every entity and field has a schema name (DB name – mixed case) and a logical name (all lower case).

Schema name retains the casing but logical name will always be lowercase.

When writing code to call/use fields, we always use schema names (DB names) not logical/attribute name.

As you can see from the following screenshot, you decide the display and schema name during creation while the attribute name will be generated by Dynamics CRM exactly as the schema name but all lower case.

 

Schema-vs-Logical-Name

 

Once your field is created, you can see in the following screenshot the Name (logical name), the schema name (DB name – mix case) and the Display name (the one the customer sees).

 

Schema-vs-Logical-Name

 

The same applies to entities.

This post may sound like it is targeting only those who are starting to work with Dynamics CRM for the first time, but in reality I have met a number of Dynamics CRM developers who didn’t know this information. Hence, I hope this is useful. Please comment with your views below.

 

2 thoughts on “Dynamics CRM Entity and Field Display Name, Field Schema Name and Field Logical name or Attribute name

  1. We learn something every day… thanks very much for the explanation! At this stage I don’t remember when and by whom, but I vaguely remember being advised to set the schema name all lower case also when creating a field. Can’t remember the reason either. Hence my question is, does it make any difference from a practical point of view whether I use lower-case or mixed case for schema name? Would really like to get this cleared because it bugs me:)

  2. Viktor,
    The reason to create entities with all lower-case schema names is because some functions use the schema name and some use the attribute name. Honestly, I’ve been using all LC schema names for so long, I couldn’t tell you which is which.
    I know OData (the REST endpoint) uses schema names in the queries, but I believe fetch calls (SOAP endpoint) use the attribute name. There’s probably a rhyme or reason to when to use one or the other, but it’s a lot easier just to use all LC schema names and not worry about it.

    One thing that *really* bugs me is that the schema name is also called the “DB name” but SQL is case-insensitive! I’ve run into an issue during integration where a field was created “by hand” in the dev environment and the test environment (instead of being imported in the solution). Unfortunately, the case of the schema name was different. Well, when the next solution was imported, the case of the field from DEV didn’t match the field in TEST. The CRM was comparing on schema name and saw the field as a “new” field, so it made a table update call. But in the SQL server, since the column names are case-insensitive, it was complaining that the field already existed!

    Anyway, there’s a world of ways you can screw yourself with mixed-case schema names. Don’t do it. I’ve actually had junior developers delete and recreate multi-hundred field entities that were made with mixed-case. They rarely make that mistake twice, but it’s an easy one to catch and fix. The errors you get when using attribute names where schema names are expected are WAAAY harder to catch, and that SQL error from the last paragraph? I think that killed a couple days’ productivity on that project, with all the manpower it took to figure out the issue.

Please comment or leave feedback