October 26, 2017 at 7:01 am
Hi everyone,
i have a strange behavior in our SQL-Server. The Machine is a Win2102R2 with SQL-Server 22014 EE on it. It is holding an AAG with automatic –failover.
The Database is connected with a DynamicsAIX 2012 CRM. During a planed patchday a wrong net framework was installed (Version 4.7) . The CRM did not like that.
After uninstalling the wrong software, everything seemed to obe fine. But on at least two tables the entries in one Column was shortend to 10 digits. The tabledefinitions are still the same (varchar(80)).
All other instances like Test and Integ where not affected but here was no worng softwareupdate.
I can not find any strange logentries in SQL-Server log or in the Windows eventlog.
Did anybody see such a mess. At the time oft he patchday, there were no changes from the developpers towards the CRM (thats what they said).
Any idea is welcome.
Kind regards
Stefan
October 26, 2017 at 7:42 am
stefan_hufnagel 24357 - Thursday, October 26, 2017 7:01 AMHi everyone,i have a strange behavior in our SQL-Server. The Machine is a Win2102R2 with SQL-Server 22014 EE on it. It is holding an AAG with automatic –failover.
The Database is connected with a DynamicsAIX 2012 CRM. During a planed patchday a wrong net framework was installed (Version 4.7) . The CRM did not like that.
After uninstalling the wrong software, everything seemed to obe fine. But on at least two tables the entries in one Column was shortend to 10 digits. The tabledefinitions are still the same (varchar(80)).
All other instances like Test and Integ where not affected but here was no worng softwareupdate.
I can not find any strange logentries in SQL-Server log or in the Windows eventlog.
Did anybody see such a mess. At the time oft he patchday, there were no changes from the developpers towards the CRM (thats what they said).
Any idea is welcome.
Kind regards
Stefan
Your suspicion is that a .NET Framework installation resulted in modifications to data in a certain column of a database? I really can't imagine how that would do it.
However, the combination of the CRM app and the 'wrong' framework could have done it, I suppose.
Presumably, you've been able to restore the data now and all is well? Or are you looking for restoration options?
October 26, 2017 at 7:49 am
stefan_hufnagel 24357 - Thursday, October 26, 2017 7:01 AM
Your suspicion is that a .NET Framework installation resulted in modifications to data in a certain column of a database? I really can't imagine how that would do it.
However, the combination of the CRM app and the 'wrong' framework could have done it, I suppose.
Presumably, you've been able to restore the data now and all is well? Or are you looking for restoration options?
Hi Phil,
we have restored the database and we fixed the two tables. But I have to write an incident report for your customer. And to avoid the mistake the next time i would like to know what had happen.
Kind regards
Stefan
October 26, 2017 at 8:01 am
stefan_hufnagel 24357 - Thursday, October 26, 2017 7:49 AMHi Phil,we have restored the database and we fixed the two tables. But I have to write an incident report for your customer. And to avoid the mistake the next time i would like to know what had happen.
Kind regards
Stefan
If you cannot find any evidence elsewhere on the web that MS CRM + the wrong version of the .Net Framework can cause unexpected updates of data, you are in a difficult position.
You could attempt to reproduce the problem on a dev server somewhere. If you can, that's good (for you) and you can go ahead with your report.
If you cannot reproduce the problem, I'd suggest doing some more detailed forensics on the corrupted database to attempt to understand exactly what changed, when it changed and the nature/logic behind the change. Perhaps that will give you some more ideas.
October 26, 2017 at 8:13 am
Phil Parkin - Thursday, October 26, 2017 8:01 AMIf you cannot find any evidence elsewhere on the web that MS CRM + the wrong version of the .Net Framework can cause unexpected updates of data, you are in a difficult position.
You could attempt to reproduce the problem on a dev server somewhere. If you can, that's good (for you) and you can go ahead with your report.
If you cannot reproduce the problem, I'd suggest doing some more detailed forensics on the corrupted database to attempt to understand exactly what changed, when it changed and the nature/logic behind the change. Perhaps that will give you some more ideas.
I have googled around lots off combinations from SQL-SERVER & CRM & net framework & trim data ..... with no result. We can not reproduce the problem because we are only respondsible for the database, we have no information about the CRM itself. Maybe the customer agrees toward a new testsystem with crm. Lets see. luckily, i was not respondsible for the patchday and the software installation.
Thank you, for your advice!
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply