VSLive San Francisco Presentations


At VSLive I presented two sessions.  One for Occasionally Connected Smart Clients and another on Advancements in Data Access.


 


The Occasionally Connected Smart Client session focused on what we’re working on post VS 2005.  Some of which should be in Orcas, some of which will follow afterwards.  Mostly the session was about providing an overview of the evolving application model to leverage SOA based architecture, but not cripple end users at the same time.  In the session I talked about some of the early thinking on some of the Occasionally Connected Systems compnents.


 


The Advancements in Data Access session focused on a few questions that come up a lot around the VS Data features.  In particular I covered:



  • How to separate your Typed DataSets from your TableAdapters
  • Increasing the performance of Typed DataSet Serialization by skipping schema with DataSet.SchemaSerializationMode = ExcludeSchema
  • Implementing a common interface for TableAdapters, ITableAdapter
  • Doing a hierarchical update within a transactions

Slides & Demos


Recording of the VSLive Session


Enjoy


Steve

VSLiveDemosAndSlides.zip

Comments (7)

  1. Frank Botnevik says:

    Watched the VSLive webcast on Occasionally Connected… This really rocks! Is there more info floating around that you are aware of?

    How do I stay current on the developments in this area?

    Best regards,

    Frank

  2. SmartClientData says:

    Hi Frank,

    Glad you enjoyed it.  There’s a lot of cool stuff, focused on end user scenarios that we’re working on.  So, for Occasionally Connected stuff, this is the place, or you can check out my new blog at: http://blogs.msdn.com/SteveLasker/

    Nothing there yet, but I’ll get some stuff up soon.

    Thanks

    Steve

  3. Nusrat says:

    Do you have an updated source code for the occasionally connected smart client demo that you gave at the PDC 05?

    So basically to help me understand you are using sql mobile edition as the local database on a desktop and the application does everything against this database.

    This local database in turn has a responsibility to keep itself synced up with the server database.

    Is this a correct assumption?

    my email is wanderernxa@comcast.net

    Thanks

    Nuz

  4. Steve Lasker, the one from the Microsoft Visual Basic team, has posted the presentations from VSLive…

  5. Allen says:

    I just got done looking at your power point on the occasionally connected smart clients presentation.  There are some things that I’m excited about and I just want to make sure that what I’m seeing will be truly happening.

    SQL Mobile:
    I noticed that it has been or will be positioned to work on a laptop and desktop.
    (1) When will the Tablet Pc restriction be removed?
    (2) Is there any documentation on any Microsoft sites that discuss this?

    SyncAdapters:
    (1) When will this be available?
    (2) Will it work with any back end?

    The slide on Synching: Relational or Objects.  What is the blue circle with the two small blue circles representing?

    This stuff looks great!!  Please just don’t tell me that these won’t be available until the ORCA version of .Net.  I’ve wanted to use SQL Mobile because it looks like the perfect solution for our application but our users have laptops and desktops and I don’t see the company buying tablets any time soon.  

    I saw your presentation on this subject at PDC last year and I’m happy to see the changes that you are making from just six months ago.

    Thanks,
    Allen

  6. Steve.Lasker says:

    SQL Mobile:
    We’re still in the process of working out the license restrictions.  We don’t have a specific timeframe just yet, but I am hopeful we won’t have to wait ‘till Orcas.  We don’t have any documentation beyond the Tablet PC scenarios as this is something we’re still working on.  The main concern is related to the unique APIs in SQL Mobile.  Will the unique APIs in the ADO.net stack for SQL Mobile block users from moving up to SQL Server.  Basically, we really want to avoid repeating the issues related to Access/Jet and FoxPro applications.  Upgrading these applications has been very difficult and confusing for developers.  

    We do believe that SQL Mobile will not have the same challenges as SQL Mobile has a strict subset of the datatypes and TSQL language.  This wasn’t the case for Jet and FoxPro.  However, the ADO.net stack for SQL Mobile does have some unique APIs that don’t work against SQL Server.  For instance the SqlCeResultSet is a data bindable cursor that works great for local databases, but would be extremely problematic with a multi-user database such as SQL Server.  If SQL Mobile was a 100% strict subset, we’d have changed the licensing already.  We do believe there are features developers do want from a local, in-proc embedded database; such as the SqlCeResultSet so we’re not quite ready to just remove these APIs and call it a day.  It would be great to get feedback from developers who’ve used SqlMobile what they think about constraining SQL Mobile desktop scenarios to a strict subset model.

    I have been trying to get an article written on the Evolving Application Model that outlines how starting with a local database isn’t a bad thing.  Actually starting and keeping a local database is a good thing.  It increases performance for the user, improves scalability as the central servers have fewer operations to perform, and improves usability for the user as it’s the basis for enabling offline scenarios.  The model we’re discussing is the application keeps their local database and adds some new synchronization APIs to keep the local database in sync with the server.  This is the concept I presented at VSLive and the direction we’re heading.  In the meantime, buy more TabletPCs and things will be much simpler 🙂

    Sync Adapters:
    These are just beginning to take shape.  We’re teamed with the SQL Replication team to deliver these in Visual Studio Orcas.  The SQL Replication team is the same team that delivers Merge Replication so there’s a lot of experience here that we’re tapping into.  Once Orcas development begins we’ll have CTP’s out that you’ll be able to play with.  For now, we’ve been using RDA under the covers to demonstrate the scenarios we’re shooting for.  RDA is a great technology as its very developer focused and the server is unaware it’s being synchronized with.  Unfortunately, RDA is missing two key components:
    –Incremental Changes – Once the initial subscription has been created, there’s no way to bring changes on the server down to the client without reinitializing them.  This includes inserts, updates and deletes.  
    –Business Logic – RDA is very internet friendly as it uses HTTP as its transport from client to the server, however there are no hooks to validate data as it travels back to the server, or extensibility points to get data from the server using sprocs or other code paths such as web services.
    We do plan to enable any back end database.  We know that all of you would use SQL Server if you had a choice, , but we also know that you don’t always have a choice.  You’ll have an easier experience with SQL Server as we have more knowledge about the product, but you will be able to configure the Sync APIs to work against any back end database.  It will essentially be an extension of the DataAdapter model, so just as the DataAdapter has a lot of flexibility in the Select, Insert, Update and DeleteCommands, so will the two additional commands, SelectChanges, SelectDeleted.

    The blue circle is the mapping layer.  Essentially we’ll still be storing relational information as it’s the most efficient way to store data.  The mapping layer that enables users to map relational objects from the database can be used to map objects back to relational.  I don’t think we’ll get this done in Orcas.  For Orcas we plan to focus on the relational layer.  Once this is done, and we get more of our mapping technologies done we’ll be able to leverage it for Object Synching.

    Steve