When an error caused by improper data (e.g., violating a constraint) occurs at the server, ADO.NET data providers return it to the application in the form of a provider's exception type. In its turn, LinqConnect wraps such exceptions into its LinqCommandExecutionException with the text 'An error occurred when executing DbCommand' and the inner exception being the one returned by the provider.

For example, the following code should result in a server error: the column the PostalCode property is mapped to has a max length restriction (precisely, it is 15 symbols - we are not sure if any country uses more than 9 meaningful symbols, but leave the rest for possible exotic formats). From the other hand, the .NET code is valid, thus the data will be sent to the server.

CrmDemoDataContext context =
    new CrmDemoDataContext() { Log = Console.Out };
Personcontact mrNowhere = new Personcontact()
{
    ContactID = 25,
    FirstName = "John",
    LastName = "Doe",
    PostalCode = "A string too long to be a valid postal code"
};
context.Personcontacts
    .InsertOnSubmit(mrNowhere);
context.SubmitChanges();

Dim context As New CrmDemoDataContext() With { _
 .Log = Console.Out _
}
Dim mrNowhere As New Personcontact() With { _
 .ContactID = 25, _
 .FirstName = "John", _
 .LastName = "Doe", _
 .PostalCode = "A string too long to be a valid postal code" _
}
context.Personcontacts.InsertOnSubmit(mrNowhere)
context.SubmitChanges()

Thus, the server should return an error, and the provider has to wrap it into an exception. Provided that we are working with an Oracle database, we get the server error:
"ORA-12899: value too large for column \"CRM_DEMO\".\"Person Contact\".\"PostalCode\" (actual: 43, maximum: 15)"
within an OracleException object which in turn is wrapped into a LinqCommandExecutionException.

The main reasons of getting LinqCommandExecutionException are:

1. Foreign key violation. Usually, it should not occur if you set the relationships between entities via navigation properties (e.g., OrderDetail.Order), as in this case LinqConnect should track the entity graph consistency. But if instead you configure relationships via the 'plain' properties (like OrderDetail.OrderID), LinqConnect does not search for the related object (e.g., Order having the specified OrderID) until you submit the changes. Hence inserts and updates involving explicit setting of foreign key fields may violate foreign key constraints.
2. Deleting 'parent' entities if no rules are specified for the 'child' ones. For example, when you delete an Order object, no specific actions are done for dependent OrderDetails (unless you set the Delete Rule or Delete On Null property for the Order -> OrderDetail association). Thus, you can get a constraint violation error (so this is actually a particular case of the first point).
3. Using invalid data type. This is exactly what is shown in the sample: the value passed to the server is valid for the .NET type used for the entity property, but is invalid for the server data type of the corresponding column.
4. Existing primary key. When inserting a new entity, you can set for it a primary key that is already in use. Unless the row having this primary key was queried before, you won't know about this conflict until submitting changes. To avoid such situations, check that the key is not used or configure primary key generators.
5. Syntax errors like 'table/column does not exist'. They should not normally occur for LINQ queries, as the SQL statement is generated by LinqConnect at runtime. However, there is no guarantee they don't occur when calling the ExecuteQuery or ExecuteCommand methods. Also, the possible reason for them is an error in mapping - e.g., if the column or table name was modified manually in the model or database, or if an invalid schema is specified in the Source property of the entity class.

In either case, the detailed information about the cause of the error is specified in the inner provider exception.