Dec 012006
 

I am always having to modify the standard queries in HAT, so I finally broke down and created a new query in HAT.

This shows me the last 100 orchestrations run.

SELECT top 100
[Service/Name], [Service/Type],
[ServiceInstance/State],
dateadd(minute, @UtcOffsetMin, [ServiceInstance/StartTime]) as [StartTime], — can’t use ‘as [ServiceInstance/StartTime]’ since this prevents SQL from using index on that column (conflicts with ORDER BY)
dateadd(minute, @UtcOffsetMin, [ServiceInstance/EndTime]) as [EndTime], — can’t use ‘as [ServiceInstance/EndTime]’ since this prevents SQL from using index on that column (conflicts with ORDER BY)
[ServiceInstance/Duration],
[ServiceInstance/ExitCode],
[ServiceInstance/ErrorInfo],
[ServiceInstance/Host],
[Service/AssemblyName],
[ServiceInstance/InstanceID],
[ServiceInstance/ActivityID],
[Service/ServiceGUID],
[Service/ServiceClassGUID]
FROM dbo.dtav_ServiceFacts sf WITH (READPAST)
where [Service/Type] like ‘%Orchestration%’
ORDER BY sf.[ServiceInstance/StartTime] desc

 

The only other thing that you need to do is near the top of the trq file, you need to replace the title with:

<anyType _locID=”1″ xsi:type=”xsd:string”>Most recent 100 Orchestrations</anyType>

Save the file back in the Tracking folder as Top100Orchestrations.trq, restart HAT, and you are good to go.

Aug 232006
 

 

When running non-atomic scoped database transactions across your network, sildenafil getting schemas from the wizard does not seem to exploit this little known fact. You need to make sure that DTC is enabled on both the BizTalk machine(s) and the database you are connected to.

Objects to check for:

  • In Component Services (Administration Tools) right click My Computer, dosage on the MSDTC tab, click on Security Configuration Tabl and Allow Inbound and Outbound Communication.
  • In Windows Components (Add/Remove Programs) click details of Application Server make sure that Enable network DTC access is checked.
Aug 152006
 

 

We had a power outage and our working BizTalk machines seemed to be unaffected. However when I tried to deploy any solution, check I got the following error: ‘Failed to load msxmlsql.dll’

The only article I found was this.

I applied the fix to my BizTalk machine, which did not fix the issue. Before calling support, I decided to reinstall everything, thinking that the power outage corrupted the file. I reinstalled everything, including the Operating System. Going through the install, I got to the Group component on the configuration, it would fail.

After a couple of days on the phone with MS Support, the SQL Support directed me that the msxmlsql.dll and msxmlsql.rll needed to be located in the SQL Server machine, not on the BizTalk Server. (The dll and rll doesn’t need to be located in the particular instances, but just the default installation of SQL Server).

After placing the file in the correct location, the installation seemed to be working correctly. I had to pull the files from SP4 install folders and place them in the correct location as per the KB article.

Hope that others don’t have to spend their time beating their head against the wall like I did.

(Which reminds me: Banging your head against a wall uses 150 calories an hour.)