I have about 40 entities in Dynamics that I need to delete. Some of them has relationships to each other. Deleting them using the web UI is very tedious as I have to make sure that there are no entities using the one I'm currently trying to delete. Is there a quick way to delete them (maybe directly in SQL Server)?
Thanks,
David
You could automate this with a program using the CrmService and Metadata Service, but I'm pretty sure writing that is not quicker than deleting the entities by hand (though it would be an interesting thing to build with all the special steps that task would include).
Never do things like this directly through the database server; that's a sure-fire way to corrupt your database beyond repair.
Is it a dev instance? Start over and import what you do want ;) Its could be a long, painful exercise fixing all those views, forms, etc.
Related
I have some questions regarding the registering/updating of 3rd party plugins that were previously loaded via a managed solution by a 3rd party.
The issue we are having is that they(3rd party) sent us a plugin update and a new plugin outside of the Managed Solution and had us register it manually though the registration tool. Then, next time we tried to import a later version of their solution, the Managed solution import failed. We eventually realized that there where duplicate rows in the pluginassembly and pluginassemblytype table that had the same Pluginassemblyid and plugintypeid respectively with different solutionids.
These solutionids were "Active" which I assume came from the manual registration and "IPM Global" which is our 3rd Party Managed Solution. The only way we were successful in getting the solution to import was to change the overwrite time
on the table(s) to 0 and then delete the "Active" pluginassembly and plugintype records.
Is there any other way to accomplish this same thing that is supported?
BTW. We did try to unregister the plugins before trying this, but there were too many dependencies in our workflows.
Wow, this is a thorny problem. Since you mention updating the tables directly, I'll assume that the system is on-prem.
Registering a plugin that exists in a managed solution outside of that managed solution is something I've never done, and while I have directly updated the plugin registration table, it is certainly something to minimize.
As unpleasant as it sounds, to get back to a good state in a supported way you may be looking at having to:
Backup the SQL database
Backup all the data from any managed solution entities.
Undo all dependencies on the managed solution (i.e. edit all the workflows so they no longer depend on the managed solution). To ease the pain of this piece you might want to experiment with exporting the affected workflows via an unmanaged solution. Then you could delete them rather than trying to weed out the dependencies. Then after you have the managed solution back in the system, you could theoretically import the unmanaged workflow solution to restore the workflow. But, admittedly this working depends on workflows finding the plugin assemblies they depend on by name rather than Id, which I'm not sure is the case - so like I said, experiment.
Unregister the "out-of-band" plugin
Uninstall the managed solution
Install a clean copy of the managed solution, INCLUDING the previously problematic plugin.
Restore/reconfigure the workflows
Restore the managed entities data
It's a lot... so much in fact that I would consider opening a Microsoft support ticket to see if they can provide any alternative methods to correct the situation.
In this situation I personally might also consider unsupported methods like using SQL to copy the tables of any managed entities before deleting the managed solution and then using SQL to copy the data back after the managed solution is fixed. Of course I (almost) never recommend using SQL in an unsupported way, so explore that option at your own risk (and with copious backups).
First, try to avoid direct DB updates in system tables whenever possible. You never know when it will hit you (next solution import, next CRM upgrade, moving to cloud, etc).
I assume that yours vendor solution contains entities and attributes and not only assemblies with SDK message processing steps. Thus you can't just simply remove that managed solution cause there will be data loss. Also I assume there are no workflow activities in their assemblies.
Ask them for solution with properly registered assemblies and SDK message processing steps. Then go into your organization with plugin registration tool (https://msdn.microsoft.com/en-us/library/gg309580.aspx) and unregister their assemblies. Then just import their latest solution. It should be able to import their assemblies with whatever is inside them.
It's good idea to restore copy of prod organization and playthrough whole process in safe environment first.
I'm extremely new to programming. Just above school level. I created a project using EF Model First only to realize after I cannot get it to use SimpleMembership for Login, etc.
I wanted to try and solve this problem whilst remaining model-first as I asked here: https://stackoverflow.com/questions/36552439/could-someone-explain-this-code-to-me-ef-model-first-mvc
However, due to lack of response I'm considering just migrating the project to code first. I know that it is possible but I've been following tutorials online to no avail.
Could someone please explain to me how to properly move to code first. I'm even willing to recreate the program if necessary as long as it does not take too long.
I'd really appreciate some help.
Thanks
This really has been answered here.
I think you should really consider moving to ASP.NET Identity Membership, it's much more robust and has plenty of nice features without being difficult to manage. This is a really nice tutorial.
As for EF Code/Model first, you're thinking of them as something that defines your project; but really, they define a database CONTEXT. In other words, you can use both! Now don't get crazy, things can get sloppy quickly. But there is nothing that stops you from pulling in an existing set of tables and building models from them, but then adding another context to promote your classes into a database.
If you think of it as "switching" your project, you're getting it backward. And regardless, to get your models and database to sync, you need to either migrate your models or import your tables into EF. But it's a specific action you take, nothing happens magically. You COULD write your classes to perfectly mirror your database, create your EF models, and everything would work without you doing any direct connection (though you'd have a bit of a migraine afterward).
So don't worry about moving from one to the other. Just add a new context if you have a specific need to manage classes across different contexts.
But seriously, look at ASP.NET Identity to make all these problems go away...
We have a website application that stores data and pictures for a specific customer. We are about to release the same application for use by another customer. The second application will eventually be customized for the second customer. Eventually we hope to have several customers using their own versions of the application.
We are using ASP.NET in Visual Studio 2012. Should we:
clone the existing application and maintain separate code bases?
add a project to the existing solution for the new customer?
We have searched for an answer to but this seems to be a rare situation.
Thanks.
I dont think its rare at all. SAP and Maximo use this a a businiess model. Same core but each package customized to the clients specifications. I have done this (on a much much smaller scale) with some of the programs that we have.
We always start a new project rather than just copy the old. No telling what is in the old one that references the old client. Sort of embarasing when an About window that you forgot about is for someone elses company.
All the code, forms, reports that are customizeable should be in the project for that customer. All of the code, forms, reports that are standard should be in a library.
It really depends on the scope of the application. I've had to do this internally with the company I'm working for; I wrote one solution for one company, then the sister company found out and wanted the same and had to implement it there.
I had a fairly small project to work on, so it was easy to make it universal (while also keeping things rooting from the same code base). All i did was:
break out the unique setting [page title?] using appSettings or similar.
add a new configuration to your solution. Then take advantage of the *.config migrations to:
set connectionStrings
specify appSettings values
When it comes to unique business logic, I had the luxury of using the *.config migrations (most of the data I gathered came from WCF endpoints of services local to the company)--so I lucked out. However, you could make generic interfaces within the app then break out implementation for each company in to separate libraries.
For Dynamics CRM 2011, Microsoft suggests moving entity customizations from DEV to PRD by packaging the changes as managed (or unmanaged) solutions. Unmanaged is bad because you cannot remove the entities when you need to (deleting the solution only deletes the container, entities contained in the solution remain). In most lab examples during training, you’d customize the system, then export the customized entity as a managed solution, then import it into production. This solution-based approach is clean, makes it easier to control what’s in PRD, bundle related entities together, track dependencies, etc, so I get that.
There are times, however, when you need to dump the org on the DEV server and restore from PRD (to address a data-specific issue or for other reasons). We do that by disabling, then deleting the DEV org, then asking the DBA team to restore the CRM database from production, then we import the org back to the DEV server. But if we implement this “managed solutions”-based change migration process, won’t we lose the ability to change our entities after we dump DEV and recreate it from PRD, where these solutions are sitting in read-only mode? If we enable customizations in these managed solutions, will we be able to add new entities to the solutions or remove entities from inside the solutions without deleting the entire solution? Because I thought managed solutions are treated as a single unit of code, so it’s either delete all or delete none. Interested in learning how others have resolved this issue.
One way we have handled this is using a seperate clean dev machine which we use to manage the configurations as the "configuration master". That machine is not used for any other dev or test work. The dev machines for plugsin, etc. can be rebuilt from prod, but this machine continues to be the master for all solutions. Not an ideal solution, but it does avoid the "feature gap" of being able to convert managed solutions to unmanaged (maybe through some password facility)
I would advise against using solutions in these type of dev-to-testing-to-prod situation.
If you are unsure about this try to remove an entity in your dev environment and publish the change to your production environment.
Solutions are inclusive meaning that CRM doesnt remove fields and entities that where deleted in your solution.
The only way to remove an entity is to uninstall your solution therefore deleting the production data in all entities covered by your solution!
While in theory solutions seem perfect they are only usefull for third party vendors.
The goal of beeing able to rollback by uninstalling your solution is a pipe dream. Consider a data model update that involves data conversion. No magic function will reverse that.
It is a far simpler and reliable to restore your backup.
I'm currently investigating ASP.NET MVC 2 and LINQ to SQL. It all looks pretty cool. But I have a few application and development lifecycle issues.
Currently, I design the DB in SqlServer Management Studio.
Then I update my DBML files by deleting and re-importing modified tables.
Issues:
I can't find how to simply update the whole DBML schema.
My DBML then loses some of the changes I made such as renaming relation members or mapping of some int to an enum.
If I want a SQL script to deploy my DB (or to keep the schema under source control), I need to go use the 'Genererate Script' SSMS wizard which would be cool if a) it could remember my settings and b) it could be automated.
Should I work the other way around (start from my DBML and generate the DB)? Should I go for some other framework (NHibernate? Can I use some Linq flavor with it?)
Also, I read that LINQ2SQL is already obsolete in favor of Linq to Entities. Does it mean that the ultimate tool supposed to make my life so much better will again make me lose time in the long term?
Thanks for shedding some light.
If you are starting your DB Schema from scratch you could consider "Code-First Development with Entity Framework 4" as outlined by Scottgu.
I have been using this on a new project and am finding it extremely beneficial - especially for testing.
I started with simple POCO classes representing my data, then as the project progressed I would allow EF4 to generate the schema to a "real" DB using my "in-memory" example data ... now I am using a mixture of both in memory POCO (for development and TDD) and auto-generated DB Schema (auto-loaded with more "realistic" data) for demonstrations etc ... so far I am very happy.
There is a lot of opinion over LINQ2SQL and whether it's 'obsolete' or 'discontinued'. But it is still in the .NET framework and a good tool, so if it suit your needs then you should use it. Frankly the Entity Framework is still not perfect and if you don't need the extra flexibility that it affords then it is not worth the pain. If I had a small to midsize project then I would definitely use LINQ2SQL again (and over EF).
As for your question, yes you'll lose any names or different type mappings when you remove and re-add a table. The options that I'm aware of are
Only remove / re-add the table that has changed (not all tables)
Try altering the DBML tables in place, rather than remove / re-add. You can add and remove columns, change column names and data types, add relationships all on the DBML.
I like JcMalta's suggestion of creating objects as classes before rendering into the database, but if you find SQL Studio to be quick to develop with then it might simply be quickest to create tables there are drop them into your DBML. It's a touch annoying to have to change something in a database and the push the changes into your code but the code-gen tools are quite good and take away most of the pain.
You can try CodeSmith/PLINQO to auto-sync DB/code:
http://plinqo.com/
As a follow-up, just wanted to say that I eventually found and fell in love with Huagati DBML/EDMX Tools.
To be totally honest, I must say that the price has significantly increased since I purchased it. I believe it is still worth the money anyway.
And for people who are looking for the same kind of tool for MySQL (or other), DevArt is your friend.