Bryant Likes

This talk covered what's new in System.Xml in Whidbey. There have been quite a few performance enhancements and usability improvements that will make working with XML faster and easier. Plus SqlXml has been integrated into the System.Xml stack. I'm not sure if people made the connection, but this means that SqlXml is now using fully managed code and not the COM Interop code that is provided with SqlXml 3.0.

Performance Improvements

• lots of them. I got in too late to write them all down.
• 4x XSLT performance (I did get this one)

Usability Improvements

• XmlFactory - looks very cool.

XmlDocument is Dead!

• XPathDocument - A better XML DOM replaces it. (In PDC bits it's XPathDocument2)
• 20%-40% faster!
• XPathEditor - uses an XmlWriter to edit the XML.
• Strongly typed!

XQuery

• The “DeathStar“ of XML. It will destroy everything in its path. “XPath++” :)
• Better syntax, strongly typed, can do joins, comprehensive functions...
• All XPath statements still work.
• Uses FLWOR (For/Let/Where/Order by/Return)
• The demo made this look easy. Very well done.

SqlXml

• SqlXml 3.0 migrated into ADO.NET.
• Query language is XQuery (via XQueryProcessor (Command))
• Uses XML Views (via XmlViewSchema)
• Now called “SqlXml in ADO.NET“.
• Stream XML from relational tables into middle tier.
• Scenarios: application evolves with XML schema (FinXML), source and sink for XML (B2B), streaming XML into relational tables (RSS feeds).
• Middle-Tier XML views - declarative syntax for mapping between XML and relational data. Supports command database design patterns (stored procs). This is the same mapping technology used in Object Spaces.

Disconnected Scenarios

• XmlAdapter - like SqlDataAdapter, fills an XPathDocument from SQL Server, updates the changes back to SQL Server using autogenerated update statements. Very nice!
• XmlBulkLoad - streaming update for XML into SQL Server using an XmlReader with an XML View. This should solve a lot of the XML BulkLoading issues associated with SqlXml 3.0. (large and small docs)

Xml Editor Enhancements

• Quite a few XML Editor enhancements....

 

 

This talk covered went deeper into Data Controls in Whidbey covering more advanced topics like caching, configured connection strings, master-details, and much more. Overall it looks like MS has done a lot of thoughtful work on how to make data controls better in Whidbey and how to enable developers to do what they are trying to do.

Data Source Caching

• Too hard in V1 so no one used it.
• Caching now exposed as properties (EnableCaching=“true“, CacheDuration=“5“) Nice!
• Cache keys are transparent.

Sql Cache Invalidation

• Tie the cache to tables or rows in the database.
• Done via Polling in Sql 2000, notifications in Yukon
• Supported by SqlDataSource and ObjectDataSource.
• Turned on in the web.config. (Also showed named connection strings)

DataGrid Filters

• Showed adding parametrized filter string
• Filter parameter can be tied to control, querystring, etc. It's good to see the parameter types spread across many areas of the ASP.NET product.

Configured Connection Strings

• Done in the web.config and can be encrypted.
• Support at design time (in Beta 1).
• MMC tool to manage connection strings.
• Added to ConfigurationSettings as a property and can be also referenced in HTML view.

Master-Details

• Navigate relationships with data controls.
• Can span multiple pages or done in a single page.
• DetailsView control (like Access form view). Use as details view of master-details page. This can also be used to insert new records. This is a very nice control.

Databinding in Templates

• New syntax <%# Eval(“field“) %> one-way or
• <%# Bind(“field“) %> two-way (not in PDC build)
• They are “real sorry“ about old confusing syntax in V1.
• Template editing now has a nice rich UI in design view. Drag-and-Drop supported.
• Two-way databinding allows you to do things like binding a dropdownlist in the edit view of a grid to the datasource. Totally customize the editing UI without coding!

Hierarchical Data Sources

• Data as parent-child relationships
• New data-bound controls like TreeView and Menu (in Beta 1). TreeView has tons of options.
• One feature in TreeView is client-side postbacks that can update the page. This feature is available to control developer as well through an interface.
• XML Databinding - XPath databinding syntax and XPathSelect syntax

Again this was a good session that covered a lot of ground in a very short amount of time. ASP.NET developers are really going to like these new features. There wasn't a whole lot of applause during the session but I think this was mostly due to people trying to take in what all these new features mean.

The goal of data controls in "Whidbey" is to make it easier to use data controls while at the same time add new features that make them better. Below are my notes on the session but I don't think I can do it justice. See the slide deck (link below) to get a better idea of how important these new features are.

