bpf error after upgrade crm dynamics to on prem 9.0.5 - dynamics-crm

after successfully upgrade to dynamics from 2016 8.1 to 9.0.5 on prem,
we encountered a problem with business process flow,
as we know each bpf has its own entity in the DB,
we use an OOB bpf in incident entity that called phonetocaseprocess,
the problem is that i saw after the upgrade that the newly table created for
that bpf - is empty :() , so all the current incidents failed on update because
i get an error that said that : phonetocaseprocess With Id = 196dc1e2-466f-e911-80e6-
00155dc4022d Does Not Exist.
when i create a new incident record it works fine and a record is created in
phonetocaseproccess table.
someone encountered that? or have an idea? thank you
UPDATE
we were able to resolve this by running the script provided in the above forum before the upgrade run, after this the upgrade was successfully completed.
https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/232669/business-process-flow-instance-exists-error-after-crm-2016-upgrade/639024
The problem occurred because processes in the source environment did not have a unique name in the database, which resulted in the upgrade not converting the data to the correct table in the DB but to another table in new_bpf_guid format.
hope this will help someone

That's because your existing records are related to the older process and that the process in the newer version has different GUID. See the snapshot below:
To correct this, you have to migrate the process entity data with the existing primary keys in the older version.

Related

Microsoft Dynamics CRM, associated entities does not pull up records

We have a on-prem instance of Microsoft Dynamics CRM. The associated entities in all the forms come up blank and no records show up.
When I get this error in on-prem environments, it's usually because the database is getting pinged and queries to it are timing out. You may want to check the database to see if it is being overwhelmed and unable to return data.
we ended up updating the CRM version to resolve the issue.
temporary fix was implemented by restoring a backup of the database.

Delete Oracle Change Notifications

I'm trying to deregister change notifications in Oracle 12c by executing:
DBMS_CQ_NOTIFICATION.DEREGISTER(24906);
But this gives an error:
ORA-29970: Specified registration id does not exist
Although when I query the USER_CHANGE_NOTIFICATION_REGS view it does clearly state the correct regid.
Any one encountered this problem?
(Doc ID 971412.1)
How Can Database Change Notifications Not Created With PL/SQL Be Removed?
[ Last updated on JULY 05, 2017 ]
Applies to:
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.2 [Release 10.2 to 11.2]
Oracle Data Provider for .NET - Version 10.2.0.1 to 11.2.0.1 [Release 10.2 to 11.2]
Information in this document applies to any platform.
Checked for relevance on 14th Dec 2016
Symptoms
You have an application that creates database change notifications via the OCI API or a higher level API that exposes this functionality such as ODP.Net. It does not create the notifications via PL/SQL, either through a stored procedure or PL/SQL block.
This application exits without cleaning up those notifications, typically via a fatal error as any controlled shutdown should remove any notifications. Or it may be that the application is still in development and the code to remove the notifications has a bug, or hasn't been added yet.
This leaves orphaned notifications in the database, which cannot be removed because they can only be removed within the same session in which they were created. Neither can they be removed with the PL/SQL function DBMS_CQ_NOTIFICATION.DEREGISTER(); this throws the error:
ORA-29970: Specified registration id does not exist.
Solution according to the MOS-Note:
Use patched Oracle version (bug fix included in 12.1 or later and the 11.2.0.4 Database and Client patchset)
enable following event to consume the fix: event "10865 trace name context forever, level 1".

SONAR 3.7.3 database update failure - JDBC Error

After installing SONAR 3.7.3 I received the following error on startup: "o.s.s.p.DatabaseServerCompatibility Database must be upgraded. Please browse /setup"
I then followed instructions to upgrade the databse by navigating to http://:/setup. However, when I click update databse I get the following error
The migration failed: An error has occurred, all later migrations canceled: ActiveRecord::JDBCError: ORA-01430: column being added already exists in table : ALTER TABLE reviews ADD manual_severity NUMBER(1).
Please check the logs.
I can see, as the message suggests that the table reviews already exist and it already contains the column manual_severity, so I'm not sure why its trying to re-add it.
Any ideas?
I would use a backup of the database schema and start the process again from the beginning.
If you don't have a backup, I cannot see any other way than to delete the column in your schema and try to migrate the database again, but you might find a lot of errors of this kind and have to repeat this operation some times. Also, you will never be sure that your DB is Ok.

Pre-Installation Check Mantis: can't install

I am trying to install Mantis on my server. Problem is that I can't seem to get pass the Pre-Installation Check step. I click on "Install/Upgrade Database", and displays all "GOOD". Then it says:
Database Creation Suppressed, SQL Queries follow
<< here it prints a lot of sql queries, mainly create and alter tables >>. When I say this the first time, I went to MySQL Workbench, (the database bugtracker was already created), and ran the script given. Thereby, creating all the needed tables.
Then it says:
Your database has not been created yet. Please create the database, then install the tables and data using the information above before proceeding.
It checks a few more things (all with result "GOOD") and finally it displays this message:
Install was successful.
Continue to log into Mantis
The previous word "Continue" appears as a hyperlink leading to login_page.php. When I click it, it leads right back to this pre installation check page.
The thing is, the database is created! And the first time I encountered the sql queries I ran them, so the tables are indeed created.
Attempting to connect to database as admin GOOD
Attempting to connect to database as user GOOD
Checking Database Server Version
Running mysql version 5.5.25
My PHP version is 5.3.14.
The Mantis version i'm trying to install is 1.2.11.
Any ideas as in what it is I am doing wrong? Or any other piece of information I could provide?
I realize now that this is not the best place for this question. Nonetheless, in case someone else happens tu stumble across this, I wanted to let know the only workaround I could find was installing another Mantis version: 1.1.1. Very old, but it worked!

MS CRM can't add users after database restore

We have restored an old ms CRM database over a newer version. But when I try and add users which were already existed in newer version I get an error.
If I delete the users from our of active directory and then try to add them to CRM it works fine.
Is it possible that CRM is storing user information in the MSCRM_CONFIG. And can this be removed in a supported way?
Have a look at the SystemUser in the MSCRM_CONFIG table, I think i need to remove the users from this table. but I can't do a delete statement as it's not supported. :)
Did you restore this database using the Deployment Manager tool or simply by doing a SQL Restore? Doing this directly from SQL would cause issues. You'll need to delete the organization in the deployment manager and then delete the database in SQL. Then you should attach the database and recreate the organization from the deployment manager, pointing it to the existing database.
Restoring just the org DB can lead to issues as some user info is stored in the config DB as well. In fact, there are entries in there mapping the user to the org (SystemUserOrganizations), so when you restore the Org DB, this mapping is now out of date.
You would need to either go the Delete/Import route or manually do some unsupported cleansing of the Config DB Tables.

Resources