PDC 2005
I'll be there, come by and see me at the DevelopMentor booth
Doh! Sorry to be late getting this on the wire but the Heartland Developers' Conference for 2006 is has been announced. This year its in Omaha and runs from 26 October and 27 October. Hopefully I won't find myself in China again...
In its 3rd year, HDC06 is the largest independent annual professional Microsoft development conference in the nation, organized by user groups, and focused on .NET development and other emerging Microsoft technologies. HDC provides regional developers the opportunity to experience sessions usually reserved for Tech-Ed and PDC at a much lower cost while retaining the same nationally known presenters. Over 2 days, 23 sessions, 2 tracks, and several networking opportunities, HDC06 is where you’re find top knowledge experts that can prepare you for next level development.
For only $125 Early Bird/$175 standard, each Attendee Pass includes:
1 Conference pass to 2 keynotes and all 23 ninety minute sessions
- Meals including breakfast, lunch, snacks, and coffee breaks
- Access to the “Developer Lounge” expo and activity center
- Wireless internet access throughout conference area
- Pre conference networking party including drinks and food
- Thursday night “Developer Jam” including food, drink, and a casino for prizes!
- Attendee Kit and a chance to win a monster 64 Bit Alienware computer
The speaker list is looking awesome too: Microsoft's own Jeff Brand, Don Bryner and Jacob Cynamon. MVPs Dave Donaldson, Robert Hurlbut, Rocky Lhotka, Javier Lozano and Andrew Troelsen and community rockstars Craig Utley, Phil Wolfe, Robert Boedigheimer, Tim Gifford, Matt Milner and Nick Parker. I'm planning of giving a couple of talks on SQL Server 2005 for Developers.
Register here. And remember, we're talking a mere $125 one of the best Microsoft-focused technical conferences in the Midwest.
As Greg and Wally have reported, I've been thinking about bringing back Take Outs as a PodCast. I'm pleased to announce with the the hosting support offered by Steve Wynkoop of SSWUG, its now a reality. The need-to-knows:
The RSS feed: http://feeds.feedburner.com/sswugorgradio
iTunes friendly feed: http://feeds.feedburner.com/SswugorgRadio?format=pcast
Episode one show notes and download file.
Let's roll!
There was an interesting questioned posted in one of the newsgroups I follow. Basically the poster wanted an example of how to partition a table of project information into by the project budget amount.
The example continues here.
Quick note to BobB: Sorry about the "continues here," but the example is a bit too long to flood the feed with... :)
When Ken Henderson asks, I listen. He's asked this question and there's been some good responses. My favorite is from Jeff Parker because its probably the most honest:
Most DBA's are not .NET programmers.
I'm not so sure that most DBA's aren't programmers at some level, though. Most DBAs do write code in T-SQL. Many of them are versed in scripting. For them programming means creating tools to help them do their job, not building applications. And that's why Jeff's statement is the most correct: .NET isn't about building tools, its about building applications. So while they get ideas embodied in the code, its a bit like asking a blacksmith how to build a skyscraper when you ask them about .NET.
And this is precisely why I think off by default isn't just a good security practice, its a good configuration practice. Many of other posters to this thread have noted that in and of itself, the hosted runtime isn't any more dangerous in its typical application and say, T-SQL code. SQLCLR used right doesn't try to much more than extend what SQL Server 2005 is already good at: processing T-SQL Queries. I've long believed that the best use case for SQLCLR is write functions that do complex calculations or that leverage something in the .NET Foundation Class Libraries that T-SQL is missing or is poor at. That includes things like financial functions, regular expressions and XML parsing. The idea is that we're just extending T-SQL via the CLR, not subverting or replacing it. Stored Procedures based on CLR are useful when you need to perform some CRUD operations as a result of procedural logic that's either easier to write and maintain in a .NET language or, again, you need to leverage some functionality in the framework like compression or Web Services. User Defined Types certainly have a place, but its no bridging business objects into in-proc environment. The best use for a UDT I've seen so far is to build composite scalar types, like complex numbers, geographical co-ordinates and so on. CLR triggers simply don't seem to do much for me. I'm hard pressed to think of cases where I wouldn't be better served to write T-SQL triggers that called SQLCLR UDFs when needed instead. Aggregators have some uses: obviously needed for UDTs and I've some other use cases for them.
Where I suspect we'll see the biggest security issues with SQLCLR is that folks won't take the "Extend T-SQL" message to heart. They've move business logic into the server and just assume that things work the they do in a non-hosted runtime. That may or may not be the case. For example, I've heard lots of people who got excited that they'd now be able to call SOAP Services from within SQL Server. And, sure, that's cool. But how do you know if you really trust the data your getting from that service? Or that the service is still the service you thought it was? My concern runs deeper too. Suppose you have a good chunk of business logic lodged in the server and you know its got holes. But fixing them means not only taking the application off-line for a while, but also the whole database. Maybe not so much of a problem for databases that just support a single application. Pretty much "no way" for a busy OLTP data warehouse.
But lets not forget on the best use cases for SQLCLR is to avoid writing something as an Extended Stored Procedure (XP). XPs are typically far more of a security and reliability concern than most developers and DBAs expected. At least SQLCLR gives SQL Server better control over the code and runtime while being nicely meshed into the current security model for other objects. I'd much rather tell somebody to blindly enable SQLCLR before I'd encourage them to use an XP.
This sort of answers Ken's third question: If you see SQLCLR as a security threat, what specific issues are you worried about? How do I answer Ken's second question: Do you think it makes sense for security-conscious users to disable SQLCLR and avoid apps that use it? The answer is yes and no. Yes, I do think that unless you have a good reason to enable CLR support in the first place, leave it off as it is by default (so logically, no, they shouldn't disable it, it's already disabled). Should it be avoided? That depends on the specific case. I'd say that the unless the DBA knows, understands and can support the code that coming onto the server, he or she might be well served to avoid it. But that's not specific to SQLCLR. The same holds true of T-SQL objects and Extended Stored Procedures. The best way that most DBAs will "grok" SQLCLR is if its presented as an simply extending T-SQL.
So while I'm relatively enjoying my time in Shanghai, I'm missing HDC -- the Heartland Developers Conference -- since I'm missing the chance to reconnect with friends and associates like Dave Donaldson, Robert Hurlbut, Rocky Lhotka, Javier Lozano, Matt Milner, Phil "McCracken" Rieck and of course and Joe and Phil. I've been following the blogs where I can of, course. But if you're at the HDC, please blog about and let me know your RSS address.
I'd like to give an shout of thanks to Robert Hurlbut for covering my talk for me. Robert rocks!
In the mean time, I'm watching Google Blog Search and Feedster for posts too.
One of the very cool things about working with DevelopMentor is that I've gotten a lot of airline miles built up. So far this year I've been too:
- New York twice
- Denver
- Atlanta
- Las Angeles three times, one for PDC
- Orlando for TechEd
- Dallas twice, once for PASS and the MVP Summit
But tomorrow is by far my longest trip. I'm off to Shanghai to teach Essential SQL Server 2005 at the Microsoft Offices for five days. While I'm dreading the flight (its at least twenty-hours from Omaha to Shanghai going via Detriot and Toyko), I'm looking forward to being someplace I've never been before. I probably won't be blog much technical for the next few days, but I will be posting my trip notes and photos on this blog. Specifically:
Blog posts about this trip: http://www.sqljunkies.com/WebLog/ktegels/archive/category/1063.aspx (RSS: http://www.sqljunkies.com/WebLog/ktegels/rss.aspx?CategoryID=1063)
Photos (feed): http://www.sqljunkies.com/WebLog/photos/ktegels/category1064.aspx (RSS: http://www.sqljunkies.com/WebLog/photos/ktegels/1064/pictures_rss.aspx)
When I get back, I have a few days to adjust then I'm off to Boston to teach this class again (love to see you in it, details at http://www.develop.com/training/course.aspx?id=180), then a brief rest and I'm back to LA to do it again. on November 28, Niels and I will be team up to deliver DevelopMentor's famous Guerrilla SQL Server 2005 in London (http://www.develop.com/training/course.aspx?id=231) and I must say that I'm eager for that. Finally: If you're in the Redmond area, we'll be rolling into the Microsoft Conference Center the week of 12/12 as well (http://www.develop.com/training/course.aspx?id=245)
Note to my fellow Microsoft MVPs: Don't forget that DevelopMentor wants you share in the fun (http://www.develop.com/press/MVPProgram.pdf)! Please let me know if you are interested in taking advantage of this offer for our Boston or LA Essential SQL Server 2005 offerings.
The title alone reminds me of an Ole and Lina joke, but no, seriously, I needed to generate a section of links for an ASP.NET 2.0 Web Site I'm working on out of an OPML export of blogs related to a given topic. Now, sure, I could have done this some hard way, like with XLINQ or XSLT, but why bother when we have the simplicity of XQuery at hand in SQL Server 2005. Consider the following query:
set @opml ='<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- OPML generated by UserLand Frontier v9.0 on Fri, 23 Jul 2004 23:41:33 GMT -->
<opml version="1.1">
<head>
<title>ourFavoriteFeedsData.top100</title>
<dateCreated>Fri, 02 Jan 2004 12:59:58 GMT</dateCreated>
<dateModified>Fri, 23 Jul 2004 23:41:32 GMT</dateModified>
<ownerName>Dave Winer</ownerName>
<ownerEmail>dave@userland.com</ownerEmail>
<expansionState></expansionState>
<vertScrollState>1</vertScrollState>
<windowTop>20</windowTop>
<windowLeft>0</windowLeft>
<windowBottom>120</windowBottom>
<windowRight>147</windowRight>
</head>
<body>
<outline text="Scripting News" count="580" xmlUrl="http://www.scripting.com/rss.xml"/>
<outline text="Wired News" count="546" xmlUrl="http://www.wired.com/news_drop/netcenter/netcenter.rdf"/>
<outline text="Boing Boing Blog" count="519" xmlUrl="http://boingboing.net/rss.xml"/>
<outline text="The Scobleizer Weblog" count="460" xmlUrl="http://radio.weblogs.com/0001011/rss.xml"/>
<outline text="Slashdot" count="347" xmlUrl="http://slashdot.org/slashdot.rss"/>
<outline text="Joel on Software" count="328" xmlUrl="http://www.joelonsoftware.com/rss.xml"/>
<outline text="Jon's Radio" count="325" xmlUrl="http://weblog.infoworld.com/udell/rss.xml"/>
<outline text="Google Weblog" count="321" xmlUrl="http://google.blogspace.com/index.xml"/>
<outline text="Jeffrey Zeldman Presents- The Daily Report" count="312" xmlUrl="http://www.zeldman.com/feed/zeldman.xml"/>
<outline text="kuro5hin.org" count="301" xmlUrl="http://www.kuro5hin.org/backend.rdf"/>
<outline text="Dilbert" count="297" xmlUrl="http://dwlt.net/tapestry/dilbert.rdf"/>
<outline text="Gizmodo" count="284" xmlUrl="http://www.gizmodo.net/index.xml"/>
<outline text="Joi Ito's Web" count="276" xmlUrl="http://joi.ito.com/index.xml"/>
<outline text="The Doc Searls Weblog" count="245" xmlUrl="http://partners.userland.com/people/docSearls.xml"/>
<outline text="A List Apart: for people who make websites" count="231" xmlUrl="http://www.alistapart.com/rss.xml"/>
<outline text="The Shifted Librarian" count="226" xmlUrl="http://www.theshiftedlibrarian.com/rss.xml"/>
<outline text="Six Log" count="222" xmlUrl="http://www.sixapart.com/log/index.rdf"/>
<outline text="Tim Bray" count="220" xmlUrl="http://www.tbray.org/ongoing/ongoing.rss"/>
</body>
</opml>'
select @opml.query('for $feed in (/opml/body/outline) order by $feed/@title return <siteMapNode url="{$feed/@xmlUrl}" title="{$feed/@text}" description="{$feed/@text}" />')
And somehow I supposed to believe that XLINQ is easier than that? :)
http://blogs.msdn.com/anthonybloesch/archive/2005/09/26/TSQL_intellisense.aspx
I've been meaning post about this, but haven't really had the chance until now. I'm pretty glad I waited because of this comment about the post made by Dave Russell:
It looks to me like MS are going away from "most" developers having to hand-code TSQL anyway. They're introducing LINQ/DLINQ which gives you language constructs that ultimately map to SQL and, supposedly, optimised SQL much better than you or I would imagine. These do have intellisense, so TSQL intellisense suddenly becomes much less important in their eyes...... I wouldn't expect it in SQL-Server-Next either.
Prophetic on LINQ, I think. But I do believe we will see at least some level of Intellisense in future versions of SQL Server.
Will there ever be a .NET XQuery implementation from Microsoft?
I think is yes only if:
- Enough people "storm the gates" of folks like Michael Champion and Michael Rys demanding it.
- Sufficient demand can also be raised for XSLT, since, apparently, the building of an XSLT2 processor could bootstrap an XQuery processor quite nicely.
- Microsoft internal CLR team architectural mindshare leaders are willing to help resource the effort. The WebData alone probably lacks sufficient resources to do all they already have on their plates and this.
This doesn't even consider XLINQ. Part of the question that we the community need to answer is what doesn't XLINQ do for us as well as XQuery. Frankly -- having spend a good amount with both -- XLINQ wins if for no other reason that it gives us the ability to manipulate instances, not just query them. As I've said before, at least part of the reason that Microsoft doesn't have client-side XQuery in Whidbey (.NET 2.0) is that the standards body moved so slowly to produce a query-only spec. Yet clearly the need to both query and perform updates, modified and deletes on instances is really required by most applications.
So no, Joe, I don't think the stars are really aligned right for there to be client-side XQuery in .NET in the next few years. There's simply not enough user demand for it or for XSLT2 and, compared to XLINQ, its likely a lower priority for the team.
My biggest beef about all of this isn't that we likely won't have client-side XQuery or that we will have XLINQ. Pragmatically speaking, I don't care *how* I query as much as I care that I *can* query. However, as somebody that believes in open, community driven standards, I'm really disappointed to see things turn out like this. Some folks might say that "here's another case of Microsoft shoddly adopting a standard then trying to obsolete it." I really don't think that was anybody at Microsoft's intention here. Rather, management made the decision -- after looking at a number of alternatives -- and decided that it was best for their customers to go down a different path. Fine, at worst its shame on them for making that decision for us, but let's be honest: shame on us for not giving them a reason not to.
A few days ago, I mentioned that Dr. Michael Kay got me really excited with his "Learn XQuery 10 Minutes" piece over on the StylusStudio web site. He got me exicited enough that I put together a SQL Server 2005 flavored version of it! Because its a fairly long piece, and I'm feeling lazy about cleaning up Word's messy HTML output, I've published it here as a PDF. It has a supporting script as well that you can download from here.
Note if you're having a hard time making the images out, you can see them online at http://www.sqljunkies.com/WebLog/photos/ktegels/picture16876.aspx
Comments on this welcome this blog post. Please do and keep in mind that its fairly rough and unpolished. Wrote this while attending today's MSDN Event here in Omaha. Not that it wasn't interesting, but I wanted to get this off my plate before PASS.
Larry O'Brien has a good post explaining that DLINQ doesn't go from code directly to T-SQL. I'd like to chime in on this part of his post, though:
...In other words, DLINQ will resolve the query into native SQL and use all the appropriate database indices and execution plan optimization and so forth...
Not quite. DLINQ works with expression trees and generates database version specific SQL from them. So for SQL Server, yes, it generates T-SQL. But since DLINQ will work against OLE-DB and ODBC data sources, so it won't always be T-SQL. It is also up to the Query Processor to know from the query that indexes and optimizations it can apply, not DLINQ itself. So in a sense, the classic performance problems with dynamic SQL aren't mitigated at all, at least in the bits we have now. Its possible that future versions of DLINQ will reflect on the database schema looking at things like indexes, partitions and so on trying to build a better query plan that QP would by default.
And silly me, I really was half-wondering why we need Plan Guides in the first place. Guess they make sense now. :)
By now, I think everybody that reads the blog on a regular basis probably knows three things about me:
- I really like XQuery
- I really like .NET
- I really care about Databases
But that doesn’t mean that I’m all that thrilled with XLINQ even though it’s the intersection of those three things. That’s not to say that I don’t like or see the value of LINQ in general -- in my opinion it is a no-brainer and I’m very excited about it. But I do have a few non-technical nits to pick.
First, I can’t help but see the emphasis in delivering XLINQ instead of XQuery on the client side as anything but Microsoft creating and encouraging barriers between .NET and other technologies. With a working knowledge of XQuery, there was at least the idea that I could learn that and either Java or a .NET managed language and be able to more easily transition between the two worlds. XLINQ effectively means that I have to learn two different ways of doing things since what I know from the Java side isn’t doable with .NET. Sure, yes, there are many mutual instances where that’s true, but this is one that didn’t have to exist.
Second, the real value for me in XQuery wasn’t that it is "easier than XSLT" but rather, it is could have been a standards-based portable, universal way to query data. SQL tries to do that, but it is so Balkanized that truly portable code is either trivially useless or so rare and less than optimally efficient that it is just not worth the average developer’s time to invest in. Combine XQuery with semantically-enhanced schema (e.g., OWL) and we really could have build platform-agnostic, highly distributed queries over data, documents and knowledge. Maybe not terribly efficient ones as we understand things today, sure, but it is/was certainly doable.
Personally I liked the idea of XQuery as a fully-fledged scripting language for one simple reason: it would have been a good mixing of imperative and functional languages for solving a certain cl