Patrick Wellink - All Comments

re: Excellent post of Charles Young about Dublin and BizTalk

Erwyn van der Meer — Thu, 16 Oct 2008 13:39:21 GMT

Thanks for the link. Interesting read, even for a Microsoftee ;)

re: Excellent post of Charles Young about Dublin and BizTalk

Patrick Wellink — Thu, 16 Oct 2008 12:01:01 GMT

oops

re: Excellent post of Charles Young about Dublin and BizTalk

Jean-Paul Smit — Thu, 16 Oct 2008 08:37:53 GMT

Your direct links don't work......the link to the blog of Charles does.

re: How to expose an old style WSDL with the schema's included from BizTalk 2006 R2 with a WCF adapter

Patrick Wellink — Tue, 07 Oct 2008 06:10:45 GMT

Oeps !!

verbeterd

re: How to expose an old style WSDL with the schema's included from BizTalk 2006 R2 with a WCF adapter

Jean-Paul Smit — Mon, 06 Oct 2008 13:29:21 GMT

Als je de machinenaam onlees wil maken, haal hem dan ook uit de titelbalk van IE :-)

PiRootOfPi Blog » Blog Archive » Copy Files From Global Assembly Cache (GAC)

PiRootOfPi Blog » Blog Archive » Copy Files From Global Assembly Cache (GAC) — Fri, 03 Oct 2008 18:37:40 GMT

Pingback from PiRootOfPi Blog » Blog Archive » Copy Files From Global Assembly Cache (GAC)

BizTalk Web Service Publishing Wizard Error: Method not found: System.Xml.Serialization.XmlMapping.get_ElementName()

BlogNote — Sat, 02 Aug 2008 14:59:35 GMT

BizTalk Web Service Publishing Wizard Error: Method not found: System.Xml.Serialization.XmlMapping.get_ElementName()

Updating repeating nodes in an XML Document with the same value using XPathMutatorStream « Connected Thoughts

Sat, 31 May 2008 10:40:50 GMT

Pingback from Updating repeating nodes in an XML Document with the same value using XPathMutatorStream « Connected Thoughts

Updating repeating nodes in an XML Document with the same value using XPathMutatorStream « Connected Thoughts

Sat, 31 May 2008 10:40:46 GMT

Pingback from Updating repeating nodes in an XML Document with the same value using XPathMutatorStream « Connected Thoughts

re: Using a Bitwise AND in a BizTalk Send Port as a Filter Expression

Kenton Price — Thu, 20 Mar 2008 16:01:02 GMT

The Brits on this project have had a bet known as a Wags for such technical arguments: whoever wins the argument gets the loser to buy them dinner at Wagamama in Amsterdam. Had we bet it, I would certainly have lost my first Wags to you on the existence of this operator - well done :) I can't find any significant documentation on it, beyond a passing mention in Charles Young's seminal How Subscription Works blog entry. As we saw yesterday, if you add a send port and click Filters, before you select any promoted property you can select the "&" from the Operator dropdown - however, unless you have any promoted properties of type unsigned int deployed (which you don't in a default BTS install), the "&" then immediately disappears from the Operator dropdown!

re: The truth about Dynamic SQL and Stored Procedures....

Patrick Wellink — Tue, 08 Jan 2008 07:44:24 GMT

I understand your point but I have seen bad Dynamic SQl as well...

But your statement :

you can handle large amounts of data in them much more effeciently than via code. Because that's what SQL Server or Oracle do best. If you need performance, do it at the source.

I totally agree with you at this point. But this implies that you have yo implement some logic in SQL.

You sould always consider where you put stuff. For simple selects and updates it's ok to use dynamic SQL. But as soon as the words 'Large amounts of data' are uttered you should consider switching to Sproc's. Unfortunately this also means you have to implement part of the Business logic in SQL as well.

re: The truth about Dynamic SQL and Stored Procedures....

Dennis van der Stelt — Tue, 08 Jan 2008 07:03:12 GMT

Patrick, there's not a good reason to have thousands of lines of code in a single method, and there isn't one to have them in your sproc. But still people do so.

Of course this isn't about that you can never use stored procedures. Because sometimes, you can handle large amounts of data in them much more effeciently than via code. Because that's what SQL Server or Oracle do best. If you need performance, do it at the source.

But my problem with stored procedures is that so many times I come across them when there's so much business logic in them. And they're still harder to debug than regular code. People should use stored procedures for retrieving and changing data. Not for business rules or all other kinds of stuff...

re: The truth about Dynamic SQL and Stored Procedures....

Chilberto — Mon, 07 Jan 2008 21:35:02 GMT

An important factor in this discussion should be what is being built. A lot of smaller systems do not require the overhead of stored procedures and would probably benefit from a more "fluid" development environment.

From my standpoint, I prefer stored procedures for business applications that will involve more than one developer over its lifetime. They tend to be easier to maintain, analyze and tune.

re: The truth about Dynamic SQL and Stored Procedures....

Patrick Wellink — Mon, 07 Jan 2008 20:16:48 GMT

I have build stored procs of hundreds of lines. This sproc came instead of a sproc of a couple of lines. (The programmers never thought it would get slow) but in time the database grows, and finally they end up with a menu that's just tooooo slow.

This was for the Main menu of I-Mode. So when the simple query didn't work within the specified time frame, it was very simple to rewrite the query and use some logic to speed it up.

So then we ended up with a versiopn 1200 times faster then the original.

This kind of tuning simply cannot be done via dynamic sql. (Sure, you could rewrite the query and compile the dll and deploy that. but that has way more impacht then changing a sproc)

Don't get me wrong, I am not against Dynamic SQL. But I aint against SPROC's eiter.

And you hit a very good point in your comments. You must Optimize them both.....

But who would you trust more to deliver performant code. A programmer or a DBA ? personally I would think a DBA would deliver more performant databases.

And finally dennis, I wont say a sproc of thousands of lines is all that well either. But maybe there was a very valid reason for doing it, or maybe there wasn't one.

re: The truth about Dynamic SQL and Stored Procedures....

Dennis van der Stelt — Mon, 07 Jan 2008 19:35:39 GMT

If you can optimize/tune stored procs, you can optimize dynamic sql. Simple.

Same goes for LINQ to SQL or other O/RM, you must optimize everything. And choose the correct technology to solve problems. LINQ to SQL or other O/RM help you solve problems by making them easier. If you need complete control over performance, use a stored proc.

I've seen stored procs of thousands of lines. Tell me, how are you going to optimize that?