NotNowNigel

[Concrete / Mildly Interesting] Sometimes SQL Server makes you want to pull your hair out. If you are using XML types in your stored procedures and seeing some  very poor performance, I may have an answer for you in this post.     XML is working, but maybe a little too hard Today I was looking at the performance profile of one of our applications and after a little digging I noticed that a stored procedure was performing rather poorly. We pass a lot of parameters to some of our stored procedures and when we do this we use XML. This technique allows you build parameters using LINQ XElement types and with LINQ to SQL, simply pass the XElement as a parameter to the stored procedure. It’s a great technique so it’s even more disappointing to see it perform so badly. And what’s worse, it seems it’s the simple operation of fetching out the data using nodes() that causes all the problems. To illustrate this, take a look at the following XML: < Transaction > ...

[Concrete/Interesting] I’ve been working with a small team on an iPhone project. I bet half of you out there are doing something similar. One member of the team is struggling with Objective-C – I need to understand the costs and benefits of native development on the iPhone. The rest of us are working on a WebKit browser app for the iPhone . Naturally, I decided we must use REST to provide a good balance of speed and functionality on the device. I’m using the jQTouch framework (based around jQuery 1.3.2 )with a bit of AJAX on the device framework and the server is developed in C#. The REST service is implemented under WCF, so building server side is a dream (see REST in Windows Communication Foundation ). Team working is a breeze – we have a basic data model and use this for reference. However, under my direction we are building up the solution screen by screen, focusing on the end user application and looking server side when we need data or processor. The team works very well be...