I was installing and configuring BizTalk Server 2013 for a client in a multi-server configuration (separate BizTalk application and BizTalk SQL servers). While configuring BAM, I received the following error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) (.Net SqlClient Data Provider)
Microsoft has released a hot fix for this issue:
To resolve the issue, apply the fix that is introduced in the following Microsoft Knowledge Base (KB) article:
FIX: The vertical scroll bar on the target schema does not work correctly when you use Visual Studio to design a BizTalk Server 2013 map
Note KB 2830546 includes the…
We have a great love for BizTalk 360 here at Tallan, and the many capabilities it affords to the realm of BizTalk monitoring, alerting, and governance. For those not familiar, BizTalk 360 is a web based portal designed in Microsoft Silverlight which monitors BizTalk environments and is designed to address the the common hurdles enterprises face when managing BizTalk environments.
Microsoft BizTalk Server 2013 was recently released and it includes many new features that make developing and deploying for BizTalk considerably more effecient. There are also many new features which expand on the already vast capabilities of a BizTalk Solution.
In this post I will go over the new features of Microsoft BizTalk Server 2013. And explain how a few of new features can contribute to a more efficient solution.
A few days ago I was troubleshooting an odd error in one of our pipe delimited flat file outputs from a map. The application was just migrated from BizTalk 2004 to BizTalk 2010, and had developed a unique problem. This file was showing what seemed like random carriage returns in the output flat file.
After ruling out any errors with the generic flat file assembly pipeline or map, I pinpointed the issue being spaces contained within the input to one of the maps. The input comes from a WCF SQL request-response port, and was contained within the data itself, not artificially inserted by the adapter. Since I was using default padding (space) for the flat file, a single space in the input XML was causing the flat file send pipeline to interpret the spaces as the start of a new record entry….