Sunday, 14 January 2007


Sometimes I run into this error, when deploying a BizTalk project from VS.NET: "An error has occurred while establishing a connection to the server.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"

I take a quick look at it, bang my head in the desk for doing it again, and then I perform the following steps:

  1. Rightclick on the project and choose Properties
  2. Go to "Configuration Properties" => "Deployment"
  3. Change the "Server" property to be the servername of the SQL Server you are deploying to
  4. Save changes
  5. Deploy again

This happens if you receive a copy of someone elses project - since the servername is listed in the projectname.btproj.user file that is a part of the project.

Hope someone else gets quickly past this hurdle now it has been blogged.


Sunday, 14 January 2007 21:43:48 (Romance Standard Time, UTC+01:00)  #    Comments [4]  | 


I have just had a client who was upgrading from the BizTalk Accelerator for SWIFT 2.3SP1 to the 2006 Message Pack, and it didn't go as expected.

Basically, after upgrading, using the migration guide found at, it didn't work. A warning appeared in the eventlog when trying an MT541 document:

An exeption occured inside the rule engine instance executing policy "MT541_Master_Policy"... Now, the obvious errors were checked for - the policy WAS deployed and undeploying it gave a whole new error. So something must go wrong at runtime, evaluating the policy. The policy only consisted of a single rule, but this rule has plenty of actions. I tried removing the actions one at the time, in new versions of the policy, and finally found out that it wouldn't work until I had removed ALL the actions.

So, basically, something must be very wrong.

The solution ended up being doing some assembly binding.

The migration guide states that:

"You must configure the assembly bindings on all computers in your environment using .NET Framework 1.1. You do not need to configure the assembly bindings for computers using .NET Framework 2.0. "

BUT, it is wrong! When using BizTalk 2006, which, as we all know, is running under .NET 2.0, you STILL need to do the assembly binding. You just need to do it using the .NET 2.0 Configuration instead of the .NET 1.1 Configuration, as written in the migration guide.

After that, the error disappeared, but another one turned up:

Now I was really mad. This error looks just like the first one, it is just another policy that is going wrong. Anyway, this turned out to be a known bug... sort of:;EN-US;928259 - the KB article states that it is for the Accelerator for SWIFT 2.1 - but actually it is for the 2006 MEssage Pack and applies to BOTH 2.1 AND 2.3.

So I was really in for a difficult job here - having to go against the migration guide form Microsoft and installing a hotfix that wasn't for this version of the accelerator.

I had actually given up, and I started a support incident with Microsoft, so all these steps were done as suggested by the support guy. The support incident hasn't cost me anything, as you might guess :-)

I hope someone else can benefit from this at some point.


Sunday, 14 January 2007 21:31:43 (Romance Standard Time, UTC+01:00)  #    Comments [3]  | 


Just read that the 70-630 exam in Office SharePoint Server 2007 and the 70-631 exam in Windows SharePoint Services 3.0 are now available.

Microsoft haven't got the web site quite up2date yet, but probably it wont take long.

Also, no MCTS certification is listed on the MCTS page yet. But since the two exam-pages refer to TS exam status, I suppose the certifications are on their way.


Sunday, 14 January 2007 13:44:19 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 


I was trying to help someone in the BizTalk newsgroups, creating a flat file schema, and I ran into this very annoying error message: "Unable to match the data in the input stream.". I got the error message after having created the schema and trying to validate an instance, using VS.NET 2005.

I searched and searched...

  • Someone needed to set the "parser_optimization" to "complexity" - I had allready done that.
  • Someone else needed to set the "lookahead_depth to 0 - I had also tried that.
  • Someone needed to set the input type to "Native" instead of XML. Had that been my problem, I wouldn't have blogged about it - I'd be too embarassed :-)

No, the problem was that I had created parts of the schema using the flat file wizard. It had set one of my records to have "minOccurs" = 18 and "maxOccurs" = 18 as well. Since my test instance didn't have that many records in it, I got this error message. Changing the two 18's to the default 1 solved my problem.

I hope Microsoft considers this and perhaps in future releases find a better error description :-)

In order to test it, you can just download the working schema: Exolit_FlatFileSchema.xsd (91.59 KB) and the test instance: Instance.txt (.72 KB) - it will validate. But try to change the minOccurs and maxOccures of the "Invoices"-record to "18" - and revalidate.

Anyway... Hope this helps someone in the future.


Sunday, 14 January 2007 13:41:33 (Romance Standard Time, UTC+01:00)  #    Comments [3]  | 
Friday, 05 January 2007


Should you ever run into this warning in the eventlog, when using the SQL Adapter for BizTalk:

your problem is that the SQL Adapter is receiving a result set instead of XML.

There are two possibilities:

  1. As we all know, when using the SQL Adapter to call a stored procedure, you must write "for xml auto, xmldata" (or some variant - I like the "elements" way of things) in your Stored Procedure in order to let the schema generator generate a schema for you. After the schema has been generated, you need to remove the ", xmldata" or else schema data will be returned every time the SP is called instead of real data. Anyway, sometimes people remove too much from the SP, ie. they remove the entire "for xml auto, xmldata" instead of just ", xmldata".
  2. Sometimes, someone forgets to write "for xml auto" after a select statement in the receive location.

Both will cause the above mentioned error.

Hope this has helped someone.


Friday, 05 January 2007 23:07:27 (Romance Standard Time, UTC+01:00)  #    Comments [4]  | 

Theme design by Jelle Druyts