Yesterday we encountered a worrying blocking error when expanding the Application node under a BizTalk Group in the 2006 Administration Console:
Failed to create ApplicationNode (Microsoft.BizTalk.SnapIn.Framework)
Additional Information:
Exception has been thrown by the target of an invocation. (mscorlib)
Failed to enable constraints. One or more rows contain values violating non-null , unique or foreign-key constraints. (System.Data)
All of the servers in the Group were affected, this suggested to me that there was some corruption in the management database given that we had been performing a deployment of new assemblies just before it occurred.
One possible resolution to the problem - repair the BizTalk installation - was discussed on MSDN, but that didn’t appear to work in our case; Instead, restarts of all the servers in the Group (3 servers in total) resolved the problem.
Not a satisfactory resolution, but one which worked nonetheless; we’ll be keeping a close eye on the environment in future….
Nick,
Ive also seen this one before quite a while ago. I think I vaguely remember something like one of the services being stopped caused it (WMI service seems to ring a bell).
Anyway the fact that with a restart of your BizTalk servers this started working again would seem to fit with this as if a service had stopped it would be likely to restart when the box is rebooted.
If I remember more ill drop you an email
Mike
Thanks Mike,
We were thinking the same, but restarting the *service* should be good-enough - it shouldn’t really need a server restart!
Nick.
Nick
I have seen this happen very often when deployment is happening on a clustered Biztalk server kind of scenario. Especially when deployment is happening (MSI import) on one of the clustered server and someone goes into the other clustered server and tries to open the admin console.
Usually it fixes itself once deployment is complete. Sometime restarting HI’s or “services” is needed.
I dont see a need for a server restart
Hema
Hema,
Thanks for the feedback re. clustered installs - a restart of all 3 servers in the Group did seem a bit extreme to me too; If I ever see this problem again, I’ll bear your advice in mind.
Cheers, Nick.
Hi Nick,
I just had the same problem on our build server. It wasnt the WMI service, it was actually when I restarted the Distributed Transaction Coordinator Service which fixed it
Hello Mr New British MVP!
I wonder whether it is something to do with the MSDTC caching data? Odd one anyway…
Nick.