Jackie Goldstein's Weblog

The recording of my appearance on .NET Rocks! is now available for download.

I really had a fun time, talking about the early days of VB, the future of VB, and some other stuff in between. All this, during what was for me 1:30 to 3:00 AM !  We all had a good time, but didn't get to cover even half of the topics that we wanted to, so I have been invited back to do another show in the near future. Stay tuned!

In the mean time, listen to the show and let me know if you have any thoughts, comments, or questions.

With the release of .NET 2.0 Beta 2, more and more organizations are taking the time to try to port existing .NET 1.X code to 2.0.  From my discussions with numerous developers at Microsoft, I know that backwards compatability was generally a very high priority for them on this release.  Of course, we need to remember that at this point, we are still talking about a BETA version, so it is not at all unreasonable for there to be incompatibilities.  MS is working hard to both document and eliminate these issues - I expect that by RTM, the vast majority of the exusiting incompatabilities will have been corrected and/or clearly documented and explained.

In the meantime, check out these newly published articles on MSDN.  They include a 1.1 to 2.0 Compatability White Paper, Testing Scenarios, and a current List of Breaking Changes:

http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/netfxcompat.asp

http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/NETFXcompatapptest.asp

http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/listofbreakingchanges.asp

The June meeting of the Israel Visual Basic User Group  meeting will be held on June 1, 2005:

 
17:30 - 18:00   Assembly
18:00 - 18:10   Introduction
18:10 - 19:15    “ASP.NET Tips and Tricks - Part 1”
                        Leon Langleyben , SRL Group
19:15 - 19:30    Break
19:30 – 19:45   "Hatzilu !"
                         Open session, with questions and answers/ideas from everyone
19:45 - 20:45   "ASP.NET Tips and Tricks - Part 2"
                        Leon Langleyben , SRL Group

This year I'll be doing 2 sessions at TechEd US.  I'll also be spending some time at the cabanas, product booths, and Ask The Experts.  And of course, GrokTalk.  If you are in Orlando, please stop by and say Hi !

Here are the details of the  2 sessions:

DAT382  Database Application Quick Start with SQL Server Express and Microsoft Visual Basic .NET 2005

Last month I did a presentation on ADO.NET 2.0 for the Israel Visual Basic User Group. Being a dilligent presentor, I made sure to run through my demos a few days before.  Many of these demos I had use for previous presentations on ADO.NET 2.0.   Of course, since I was now running on a different version of the Framework and of VS, there  were a few changes - no big deal. 

However, there was one shocker.  One of the coolest (if not simplest) enhancements in 2.0 is that you can specify a batch size for the DataAdapters updates.  In 1.x, when you call DataAdapter.Update (), it will execute the appropriate commands to update the database, for each modified row in a DataTable.  The problem is that each update command is executed separately - meaning a separate round-trip to the server for each modified row.

So the ADO team added the BatchSize property to the DataAdapter class to specify how many records should be sent in a single batch to the server (no, bigger is not neccesarily better - there is a point of diminishing returns, where the batch size is so large that the setup and tear-down time for the batch seriously reduces the benefits of sending in a batch).

So far, so good.   But how to you prove this to a (presumably cynical) crowd of developers ? What I had down was run the application with BatchSize =1 and look in the SQL Server Profiler to see the individual commands being sent to the server, and then run it again with BatchSize = 5 and see only 1 command being sent to the server.

When I did this in previous presentations, the above worked as advertised and everyone was impressed.  However, in my trial run at home last month, I suddenly saw 5 commands being sent to the server, even with BatchSize = 5 !!!!  Imagine my surprise and horror....

To make a long story short, I figured either (1) I had some gross misunderstanding of something that was going on, or (2) this feature was just broken in that CTP version of VS/.NET.  But then I remembered a conversation I had a few months earlier with Pablo Castro of the ADO team and realized that the correct answer was (3) it was by design !  I called Pablo (in a panic...) and he confirmed my suspicion and help prove to me that there really was fewer network round-trips, even though multiple commands were arriving at the SQL Server (which is all SQL Profiler can measure).

What had happened was that the whole batch update mechanism was rewritten, mainly to address 2 problems that existed with the earlier Beta implementation:  (1) When sending a single all of the updates in a batch as a single command, you would easily hit the limit of about 2K parameters per command, and (2) creating batches of different commands every time would wreak havoc on the query plan cache.

Pablo recently posted a great blog entry that clearly explains all of this.  Check it out. 

And always practice your demos.

Is that a good thing ?
Will it make you more attractive ?
Will it make members of the opposite sex run in horror ?

What the heck are GrokTalks ? They are so powerful and secret, they don't even appear on the TechEd agenda - but you'll definitely know that they are there...