November 2004 - Posts
...you better get on it ASAP. I'm hopefull that we're going to see a blizzard of activity there in the next few days related to SQL Server 2005 Express, Express Manager (XM) and build releases.
'nuff said?
Suppose for a moment that you could have access to any assembly you had a good use case for inside of some future version of SQLCLR that was "SAFE." What assemblies would you want? What could you do with that you can’t do today?
My biggest wish is for System.DirectoryServices since it is about the best way to work with identities and organizational data that’s not in SQL Server already (short of MS Identity Integration Server… that’s a horse of a different color…)
What would you vote for?
Christa points us to the The definitive word on SQLCLR. At least I know what I'm having for lunch today...
We've just published another whitepaper on MSDN, Using CLR Integration in SQL Server 2005, about your programmatic choices in SQL Server 2005 - CLR integration, T-SQL and xprocs - and how to choose between them. It is authored by a handful of the folks on the product team that designed & built SQLCLR, so if you want the authoritative take on when to use this feature, this is it.
I like doing things the simple way I guess. Here's an example of using the .nodes() method of an XML-type instance to produce a tabular shred of its data. Not hard once you figure out that its giving a new current context for each row.
Continues here.
Well now isn't this interesting... I've not cracked it open yet, but one of the big use cases I see for the XML type in Yukon is the storage, query and serving of WordDocs. Now sure, you can use XQuery to shape the XML you from those instances, but sometimes it might just be easier to let XSLT to the job. Of course, the problem is... how you write XSLTs against WordML?
Been there, done that. Got myself quite the headache for my efforts. So when John Durant posted this, it made my day:
Microsoft Word 2003: WordProcessingML Transform Inference Tool
Obviously, WordProcessingML is great because you can run a transform against the XML data files and get nicely formatted Word docs to send out to information consumers. But, what should the transform look like? How should you structure it? To be sure, there is no replacement for cracking open a good text on XSLT [ed: link added] and getting up to speed on it, especially when you want to do advanced things. However, the Inference Tool lets you create a "seed" document in Word where you load one of the raw XML data files into a doc and format it to your liking. You save the Word doc as an XML document marked up with WordProcessingML. Then, you run the tool against your saved file to produce the XSLT.
Ta-Dah! BRILLANT!
Kirk and I are having a lot of fun with this RSS issue. Here's an updated version of my previous example that copes with Unicode BOMs and pre-validates the fetched RSS before it attempts to store it. It demonstrates that typed XML really does validate everything...
Continues here.
There's been a brief discussion on the SQL Server 2005 XML newsgroup regarding RSS and the XML type on SQL, encoding and schema. In keeping with my recent series of code-heavy examples, here's the guts of a primvative little VB.NET console app that sucks feeds into a table.
The basic gist of the problem is that the XML type doesn't look at the content to determine encoding unless the source that being converted from is binary, but if an encoding is given in the prolog other than UTF-16 (in most cases), SQL complains that it can't switch the encoding. That's seldom the case with client side code where we are using SqlXml typed parameters. It seems the trick is to parse off the document prolog so that we're just feed the typed column data and not encoding information.
Continues at http://sqljunkies.com/WebLog/ktegels/articles/5013.aspx
There was a post this morning the SQL Server 2005 XML newsgroup that caught my eye. I don't know that I answered the poster's question exactly, but it lead to what I thought was an interesting example. So, here's another code-heavy article on showing how to do that.
This item from the W3C RSS feed caught my eye today. There's useful stuff in it your thinking about using SQL Server 2005 XML to work with Documents as Data.
More on my SQLJunkies.com Blog.
On Tuesday (the 16th) night, the Greater Omaha SQL Server Users' Group will be meeting at HDR starting at 6:00 PM. JC Novoa will be presenting on DTS in SQL Server 2000. Please let me know if you are interested in attending since seating is limited.
On Thursday (the 18th) afternoon, Mike Benkovich will be presenting the November 2004 MSDN event at the AMC 24. Details and registration here. Mike will be joining us for the Omaha.NET User Group meeting at Creighton University West. More details about that here.
Hope to see you there!
More Posts
Next page »