Data Controls

• Too hard in v1 (commonly requires 100s of lines of code)
• Easy and powerful in Whidbey (do not require developer to understand the page lifecycle).
• Goal: Common UI scenarios with little coding.

Types of Data Controls

• Data Source Controls - represent backend data sources (ex: SqlDataSource control)
• SqlDataSource - connection to database with select, update, etc.
• Supports SqlClient, OleDb, ODBC, Oracle, etc.
• Commands and stored procs
• ObjectDataSource - BusinessObjects - select, update, etc point to methods on object
• Binds to custom business objects
• integrates with new Object Spaces
• XmlDataSource - Xml Files
• AccessDataSource - Access
• DataSetDataSource - DataSets
• SiteMapDataSource - connects to new ASP.NET sitemap
• Data-Bound Controls - rendering data (ex: DataGrid control)

Data Source Controls

Retain the flexibility of v1 but add new benefits. Also easy to build your own data sources controls (ex: SalesFiguresDataSource). Two interfaces for doing this (plus two abstract classes)

1. IDataSource
2. IHierarchicalDataSource

New Data-Bound Controls

• DetailsView
• GridView
• TreeView
• Menu (Beta timeframe)
• BulletedList

Sql Data Source Control

Responsible for sorting, paging, updating, inserting, deleting. In Beta 1 timeframe will persist the connection string to the web.config file and will be able to encrypt it. The data source controls was then demonstrated:

1. Drag-and-Drop SQL table to page. It just works now. Showed some of the code (html) that makes this all work. Looks good.
2. Turned on sorting/updating. Also just works. One cool feature was the new “move column“ feature where clicking a button moved a column without having to go into the property builder.
3. Paging - done with the UI but can also be done via ExecutePagedReader with was seen in the ADO.NET session.
4. Filtering - V1 made this hard, in Whidbey you don't need to code this.
5. Parameter Types - ex. QueryStringParameter, ControlParameter, etc. These are very cool. Can then take these parameter types and associate them with a command (like select). All done in the HTML source. Very easy to add a dropdownlist to a page with a gridview and filter it using the dropdownlist. No code used.
6. More events: OnSelecting, OnInserting, etc. These are for both data source and data-bound controls.

Object Data Source Control

1. Select method can return any Object or IEnumberable list, collection, or array.
2. Updates, inserts, deletes methods take individual fields.
3. Many more features coming in Beta 1 timeframe. Wizards, designers, design-time support.
4. A demonstration was done showing how to bind a datagrid and dropdownlist that both were bound to a business object. Selecting, sorting, paging, filtering, etc all done against middle tier object. Very cool!
5. Can also bind data-bound controls using generics.

VS Data Component

A middle tier data access layer for Web and client. Seems like a DataAdapter that does everything better. Created from DB schema, sql, or sprocs, and does paging, fillby, and much much more.

ASP.NET Code Directory

Haven't seen this before. Basically it is a directory that you can drop class files into (cross-language supported) and the files will be compiled and can be referenced in your project. The demo showed a VB ASP.NET project and a CS file was dropped into the code directory and then the class was used in the pages.

Object Spaces

This is an object-to-relational framework that looks very promising. Mapping data to objects is a very common task.

1. Map files, OSD, and RSD used to map the data to objects. (read: another xml format to learn) Thankfully they are generated by design time tools.
2. Can do parameterized OPath query. (note o = object vs x = xml).
3. ObjectDataSource can connect to object spaces as well.
4. Also did a demo of how to create an ObjectSpacesDataSource object.

Overall it was a very good session. I'll be hitting part 2 for sure.

Slides at http://www.asp.net/whidbey....

ADO.NET in Whidbey doesn't break anything from 1.0 or 1.1. It just adds new features and performance. All the items below were explained and demos done.

Faster

1) Asyncronous methods. Very cool. Now you can open two connections and perform two operations at the same time with the new methods (ex: BeginOpen, EndOpen).

2) Batch Updates. Add a bunch of rows to a dataset, but only make one roundtrip to the database. Very nice! All done via one property “BatchSize”.

3) DataSet Performance. Now offers binary serialization for fast serialize/deserialize and less memory usage. Faster index engine speeds up inserts.

Easier

4) No MDAC requirement! (PDC build still requires MDAC)

5) Paging via ExecutePageReader with starting row and number of rows. Very easy to do. I like it!

Yukon Enabled

