Monday, February 07, 2005 - Posts
I got nailed with a couple of good questions tonight that I could have answered better. One of them was “why would you choose to use SqlString vs. String in a SQLCLR object?”
- These types are direct mappings of the native types in the SQL engine
- They are faster since there is no conversion to a .NET type to cope with
- They are safer since there the semantics of the type match those with SQL Server, especially for conversion.
- They deal with nullability the way we'd think about it from a database point of view
- If an instance is nullable, setting it to dbNull.value works.
- If an instance isn't nullabe, setting it to dbNull value causes an SqlNullValueException
- When an operation would result in a significant loss of value throws an SqlTruncationException
The crux here is probably the safety factors rather than the performance aspects. Why? In the past, I've not been very diligent about using the the SQL-Specific types within the body of a method, but have been about making sure the method signature as for SQL-Specific types. Performance never really seemed less than I expected, except in one case where I was building -- rather than parsing -- strings.
That made me wonder, though, what are other folks doing in this regard. Interestingly enough, the example in “Using CLR Integration in SQL Server 2005” white paper doesn't actually show them being used all that much, except for those things that actually call back to the engine. Not really sure what to make of that.
Past 27 hours of blog activity:
- Posting about “Best Super Bowl Commerical”: 1,072 hits.
- Posting about “Michael Earls and Little Red”: 305 hits.
- Posting on “Grizzy is why need YAWF”: 282 hits.
- Article on “SQL CLR and XML: Saw the woman in two carefully”: 45 hits.
Draw your own conclusions about what people are really interested in.
Sorry if confused anybody about that -- not what I meant to say!
It may be underappeciated, heck it may even be unappreciated, but don't let that confuse you: it's only depreciated in the MDAC after version 2.x. As Irwin points out, SQLXML as a technology stack is hanging around. That's really good news because there's a lot of cool stuff in this stack that folks just don't take advantage of. Expect to see a few posts here when Beta3 of SQL Server 2005 releases.
Note that is there is another 2.x release of MDAC, SQLXML support will still be there too.
Who: The
Sara Moulton
What: A benefit for the Omaha Food Bank
When: Thursday, February 17, 2005 over the noon hour
Where: The Classy Gourmet, 721 N. 98th Street (Clock Tower Village)
Why: Helps a Great Cause! Sara will be making Arugula Salad with Aged Gouda, Savory Praline, and Whole-Grain Mustard Dressing and Seared Sea Scallops with Celery Root Puree, Parsley Oil, and Lemon-Caper Brown Butter.
How: Register online here. $150.00 per person with $110.00 tax deductible. Space is limited to 15 students. Each student will receive a CLASSY GOURMET apron and a complimentary glass of wine with lunch.
Had the joy of cleaning off my desktop this morning frantically looking for a piece of documentation about a project I'm working on. Found that, but along the way I noticed the that there were a few books that never seemed to get put away since I'm usually digging through them at least once a day. My list follows, but I'm interested... what's on your?
- Designing Web Usability (Nielsen)
- Perl 5 Quick reference (O Foglhu)
- XSLT2 Programmer's Reference (Kay)
- SQL for Smarties (Celko)
Betsie Freeman pens an article about blogging in our local fishwrap: Dear (Web) diary.
Aaron Weiker post drew my attention to Sahil Malik posting about SQLCLR UDTs, and Shawn Wildermuth's response. My response grew into this article. My advice is to listen to Warren Zevon warning...
I can saw a woman in two, but you won't want to look in the box when I am through.