MSCRM: How to create entities and set relations using the xRM linq provider - linq

Do I need to save newly created CRM-entity instances before I can set relations to other crm entity instances?
I'm facing the problem that after calling CrmDataContext.SaveChanges() the newly created entities are written to the database, but the relations between those newly created instances are missing in the database.
What do I miss? Do I have to call CrmDataContext.SaveChanges() each time I create a new crm entity instance that I want to have relations to other CRM-entity instances?

You should be able to set relationships to other entities in a 1:N relationship before saving this entity(i.e. a lookup).
If you are wanting your entity to be referenced by another entity it will need to be Saved first OR you need to set a Guid for the entity first. Otherwise your link won't stick.
When you new up an entity its id is not set until it is saved to the database, unless you set it manually. If you set it manually it will respect the new Guid you have given it and the relationship will survive the saving process.
If you try to save an entity individually, you need to make sure that you have saved all the entities that it refers to before you save that entity, or it won't have a link.

Related

Generating unique IDs for new records and existing records

I'm basically trying to create a primary ID between CRM and QuickBooks. Figured I'd just use the existing PK in CRM for the lookup. I'd like the PK to visible to the user, but not editable in CRM.
This has presented several problems in that you can't do that out of the box. I thought I read somewhere you could either via business rule or calculated field, but I haven't had luck with that.
It sounds like it would require web resources if I were to go this route.
The other option would be to just generate unique values for every record in Accounts and Contacts.
Does this automatically populate existing records or just new records? How do I get it to populate existing records?
You can use Auto number manager for configuring an auto-number attribute in every entity. This seeds a number based on configured format for new records. Uniqueness assured by SQL sequence feature & no need of any extra plugin/workflow.
For existing records - you can design a workflow along with a temp entity to assign auto-number. Read more.
Otherwise you can use SSIS + Kingswaysoft package to generate auto-number & assign for existing records.
I am suggesting you to create a new text field on the entity and create a pre plugin that will get the record primary GUID id from context and will set this GUID into the newly added attribute. You can set this field as read-only of form as well.
OR you can generate new GUID as well into the plugin.

Update EF model - DB at different location

I am very new to EF programming.
My application gets the data from existing database. (DB first)
Now I have come to situation where I want to update my model to newer DB. basically the core schema is same as previous but has some modification in the table.
When I change the DB name for app.config and update the model it gives list of error
have I missed something?
When you do an update it merges the model you have with the DB that you update from. Additional columns are added to your existing entities but columns that you have removed from the DB are not removed from your entities and you need to remove these mappings yourself.
If you know which tables have columns removed it sometimes easier to delete the entity from your model and then do an update to reload it from the DB.
If you've don't know what tables or there have been many then it may be easier to delete all entities from your model and just do a full Update to reload the the new DB structure.

How to link an entity with database?

I have a complex entity with many relations, so I need many forms in many pages to create one. Therefore, I use a session to keep my entity.
Everything is going okay, but when comes the time to flush, the entity manager returns the "entity through relationship is not configured to cascade persist" thinking that some entities are new but they're actually stored in db !
For instance, I create a User with a ManyToOne Group, using $u->setGroup(Group $group); ($group being an existing group from the db). When I put it in session, then get it back in another page and then flush it, the entity manager tries to create a whole new group, not knowing that it is an existing one in db.
I use a little trick to overcome this :
$u = $this->get('session')->get('userToAdd');
$group = $em->getRepository('MyBundle\Entity\Group')->find($u->getGroup()->getId());
$u->setGroup($group);
With this, EM will recognize the group stored in db and the flush will go just fine, but with my entity having so much relationships like this, it is very convenient to do this for every single one.
Any ideas for this issue ?
Before find group try to refresh $u object.
$em->refresh($u)
You have to do:
$em->merge($u);

Core Data cross storage fetched property