6) User-Defined Types. Use CLR types that live in Yukon. This demo was probably the best demo I've seen yet. Very cool wireframe drawings using CLR types in Yukon. Also did a demo showing how you can call methods on CLR types in SQL Workbench.

7) Multiple Active Result-Sets (MARS). You can now open multiple active datareaders on one connection.

8) SQL Server XML Data Type. XML is “just a type“ which means seamless integration. SqlDataReader.GetSqlXmlReader (I like the looks of this one).

Common Base Classes

9) Common Provider Model. Now have abstract base classes instead of interfaces for the provider model. This is without breaking changes.

10) Db* Base Classes. DbConnection, DbCommand, etc. Problem: SQL syntax is still database-specific, but this will be done before it's released. What I found to be cool was the DbProviderFactory: DbProviderFactories.GetFactory(“System.Data.SqlClient“). You can use this factory to create a DbConnection or DbCommand which can execute SQL statements against SQL Server. Just change the factory to change your data provider.

Overall this was a very well done session. I really liked the before and after views of the code. If you missed this session I would ask if it could be repeated. This session was the first session that I got really excited about.

Trying to leave the WSV301 session proved to be almost impossible. Traffic was at a complete standstill in the hall. Maybe they should start adding some traffic reports?

12:31. If you don't have a seat for the Indigo session, you're probably not going to get one. This place is packed.

12:35. The are no longer seats on the floor either. Maybe they should have used the main hall? Looks like it's starting...

Another just published: Performance Optimizations for the Xml Data Type.

This paper covers several techniques to improve the performance of queries against and modifications to the XML data type in the latest version of Microsoft® SQL Server™, SQL Server "Yukon." To get the most value from this paper, you should have some familiarity with XML features in the context of SQL Server.

Just published on MSDN: Xml Best Practices for Microsoft SQL Server “Yukon”.

This paper provides guidelines for XML data modeling and usage in SQL Server "Yukon." The paper is divided into the following two topics:

• Data modeling

  There is more than one way of storing XML data in SQL Server "Yukon"—for example, using XML data type and XML view of tables. This topic provides guidelines for making the appropriate choice for modeling your XML data. This topic also covers indexing XML data, property promotion, and typing of XML instances.

• Usage

  This topic discusses closely-related features, and suggests appropriate use of these features. Some examples are provided to illustrate the ideas.

Today while reading through the PDC Bloggers feed I ran across a couple of fellow SqlXmlers: Eron Wright and Jason Collins. I'm glad to hear that I'm not the only one who is excited about SqlXml in Whidbey.

There were also a few SqlXmlers in the Data Access Roundtable BOF last night. So SqlXml is being used and its user base will probably grow as Whidbey integrates it into VS.

I would love to hear how other people are using SqlXml. If so leave some feedback about how you're using it.

 

The Data Access BOF was very interesting. I was actually surprise that over 30 people showed up even though it was so late. We had some very interesting discussions regarding SqlXml, DataSets, and DataReader-to-Business Objects types of Data Access. I'll try to post more about it later.

I missed the Keynotes due to the fires, one of which is right down the street from me.

I did catch the lunch session on Tips-and-Trick for .Net Managed Components which had some pretty good information. People were coming and going quite a bit but I think it was most interesting when someone started leaning on the light controls.

Next I went to the Data Access and XML in Whidbey session which was somewhat interesting but was way too crowded. The new XML editor in Whidbey looks nice and I do look forward to the intellisense. The drag-and-drop data controls look cool, but I'm not ready to buy into it until I play with it.

In the afternoon I went to Scott Guthrie's session on ASP.Net in Whidbey which was very good. Again it looks like MS has implemented some great drag-and-drop features which hopefully work well. I can't help but think of the script library that came with Visual InterDev 6.0.

For the last session I hit the Indigo session where Don Box philosophized about software services. I found the session to be interesting despite the lack of demos and sometimes crude metaphors. Below are my notes from the session:

Indigo Tenets:

1) Boundaries are explicit (opt-in)
2) Services are autonomous
3) Share Schema (and contract), not class
Schema = define structure
Contract = Schema over time (behavior)
4) Policy-based compatibility

Services:
Today - use ASMX (for most situations)
Tomorrow - Indigo

What you get:
1) Boundaries come into focus
2) Unified and Simple
3) Interoperation
4) Continuity

After the sessions I had dinner at In-n-Out with some fellow SQL Server MVPs and our MVP lead.

