Milind Lele - Demo of using new SQL Server from Visual Studio

Sweet! Milind, the first Microsoft guy I ever met. Great guy, and a great interview too.

i'm glad someone finally explained when you would want to use managed code versus straight TSQL. good video.

one question, does anything need to be done on the SQL Server to enable debugging?

Thanks Chris. The connection node in server explorer has a context menu command "Enable SQLCLR debugging". You can check that to enable this. Also when you create a SQLCLR project you are prompted for a connection to use as the target for your assembly. If this is not enabled for this connection, you will be prompted to.

I noticed that Lele is using SqlTypes (SqlDouble). Why can't we just use the .net framework variabletypes?

nice video


could someone tell me where i can get the background Lele has on his machine?

Had read a couple of articles about the integration of CLR with Yukon but the concept was never so clear as was after watching this video.
Anyone noticed the ";" that Milind had put after a VB line of code!!! I (and may be others too) tend to do the same mistake after writing code in C# (or JAVA) for months

-Aayush

Very informative. Milind, could you detail the code paths of executing a native SPROC vs. a CLR SPROC? I'm mostly interested in performance issue. Whether or how much of a performance penalty a CLR SPROC may cause.

Did anyone else notice that VS .NET 2005 was running rather slow on his system?  I've seen this on my computer as well, and would really like to see a speed improvement.

Dan

I have never had an issue, what I did notice is he was running beta two LOL One can hope that is not to far off. I find that VS 2005 runs pretty quick.

the one thing i notice on my machine is that in C# mode vs runs really smooth .. but C++ is almost painful. IntelliSense doesn't really work as expected most of the time and the editor performance in general (C++ only, that is)  is rather poor, unfortunately. I know these have been long reported to the feedback center.. just wanted to reiterate.

Could it be that Milind is usually programming in C#?

Hehe, so funny that he was typing in Double first insted of Dim etc...
and then the ; at the end of the line

I'd love to see more videos about Whidbey and Yukon!

It was very professional of Milind to continue the demonstration during the earthquake that occured during filming. Most impressed.

FYI: Here's a great article that might help answer some of the questions:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sqlclrguidance.asp

Sorry I'm late to the party, just found the time to start watching some of the videos this month.  One down, nine more to go.

One thing I'm very confused about regarding sql/clr integration.  How does writing business logic on the data tier fit into a three tier archetecture?  In other words, why in the world would you do this?

Thanks,
BJ

No response.  It's good to know that Microsoft doesn't understand the proper application of it's products either.  You guys are scaring me.

It is not a recommendation to move all mid-tier logic to the data tier. Some of it can be. One must weigh and trade off data-traffic with server utilization.

IOW you would never move all your business logic into the data tier.

Hope that helps.

Milind

No, it doesn't help, it only keeps things muddy.  The "Some can be but all shouldn't be" philosophy seems like it has room for some pretty broad interpretation. Your guideline to "weigh and trade off data-traffic with server utilization" isn't all that clear either.  Even if I thought that was the correct design criteria for where to put the business logic, you don't give any standards to measure by.

Don't get me wrong, I use and love Microsoft technology, especially .NET.  The reason I love .NET though is that it has made it easier to build well architected applications, while making it harder to write poorly architected applications.  Clr\Db integration seems like it is moving in the other direction, making it easy to put business logic in the database.  There are still a large group of Microsoft developers (sorry VB'ers) who don't fully understand proper architecture and this is a misleading gesture to them. 

Microsoft should either drop this "feature" to go work on indigo or they should do a much better job of explaining it's proper use.  Otherwise I guarantee there will be database implementations bloated with business logic.  I know people now who think it is a good idea to put business logic in stored procedures as a general practice.  The fact that clr\db integration even exists is asking for people who don't know better to write business logic in their database.

*bump*

Maybe it's because I'm able to decide which socks to wear in the morning, or it could be that I'm used to IBM's approach to customer service (pay us for tech support, pay a consultant for best practices) but I don't understand how it's Microsoft's responsibility to instruct the masses on correct feature use (like in this article: http://msdn.microsoft.com/SQL/2005/servprog/default.aspx?pull=/library/en-us/dnsql90/html/sqlclrguidance.asp).  Read, demo, and determine if and how to implement.

SQL Server's trying to sit at the big kids table in regard to Enterprise DB Solutions.  They needed to add things like CLR support b/c their competition has implemented it.  That said Microsoft has done a much better job implementing the CLR, giving developers much more leeway to develop custom apps.  Development standards, performance analysis and good old trial and error are enough - if developers hose their application because of a bad architecture decision, then they need to rethink and reimplement their design.  Frankly, it's up to "senior" staff to shield developers from nightmarish mistakes; I like to think the ability to intuitively make sound architectural decisions, and not just "following the yellow brick road" the vendor lays out before me keeps me employed.

My only gripe is the lack of release notes when a new update comes out - though while Yukon's in beta it's understandable.  I hate having to search the world over until I come across the odd Microsoft Developer's blog pointing out an undocumented change.

To add to what ZIsraeli said in response to BJMarte, if MS or indeed anyone enforced a pattern on where to put what code, developers all over would be furious and up in arms immediately saying "dont tell me where to put my code. I know what layer is best for my component" and so on.

Architecture is all about trade-offs and things that work fine for some scenarios would be foolish to attempt for others. 

Secondly dont confuse layers and tiers. Layers are logical and tiers are physical .You can have a three layered or more design sitting on one single box.

Cheers