I am using Asp.net Webapi and EF and i am having issues with partial updates with the Entity Framework 5 .
I usually get say 20 fields from REST services that i need to update out of the complete entity.When I update I set the entity state to Modified.
The whole entity is updated all the time overriding all the existing values in the table that should not be changed as a result of the update.
There are random fields that I got from REST services not fixed fields that can help me to identify what properties are updated.
I want to know how this issue is being resolved out there and what are the practices are used to fix this.
Thanks.
Related
Is there a good practice to introduce existing legacy database tables/entities into a JHipster project?
The idea I had was to create the JPA entities that look exactly like the existing entities and then use the generated artifacts as per normal. Will this possibly work?
In the end, I opted for just creating a view of all the underlying tables I needed in my query. The steps I followed were:
create the view on the DB,
Generate the entity using JHipster, with exactly the same fields.
Strip out the Update ad Create and Delete functions and we have a read-only view page with all the data you need and all the fields displaying, done.
Now I can add my own routers and buttons, to allow other specific operations/flow. This page was my inspiration: https://www.javabullets.com/calling-database-views-from-spring-data-jpa/
In my solution I have a workflow where one step contains a reference to Queue. After importing this solution on another CRM instance this workflow could not be activated because it contains an invalid reference - Queue can not be resolved. Queue with same name is created on new CRM but resolving is probably based on record Guid.
Now, I'm wondering, is there a way to edit workflow steps using CRM SDK? Whole process of CRM solution deployment is automated. And I want to remove all manual work. Some example would be great :)
Thanx in advance!
There are 2 things you can do if you are having issues with the Guids not matching in a workflow lookup when deploying from one environment to another.
Use the API to create those records referenced in the WF. When you create a record you can actually specify the Guid that it uses as the id. So write a tool or see if one exists already that will create some default data for your environment.
Use a configuration entity with references to all the EntityRefrences needed in your WFs. Then you can create a custom workflow activity to retrieve the configuration entity record (there should only ever really be one) that contains all the references in that environment.
I have a custom entity Project, which is having a many to many relationship with User entity.My requirement is when an User is added to a Project he/she only can see that project.
To do that I have tried to add a custom Plugin which will share the Project record to added User, in update message of Project entity. But plugin not firing.
Is there any other way to do that? Please help me out here.
Thanks.
You need to register the step of your plugin at Associate message (and eventually Disassociate is you want to manage also when a Project record is removed from a User) not the Update one.
When a record is linked with a 1:N or N:N relationship the record doesn't get updated.
The Associate message needs to be registered against all entities (leaving empty or set to none the Primary Entity field inside Plugin Registration Tool)
If you use the Developer Toolkit you can find a tutorial to register on Associate message here:
http://zhongchenzhou.wordpress.com/2012/05/20/create-plug-in-for-message-with-no-primary-entity-associated-using-dynamics-crm-2011-developer-toolkit/
Read also this post that explains how to check the entities that triggered the plugin:
http://orwin.ca/2011/07/05/crm-2011-plugin-triggering-off-associate-message/
I upgraded from VS2005 to VS2012 specifically to code in .Net 4,.Net 4.5, and use EF5. I am new to EF. I have Julie's EF book but it talks mainly about EF4 and POCO and it has me confused trying to implement EF5.
My hosting only allows me to run .Net 4 currently. I am trying to use EF5 on a new database.
I tried Code first to generate my database but I could not get it to generate the database. So I created the database first and then generated the model from the database with EF5. What I want is a layered website using ASP.NET Forms, Data Access Layer, and a Business Layer. The business layer I intend to build so I can use ObjectDataSource to pull in to the webpage along with some web services to use cascading dropdowns.
I have my NameX.edm model created but the tt files don't have the same names, they have Model1.tt and Model1.Context.tt is not the same name, why. Also Model1.Context.tt is empty. I am attempting to create the POCO classes running the EF5 DbContext but I am having trouble getting it to see the edm model. I read somewhere that EF5 creates the POCO automatically. I am not seeing the big picture here. Is my issue that I am not using .Net4.5?
What I have is a ASP.NET Application project, a EF Project, a POCO Project, and intend to have a forth project with the Business logic. How do I get the EF generated correctly and the POCO classes? I want a layered application for to scale well. Next question How to get the POCO classes to talk with the Business logic? My database is SQL. I am use to writing stored proceedures to accomplish everything through business logic.
If you are using Model First technique, make sure that you have references to System.Data.Entity and System.Data.Entity.Design. Also, you will need to create a reference to the EntityFramework.dll as well. It is located by default in c:\Program Files\Microsoft ADO.NET Entity Framework Feature CTP5\Binaries\EntityFramework.dll. If you can not find it, make sure you have installed the Entity Framework through your Package Manager Console. To do this, open up Tools, Library Package Manager, Package Manager Console, then type Install-Package EntityFrameWork.
Next you want to add a new item to your project. Right click on your solution, go to Add, then select New Item. You want to select Data from the Common Items section on the left, then select ADO.NET Entity Data Model.
Next Select Generate From Database. In the next screen, if you have not set up your connection to the server, click New Connection..., otherwise select your database from the drop down box. You need to select whether or not you want to include your connection string information in your config file. This is up to you how secure you need your application to be. If you choose not to, you need to pass this information as parameters in code. Also at the bottom, you will most likely want to change the auto-generated entities name to something easier for you to use. This name will be the name of your DBContext Class!
Next you want to select the tables you would like EF to create POCO's for. If you want all the tables just tick the tables items. Same goes for views and stored procs.
Once you click finish, then you should see all your fancy POCOS laid out in front of you in Design Mode. Note If you do not have primary keys in place for all your tables, I suggest you fix that! VS will spit at you if you do not have Primary Keys set, or if your naming conventions in your tables prevent VS from creating them for you implicitly.
This is a quick little tutorial on getting you up and running. You can now persist and pull data from your POCOS by using your DBContext object. For example if you named your DBContext class *Gary_Bettman_Sucks*, and you wanted to create a new record from your table called NHL you would do the following:
Dim context as New Gary_Bettman_Sucks
Dim PullMyGoalie as New NHL With {
.Goals = 0,
.Playoffs = False
}
context.Set(Of NHL).Add(PullMyGoalie)
context.SaveChanges()
I would Highly suggest you look into implementing the Repository Pattern with your design to encourage code re-use, and it will seriously make your life MUCH easier down the road.
Hope this helps!
we are currently working on a specific CRM development. As part of this development we are working with a different supplier who have provided us with a 'core' managed solution, a toolkit of sorts. This toolkit contains a number of entities/web resources etc but crucially contains the case and contact (renamed to customer) entities. As part of our development we need to extend these entities by adding attributes/amending form layout etc for both these entities.
should i create a new unmanaged solution - select add existing - choose the customer entity.
I can then make my changes (new attributes, form layout changes etc)
I then publish my unmanaged solution as a managed solution to import into a UAT/Prod environment.
Would this approach work ok?
What if the supplier make changes to their core entity and provide us with an updated release? what happens then or what should i do?
There are a couple of attributes (title and ethnicity) that are part of their entity but i need to work of global option sets so i have create 2 new attributes and these are displayed on the form in place of their's. I have not removed theirs but could this cause issues?
any help appreciated
chris
You are right on in the first paragraph, you would need to create a new solution and amend their entities. When you import their changes it will add on any additions to those entities. Importing customizations should never remove anything, you have to do that manually. Although unlikely, it is possible that the vendor may release a new version that requires you to roll back your customizations and reinstall it. In this instance you would need to come up with an upgrade plan and take into account all of the dependencies of the system.
I would imagine that those attributes would be dependencies of their managed solution and suspect that CRM won't let you delete them. If you are able to delete the fields and recreate them using global option sets there should be no issues so long as you use the same picklist integer values and schema names for the fields. Microsoft CRM basically copies all of the global option set values to the entity that you put them on so externally there is no difference between the standard and global option sets. Obviously a future upgrade by the vendor may force you to delete it all and recreate everything again manually (or via code using the CRM web services), but that is something you would have to take into account.
What the disadvantage here is, is if you create an entity, attribute or relationship in Dev and deploy to forward facing entity, if you then remove that entity, attribute or relationship in Dev, you must "uninstall" that solution. Of course, if you have critical data in that forward facing environment, it is gone when that solution is removed. So, if you deploy from Dev to forward facing, if in the future you no longer need that entity, attribute or relationship, although you can remove it from forms, it will always remain an artifact in your system. This is a disadvantage when working with Managed solutions.