Now I'm back at the PDC sitting in a Birds-Of-A-Feather session waiting for my own BOF session to start. I met with Andrew Conrad in the expo hall today and he and some of the other Data Access guys will be there. Hopefully it will be interesting.

Paolo has updated his XML feed and I've updated it on the PDC Session Layout. I also added the session code and room information. Also if you hover over the session you will see the abstract.

Now I just need to figure out which sessions I want to attend, add them to MyCalendar, and print it all out.

Update: I had to remove the Hands-On Labs since they didn't have a start-time or end-time. I'm assuming they run all day.

Well I thought the MyCalendar application was a useful application, but I wanted to see all the sessions side-by-side per time slot. Since I didn't see anyway to do this on the site I decided to create my own as a way to learn about ASP.Net. You can see my first attempt here.

The page uses the XML from Paolo's Notes.

Today I attended the Office 2003 Launch Event in Los Angeles. I skipped the Keynote since I assumed that it would be mostly marketing information which really didn't interest me. I ended up only attending one of the developer sessions which turned out to be quite interesting.

The thing I like best about the presentation: Associating an XSD with a Word document and then saving off the document as either XML data only or an XSL document that can be combined with the XML to “remake“ the document.

The idea of using word to make an XSL seems pretty cool and I'm planning on playing around with this and seeing how well it interacts with SQL Server 2000's XML features. This, of course, means even more for the next version of SQL Server.

As someone who has done a lot of work in the past with SqlXml, .Net's Xml Serialization feature has always been an interest of mine. I was always wondering what kind of performance you could get using FOR XML queries and Xml De-serialization. Well after reading the section about this in Dino Esposito's book Applied Xml Programming I decided to play around with this some and see how it worked.

I started with Dino's Sql2Class example which grabs employees from the Northwind database and populates an employee object. This test class showed the Xml Serializer taking about 4 times as long as some ad hoc code that parsed the Xml. This was interesting, however, I wanted to compare the serializer performance verses standard data access techniques. So I made my own Sql2Class test project.

For my standard data access code I used Scott Watermasysk's data access code in .Text. For the SqlXml data access code I just used the System.Xml.Serialization.XmlSerializer class and FOR XML EXPLICIT queries in the database. Below is a screenshot of my test app which shows the scores for 100 iterations.

As you can see, the serializer is slower than the standard data access code. However, I think it is fast enough to be usable.

One interesting item was that parsing dates using the serializer seems to be very slow. I tried replacing the serializer's date parsing routines with my own by slightly changing the name of the HireDate and BirthDate attributes in the Xml and then adding an XmlAttributeEventHandler method. This did speed up performance by about 20-40ms. I'm not sure why this would be true since my own date parsing just uses the standard DateTime.Parse method.

So I'll keep playing around with this stuff. If anyone is interested I can post the source for my test project which runs off the Northwind database.

Personally I think this is all going to get much more interesting when Yukon goes to public beta.

Just got my PDC Attendee card in the mail today:

Also I read Nikhil Kothari's abstracts for PDC talks both of which look very interesting. Here are some excerpts from the abstracts:

WSV 401 - This talk features an HtmlEditor server control that demonstrates Composition, Client-scripting, Web resources, Script asynchronous callbacks, Control state, Theming, and Adaptation.

WSV 402 - This talk will feature the BlogEntryView and BlogDataSource server controls that demonstrate writing Data controls, automatic data-binding and data editing, design time schema, tasks and in-place editing.

Hopefully they will be including not only an HtmlEditor but also some kind of Internet Explorer control that is easy to use.

 

In addition to trying to understand .Net and OO Design, the rest of the products I use aren't standing still either. XML and SQL Server are finally tying the knot after courting each other for the last four years. Additionally, .Net and SQL Server are also getting hitched which means there are even more possible designs when building data-driven applications in .Net. And in a few years, SQL Server will be hitching up with Windows itself a la WinFS. So as a SQL Server MVP who specializes in XML, I have a lot to learn on top of how to be productive using .Net.

Vinod just posted his 10 Commandments of .Net  which I find to be very interesting and true. Below are some of the commandments along with my own personal comments.

1. Thou shall learn XML, now! But not just any old XML, .Net XML. What do I mean? I'm an old VB6 (is there such a thing) developer who did all his XML work with MSXML. When I made the move to .Net I found that XML in .Net is much different than XML in MSXML. I still don't think I fully understand how XML is handled in .Net, but not because I don't understand XML, because I don't (fully) understand .Net.

