More Thoughts on .NET in Yukon
I previously blogged about my fears that making the .NET languages available in Yukon might lead to horrible stored procedures by people who don't understand the difference between set-based and iterative processing. I am still worried about that, but I just read a blog entry by Greg Linwood that talks more about using the .NET languages in lieu of extended stored procedures and COM. Okay, I can accept that and see value in it. We get a lot of questions on SQLTeam about sending email from SQL Server without using SQLMail (usually because they don't have an Exchange Server. There are a few articles on SQLTeam about how to do that in SQL 7 or 2000. But I could imagine it might be easier / better to do this with a .NET assembly instead of, for example, the sp_OA calls. On the other hand, I read somewhere that SQLMail was changed in Yukon to allow sending SMTP mail without an Exchange Server, so maybe this whole example I cooked up is already obsolete.
Ah well... time will tell. Can't say I personally have had any real need to do COM or XPs yet anyway, so it might all just be a moot point for me.
Legacy Comments
|
Lavos
2003-11-11 |
re: More Thoughts on .NET in Yukon I know some people who were really looking forward to using C# or the language du jour in place of transact sql, and to be honest, I'd be eternally grateful if that didn't happen. It's already too easy to introduce cursors are really really bad constructs that are then blamed on the product instead of the developer, and I think a non-set based language would make that too easy. From what I can tell however, I think they got the level of dotnet support just right in that you can create objects and call methods (and properties?) on them, even from inside a select statement using columns as arguements. I like the new inplace table/view definition construct in theory, Pivot doesn't do much for me but I'm guessing it'd be one of those things I'd end up having to use a lot of dynamic sql for (even as the improvements in TOP reduces the amount of dynamic sql), and I think APPLY might help me cut out one or two cases where I'd normally take a cursor approach. But the real wins for me was a) making developing extended procedures easier and b) allowing user-defined aggregate functions. (God, I never did get around to finishing my extended procedure shell project, and now I won't have to. yay. yay.) |