I'm currently wrapping my head around some problem with Core Data.
I have one user model in its own store that I do not have any control over, as it gets shipped with a framework. A Persistent Store Coordinator, Managed Object Model and Context for this model gets created automatically and cannot be touched. In it, this model has a single user entity
On the other hand, I have a properties model with a properties entity in it that I have complete control over. In there I store properties for some user entities in the other store. Both user and property entities have an id attribute similar to a foreign key.
This model has it's own Persistent Store Cordinator, Managed Object Model and Context.
What I now want is to have the associated user entity as an attribute of the properties entity so I might be able to bind to key-paths similar to myproperty.user.someValueOfTheUserEntity (I'm aware that myproperty might be an array when using fetched properties).
However, as cross-store relationships are not supported I thought of using a weak relationship via Fetched Properties. That one would just have to match the two corresponding id attributes. I have created a Fetched Property for the user in Xcode and the required accessors in my properties entity's class file (As suggested in other questions, I'm treating the values returned by the Fetched Property as an array).
However, I'm unable to set a destination entity for the Fetched Property in Xcode, as the target entity resides in a completely different store. Would I also have to define my user entity in the properties store? If so, how does Core Data know that that entity shall be fetched not from my properties store but from the users store?
Some threads mentioned using configurations for this, but I cannot find any documentation that goes further than mentioning "use configurations for this".
Can somebody enlighten me on how to set up cross-storage fetched properties? #
You can use several persistent stores that share the same data model:
Use single data model (xcdatamodeld) and add all your entities
Create configurations (Editor/Add Configuration) for each "logical set" of
entities that should be stored in separate store file
Assign (Drag) entities to appropriate configurations
Add configured persistent stores to your context (see below)
Configure fetched properties
// 1. Add "static", read-only store
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your static configuration name goes here..."
URL:storeUrl
options:#{
NSReadOnlyPersistentStoreOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];
// 2. Add "dynamic", writable content
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your dynamic configuration name goes here..."
URL:storeUrl
options:#{
NSMigratePersistentStoresAutomaticallyOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];

Making entity framework treat views with many-to-many relationships, like it does tables with many-to-many relationships

I have three views that I've manually created in the DB.
First view is "Region", the second is "FIPS" and the last is a many-to-many between them called "Region2FIPS". These are all views, and I only need read access the data, so I'm not worried about having updateable views.
I have added each of these views to Entity Framework, and created the appropriate associations between them.
Region to Region2FIPS is a 1 to many.
FIPS to Region2FIPS is a 1 to many.
The "Region2FIPS" view contains only two columns, one called "FIPSID" the other "RegionID". These column are associated with their respective views in the relationships I defined above.
When this type of association is made on tables in the DB, Entity Framework knows that it is a many-to-many relationship and it creates a navigation property on "Region" called "FIPS" that I can use to navigate through the child collection of FIPS. It does likewise for "FIPS" to "Region".
However, when done manually, with views, it does not exhibit that behavior. Instead, my "Region" object has a collection of "Region2FIPS" objects, which each have a navigation property called "FIPS" which is of type "FIPS". And my "FIPS" object has a collection of "Region2FIPS" objects, which each have a navigation property called "Regions" of type "Region".
I assume this has something to do with the fact that I can't create foreign key references on the views, so entity framework doesn't realize the many-to-many relationship. But I thought that if I manually created the many-to-many relationship between the views it would recognize it and properly handle the navigation between the types. Is there a way for me to force it to do this?
It's possible, but the designer doesn't really help you here. You have to do the mapping manually.
One fairly easy way is to use Code First mapping. But this means your model has to be Code First to begin with. If you're writing a new model, just do that.
If you're using DB First mapping, however, you will have to do the mapping manually. Your SSDL will probably already be correct, once you define the "primary keys" of the views. You would then have to remove the "Region2FIPS" objects from the CSDL (not just from the designer!) and manually patch up the MSL.
Perhaps the easiest way to do this would be to use the designer to automatically map real DB tables (not views) with a similar schema and then replace the table names with view names in the EDMX, using the XML editor.

Resources