2. Thou shall become an object-oriented programmer! Another fun one for the VB6 developer. When I switched to .Net I forced myself to learn C# because I found VB.Net to be too frustrating. It was similar to VB6 but that seemed to be more of a hindrance than a help. What is the use of a familiar syntax when everything underneath is different? Needless to say I think the fact that I don't have a CS background (I'm a self-taught developer) is a hindrance when developing in .Net. To be productive in .Net you do need to use OO techniques, now I just need to find a good book to bring VB6 developers up to speed on OO in .Net using C#.

3. Thou shall concentrate on the .Net framework, not the language being used. Agreed. The only question for me is how much do I need to learn about the framework to be a successful developer? I read Sam Gentile's posts about CLR books to read which sounds great until I look at my current stack of books I'm trying to read just to understand how to develop in .Net and be productive. Unfortunately I'm a mere developer and sometimes .Net seems to be so big that I can't possible wrap my tiny brain around it.

4. Thou shall not go it alone. Perhaps this is the answer to my questions above. I should get involved in the .Net community. This is how I learned so much about SqlXml, by helping out in the newsgroups. [Note to self: subscribe to a .Net community of some sort]

5. Thou shall adapt to new development environment. I think I've been working on this ever since .Net came out. I can say that at this point I'm very comfortable using VS.Net, however I'm not sure that I'm a very good .Net developer.

6. Thou shall abandon DCOM and use remoting. Amen. At least on the the abandoning DCOM part. In my previous life as a speech application develop, I abandoned DCOM for my own version of SOAP before SOAP was a standard. DCOM was a headache.

7. Thou shall not use VS.NETs code generators without understanding the code they generate.My own version of this is thou shall not use VS.NET's code generators if they generate too much code to understand. Some of the code generator's (ex: events) generate an understandable amount of code, while other code generators (ex: dragging datasets and SQL connections onto a form) generate more code than I care to figure out.

8. Thou shall use structure error handling in VB. I haven't done much (OK any) .Net coding in VB due to my frustrations with VB.Net when I first started. However, I recently read an article (but I don't remember where) that talked about using VB for the UI layer because it made more sense. I think I'm just about ready to start using VB.Net from time to time when it fits, and when I do I don't have any plans to go back to VB6 type error handling.

9. Thou shall avoid using COM+ for single phase transactions. I'm currently not doing anything with transactions, but I'm keep this in mind when I get there.

10. Thou shall not underestimate the complexity of .NET.Nor shall I overestimate the size of my own brain. I'm beginning to think that I will never fully understand .Net even though I think I have a pretty good grasp of it. Hopefully I will begin to get it more as I begin to get a better understanding of OO design, and as I understand .Net XML, and the CLR, and the 10 books sitting on my shelf. OK so maybe I'll never fully understand it, but hopefully at some point it will help me be a more productive developer who write solid, maintainable applications.

Thanks again Vinod for your great list, I enjoyed thinking (and blogging) through it.

 

This is something that many people have been waiting for. It was posted yesterday in the newsgroups but I missed it since the MS news servers were having problems.

I'm happy to announce that the RTM version of SqlXml 3.0 SP2 has been
released!

You can download the bits from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4c8033a9-cf10-4e22-8004-477098a407ac&DisplayLang=en

SP2 includes many fixes since the SP1 release including:
  a.. Identiy Propagation for XML Bulkload
  b.. Null Support for Web Services when used with Visual Studio .NET 2003
Please see the included documentation for details.
Overview
SQLXML enables XML support for your SQL Server Database. It allows
developers to bridge the gap between XML and relational data. You can create
XML View of your existing relational data and work with it as if it was an
XML file. SQLXML allows you to:

  a.. Build Web Services with SQL Server 2000
  b.. Build Web sites to publish data from SQL Server
  c.. Query relational database with XPath
  d.. Update relational data as if it was XML
  e.. Load XML into SQL Server
  f.. Query SQL Server via URLs, OLEDB/ADO or .NET Managed Classes


Thanks!
Irwin Dolobowsky
Program Manager, SqlXml

Now we just need to get some managed classes that don't use the COM Interop.

Well I've been too busy working on projects to blog much. When I'm not in school or working on projects I've been reading Essential ASP.Net. Today I bought C# Design Patterns: A Tutorial which I'm hoping will help me progress through Design Patterns. The book isn't a very good C# book, but I only bought it for the design pattern examples which do seem to be useful. I picked up some of these books because they were recommended by Sam Gentile in his recommended reading list.

Well back to reading....