I'm in the middle of a contract that is porting a company's hand-rolled Microsoft Access-based CRM to Microsoft CRM 4.0. It's all gone pretty well, but now I have to migrate the data across.
The data is all over the place in the source .mdb. Lots of tables, lots of duplication, and generally shows all the signs of an ad-hoc database which has grown organically (like weeds) over time.
So, my dilemma is this. Do I bite the bullet and write lots of queries inside Access to export the data into some intermediate format that CRM can somehow import? Or is there some other way? Are there any middleware tools that map data from one to the other that anyone here knows about?
Note this is my first time using CRM, so if the question is obvious, I appologise.
Cheers,
Shane
Dynamics CRM 4.0 provides built in tool called Dynamics CRM 4.0 Data Migration Manager to help developers migrate data from previous database into Dynamics CRM 4.0 database. I haven't used it extensively, but as far as i know, the previous data needs to be exported into a "standard" excel format provided by CRM 4.0 Data Migration Manager (DMM).
You can refer to below references :
http://blogs.msdn.com/crm/archive/2008/01/04/microsoft-dynamics-crm-4-0-data-migration-manager-with-john-o-donnell.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=6766880a-da8f-4336-a278-9a5367eb79ca&displaylang=en
There is also 3rd party solutions called Scribe http://www.scribesoft.com/ that will help you migrate to Dynamics CRM 4.0 database
I've had success just using the mscrm api in these kinds of cases. You can write a .net app which use odbc to connect to your mdb then use the mscrm api to create the entities you need on that end.
Anyway you cut it - it's not too pretty but you can get the job done.
Good luck.
Ms CRM Service Reference
I am sorry to say, I think you have to bite the bullet and write queries to pull the data from various sources and use some intermediate database like access ( You may also use SQL server or any db)
In my experience of handling several data migration projects for various small and large enterprises, I have always uses MS access as my data massaging/pulling tool. It works great. It might sound a lot of work but it’s is definitely lot cheaper than buying any expensive tools and spending thousands of dollars configuring them.
I would recommend you save all your queries and write a macro to automate the import.
Hower trivial the query is, SAVE it. This will be very useful as you will have to do this again and again before you actually go live.
Once you automate it, it is just a matter of clicking a button.
Typically and data migrating project will undergo at least 2 iterations and it could go up to 10.
Once you have data in the intermediate database, you can use de duping tools to standardize and remove dups from your data. There are a lots of cheap tools available both online and offline.
Related
Microsoft Edge and other Microsoft products use an Extensible Storage Engine. If you have edge installed on windows, you can find the database file here:
C:\Users\username\AppData\Local\Packages\Microsoft.MicrosoftEdge_xxxxxxx\AC
\MicrosoftEdge\User\Default\DataStore\Data\nouser1\xxxxxxxx\DBStore\spartan.edb
I would like to read this database from my .NET app.
The only tool I have seen for viewing this data appears to be deprecated:
http://www.woanware.co.uk/forensics/esedbviewer.html
I can't seem to find any relevant nuget packages for querying this type of database. Does anyone have experience working with this type of database?
The database engine is esent.dll, and you can access it in several different ways:
C API. https://msdn.microsoft.com/en-us/library/gg269259(v=exchg.10).aspx
C#. https://github.com/microsoft/managedesent
Simplified C# (Isam layer). Easier to use, but not everything is exposed. https://github.com/Microsoft/ManagedEsent/tree/master/isam
(Disclosure: I've worked on the above products.)
That being said, if you just modify a random database, you can impact the host process's integrity, and it might end up crashing.
If you're a law-enforcement agent and it's for forensic purposes, Microsoft should be able to assist you (I haven't done it myself, but I've heard that they'll do it).
-martin
Ever since I started to work with TFS 2010 (through VS 2008 if it matters) and was tasked with producing administrative reports, I have had a lot of challenges. I know that there is an API and the Sidekick but neither give the details, scheduling capabilities, zero client involvement, or ease of use that my group requires.
After looking at one of the collection schemas, I only became more frustrated... We aren't using the testing/lab piece of the tool, so the only database relationships available are of little use to us.
My department is heavily involved with reporting branch activity/maintenance/administration, where the primary focus of the canned TFS reports is more towards work items and burn rates (not useful to my department).
Ideally, I would like to know what SQL is involved to achieve this without having to run a profiler against a branching process, decipher the logs, and decrypt all involved SPs/functions/views to identify the programmatic connections between each table involved so that a SSRS report (2008r2) can be developed to provide this scheduled information more dynamically...
I can't be the only person in a Release Management department that wants this info... Can anyone help?
I need to find a stand-alone (ie. no OpenOffice-based tools, for instance) Windows application that can present users with forms to enter records into an SQLite database. The goal is to migrate data from Excel sheets into a serverless, single-user database like SQLite.
As a bonus, the application would also have a somewhat-protected admin section so that I can also use it to CRUD data with the same app, but it's not a requirement.
There are a lot of applications listed on the official SQLite site: Can someone recommend one that is meant for end-users, either open- or closed-source?
Thank you.
Edit: the correct term I was looking for is "data entry form". Googling around didn't return a Windows application that makes it possible to easily write data entry forms to let end-users create/edit records, ie. with no direct access to the underlying tables.
I think FileMaker or Microsoft Infopath (May be with Sharepoint Services) could fulfill your needs completely. There are forms in both, validation, different available sources for keeping data, working over net. Both are very flexible and powerful. Infopath with Sharepoint Services can be installed and customized quite quickly.
I'm a junior VB.net developer with little application design knowledge. I've been reading a lot of material online regarding different design patterns, frameworks, and methodologies. It's become a bit confusing for me.
Right now I'm trying to decide on what language would be best suited to convert an existing VB6 application (with SQL server backend.) I need to update the UI and add more user functionality and reporting capabilities. Initially I was thinking of using WPF and attempting the MVVM model for this big project. Reports would be generated from SSRS.
A peer suggested using ASP.net and I don't have enough experience to determine what would be better. The senior programmers here are stuck on using VB6 and don't have any input on what to use. They are encouraging me to use the latest technologies.
This application would be for ~20 users in a central location. Ideally I would stick to a Microsoft .net language. Current interface is similar to a datagrid table where the user would click in to see the detail of each record. They would need to have multiple records open at any given time.
I look forward to all the advice I can get.
EDIT 2010/04/22 2:47 PM EST
What is your audience? Internal clients within an intranet
How complex are the interactions you expect to implement? not very... displaying data from SQL server to UI. Allow user updates to said data. Typically just one user modifying a record.
Do you require near real-time data updates? no
How often do you expect to update the application after the first release? twice/year
Do you expect a well-defined set of client platforms? Yes, windows xp environment, potentially upgrading to Win7. Currently in IE.6 moving to IE7 or 8 within a couple of months.
Do users need access from anywhere? No, just from their PC.
What would be wrong about building a simple ASP.Net application in VB.Net using Gridviews for allowing the data access and manipulation? Seems like a simple ADO.Net trial application if you aren't familiar with it in the beginning you will be by the end. CRUD applications are pretty common so it shouldn't be too hard to build it and then refine it as more requirements become apparent.
Sounds like you need to use a web-based solution--this eliminates alot of your potential distribution woes with multiple users. You could use silverlight, but if you are locked into SSRS, this might not be the way to go.
My organisation is in the final stages of acquiring CRM 4.0 for use as a general purpose software development platform. The company who is selling it to us has convinced upper management that CRM will solve all our productivity problems and make software development as easy as point and click. (They don't read Brooks.)
Having resigned to the fact that I can't stop CRM from being foisted upon us developers, I have been doing research on how to manage the complexities of large scale CRM development.
I have so far identified the following complexities that need to be addressed:
CRM seems wholly incompatible with basic configuration management practices.
Keeping the black box CRM database in bidirectional synchronisation with external LOB systems is both very hard and critical to project success.
What other complexities must I take into account when building a large scale CRM application?
What limitations does CRM have as a development platform?
Edit: This topic provided additional insight.
I've worked with MS CRM 3.0 and now 4.0 here's my take:
Whenever possible focus on standard best practices. Don't get overly confused by what CRM is doing or wants you to do.
Don't be afraid to break what's "supported" by MS. With some caveats on 2 major factors - will your company let you think outside the box to solve problems and do customizations/integrations that are not officially supported? - and are you comfortable enough with .Net, SQL, javascript etc to weave through their code and implement what you need?
I have sometimes banged me head 100 times trying to do something in a "supported" fashion when one small tweak to a js file here or a small db modification there gave me what I needed.
If constant data integration with other LOB apps is critical you should consider a 3rd party tool like Scribe (http://www.scribesoft.com/). It's not cheap but can basically get you 90% of the way when it comes to integrating with your other LOB apps.
As a general rule, MS CRM is great at contact management - doing things like tracking appointments, doing mail merges, etc. Could you use it as your core HR system - probably. Finance system - maybe a bit more difficult. The further you go from it's core competency of performing contact management the more custom work you'll have to do. The more custom work you have to do the more you should consider if MS CRM is the right solution to that problem.
I know you're likely well underway into your deployment of Dynamics CRM, but just a few quick tips:
I'd avoid making unsupported changes purely because it becomes too hard to track the changes eventually. Since Dynamics CRM allows developers to make C# Plugins and access to web services, it's usually unnecessary to make unsupported changes for anything non-trivial. Plus you run the roulette of having to hide changes from MS if you have to call their support. I know many people will include external javascript files (jquery, etc) and other somewhat benign changes, but try to mentally stop yourself when an unsupported edit involves anything non-visual.
Look into the phrase Microsoft Dynamics Xrm, there are several books on the subject that are excellent, http://www.thecrmbook.com/ is particularly good because it comes with some nice custom code to use with your CRM.
Source Control your customizations xml's and don't let people touch the database, also, Google Halan CRM tool, and use it for scripting out CRM customizations and javascript files. Easier than writing custom powershell scripts to do the same job.
Transaction Support
If your application require transaction support from the underlying platform, Dynamics CRM is not the correct choice. The reason is because currently Dynamics CRM SDK web service doesn't support transaction.
The reference thread is here : Does MSCRM web-service support database transactions?
Since you would like to utilize Dynamics CRM as a platform, that means all the business logic should utilize Dynamics CRM SDK Web Services as data access layer. But imagine without the transaction support and you're invoking a series of web service calls as a unit of work, and one of the web service calls fails. That means you potentially will encounter data integrity issue.
Configuration
Usually i create a custom entity called Configuration, which will store all the necessary related configuration for the current CRM application. After it has been created, you can use Dynamics CRM SDK Web Service to read all the necessary configurations from the Configuration custom entity