Steve Lasker's Web Log - www.SteveLasker.com/Blog : offline

Demos, Presentations, Links, Screencasts and Videos for SQL Server Compact

Steve.Lasker — Wed, 26 Nov 2008 00:57:00 GMT

I often find it hard to find my own demos scattered throughout my blog, so figured I'd just create a single posting that had all my current demos and powerpoints.

Recent Presentations at PDC and Tech Ed

SQL Server Compact Overview (lots of demos with supporting slides)
This was a very demo heavy deck with supporting slides. Covers many of our SQL Server Compact goals and non-goals, including the tooling scenarios, split between VS and Management Studio. Slides and demo on ASP.NET soft block, programming models with DataSet and SqlCeResultSet. (This deck was before we had LINQ to Entity support available). Covers a quick overview of optimized online, offline enabled architectures, with demos of Sync Services for ADO.NET, including 2 tier and N Tier. Then wraps up with Logical Queuing as the overall architecture for client based apps. I had a lot of fun with this presentation, but it was hard to fit in an hour.

Unlocking the Power of SQL Server Compact (Tech Ed EMEA 08)
Covered several topics, such as the questions on how fast can SQL Server Compact insert data. For Tech Ed EMEA, I added the section discussing stored procedures, and how a common DAL layer can actually provide more functionality than sprocs for both local data and server data. (yes, I'm sure there will be lots more to debate on this topic, but here's our thought process J)

With some coverage on private deployment, including 64bit, deep dive on perf and the managed sprocs demos, I bubbled back up to cover several interesting aspects for using SQL Server Compact, including a TraceListener to capture information from the field and sync it back with Sync Services for ADO.NET. Then covered read only databases on DVD's and using Compact as a custom Document format.

Associated Demos:

SQL Server Compact Bulk Insert Performance Test Harness (Compares Compact & Express)
Demonstrates the power of an embedded database and how much faster it can run than SQL Server for many operations. By implementing a few things, such as "connection pooling" and caching your SqlCeCommand objects, you can achieve similar functionality provided by SQL Server's connection pooling and Query Plan caching. However, because Compact is "in-proc" with your application, you can get the benefits of not having to work through additional networking, process and security layers required by SQL Server which is designed to work over the network.
Managed Stored Procedures (A Common DLL for data access to Compact and SQL Server)
SQL Server Compact Trace Listener
Demo for using Compact as a TraceListener to capture the output of System.Diagnostics.Trace.WriteLine and then synchronize that info back to the server providing visibility into what's happening out on the client. This deck includes animation, which looks a bit like Missile Command, demonstrating how this sample works.
Running Compact from Read Only Media (DVD, CD, Locked USB Key)
Using Compact as a Custom Doc Format (Recipe Manager)

Managing and Versioning Client Databases (Tech Ed EMEA 08)

Discusses the pros and cons of managing database deployment on the client. Why deploying databases as files, through MSI's, ClickOnce or other technologies can be easy for V1, but could lead to data loss in V2. Why a little investment up front can yield you productive results long term, and make for a better user experience.

Associated Demos:

Creating & Managing Local Database Versions through Scripts
When deploying applications with a local database, deploying the database with the app can seem easy at first, but once the user starts making changes to the local database, it gets messy quickly. If you're not careful, you can even lose the local data created/updated by the user. In this presentation, I created several animated slides that explain the complications and why script based deployment and versioning is the only practical way to manage local databases. This sample walks through the creation and versioning of local tables. To focus on the script based versioning aspects, I excluded any interaction with synchronized tables as that just gets even more complicated.
Versioning Local Databases with Scripts when using Sync Services for ADO.NET
In this demo we see how to version schemas when using Sync Services for ADO.NET. This includes two projects. One for the initial installation of V1, and another for the upgrade, or initial creation of V2. V1 includes creating a set of tables that aren't synchronized, such as state management for submitting orders to an existing service. Once sync completes, there are a set of additional scripts to create foreign keys between the synched tables, and between the synched tables and the local tables.
V2 enhances the synchronized tables with additional columns. The setup of this demo is a bit more complex as I've configured the server side sync components in a dll, then hosted the dll in a WCF Web Project. The WCF Web Project is published to an IIS instance, but uses different sub directories: for V1-http://localhost/VersionSchema/V1/LookupSyncService.svc, for V2-http://localhost/VersionSchema/V2/LookupSyncService.svc. Using this versioning scheme we can publish V2, allowing apps to slowly migrate over to V2, while the V1 apps continue to function and the business continues to function. The animation in this presentation helps explain this somewhat complex subject.

Just the demos, and nothing but the demos...

SQL Server Compact Trace Listener
Demo for using Compact as a TraceListener to capture the output of System.Diagnostics.Trace.WriteLine and then synchronize that info back to the server providing visibility into what's happening out on the client. This deck includes animation, which looks a bit like Missile Command, demonstrating how this sample works.
Using SQL Server Compact under ASP.NET
Demonstrates how to "unblock" SQL Server Compact for usage under ASP.NET. I discussed our reasoning in this post. A quick recap: The reason we blocked Compact for ASP.net scenarios was simply to not set expectations Compact is meant to be a replacement for SQL Server. It performs better than Jet. For the most part, we unblocked it for pre-building a SQL Server Compact database for sync scenarios where it's faster to download the database as a stream, then to sync the initial snapshot of data. It's also perfectly fine for small websites or other services. The main intention is strictly to make sure developers know, this is not meant to compete with SQL Server. There are coding differences between Compact and SQL Server, so we really didn't want developers to start with Compact, only to later find out it doesn't scale to thousands of concurrent website/service users for updating data. As long as developers understand the scope, it's perfectly fine to use for ASP.NET, WCF, or other service scenarios...
SqlCeResultSet Demos - Scrollable, Updateable, ISAM like cursors
Demonstrates how developers can take advantage of embedded a database directly into your app. The best thing about the SqlCeResultSet is it works directly over the data in your local database. No queries that bring the results into another copy in memory that you must mange potential conflicts with the local store, or potential conflicts between the local store and the remote server. With the SqlCeResultSet you can scroll directly over the local table, even setting the index to filter and order the rows you're viewing. The SqlCeResultSet is a scrollable, updateable cursor and can really improve the perf and overall working set of your application.

Direct Access (ISAM) with the SqlCeResultSet
Why do we need to make copies of the data, update it, then send it back? In a shared database environment, where you're likely connecting to the database across the network, and sharing with potentially thousands of others, because it's the only way we can scale. However, when the database is local, in-proc with the app, things can be much simpler. In this demo, you can easily update data, and as soon as you move off the row, it's committed to the database. To get the most of this demo, run the same app twice (CTRL+F5). Make changes in one of the instances, move off the row. In the other instance, move to the row that was just updated, (note: if you're already on the row, you'll need to move off then back). You'll see the change made by the other app and can make the change back. The one piece missing from this scenario is an implementation of eventing so that instance 2 would see the changes made by instance one. This is why you must move off, then back to the row to see the change. As you move across the rows, the DataGridView requests the data. The data is fetched directly from the local database/table.
Another ISAM/SqlCeResultSet demo
In this demo we see how the index can be set to control the order of the data. Using a system view, we can populate the ListBox with the list of potential indexes. As you change the index, the view is updated to reflect the data sorted by that index. What isn't covered in this demo is the ability to "filter" the values using the SqlCeCommand.SetRange() api which uses the index to directly filter the visible rows.

SQL Server Compact Bulk Insert Performance Test Harness (Compares Compact & Express)
Demonstrates the power of an embedded database and how much faster it can run than SQL Server for many operations. By implementing a few things, such as "connection pooling" and caching your SqlCeCommand objects, you can achieve similar functionality provided by SQL Server's connection pooling and Query Plan caching. However, because Compact is "in-proc" with your application, you can get the benefits of not having to work through additional networking, process and security layers required by SQL Server which is designed to work over the network.
Privately deploying both the 32 and 64bit versions of SQL Server Compact with your app
Do your users know whether they have 32bit or 64bit machines? If they are 64bit, are they running a 64bit version of the OS? Should they have to figure this out? Using private deployment, developers can include both the 32 and 64bit versions of Compact so the user never has to make a choice. Yes, it's a bit more k to include in your app, but if it "just works", is that a small price to pay?
Running Compact from Read Only Media (DVD, CD, Locked USB Key)
Ever get a CD or DVD in the mail. Pop it in the drive to see what's on it, and it prompts you to install some software - yikes! Let's see if you can use this as a Frisbee and get it in the trash across the room, J With this demo, you can deploy a large amount of content, but stored in a Compact database so your users can run the app, search the data, and with private deployment, you can include the Compact engine so your users can "view the data" without having to install anything.
The demo is simply an extension of private deployment, but modifies the connection string to tell Compact to open the database in ReadOnly mode, and specifies a temp directory:
connStr = String.Format("Data Source = {0}\Northwind.sdf;Mode = Read Only;Temp Path={1} ", Windows.Forms.Application.StartupPath, My.Computer.FileSystem.SpecialDirectories.Temp)
Using Compact as a Custom Doc Format (Recipe Manager)
Need to save data from your app in a "document"? Want to post that "document" to a SharePoint site or email it to another team member? Want to double click your document and launch the associated app? Since SQL Server Compact uses a single file, code free, file format, and since it doesn't care what extension you use, developers can use custom extensions for the database file to launch their app. In this demo I use Click Once enhancements in .NET FX 3.5 SP1 to associate the custom extension with my ClickOnce installed application.
Managed Stored Procedures (A Common DLL for data access to Compact and SQL Server)
The great debate will forever continue on the debate of sprocs and its religion or science. I wrote about this here, but rather than debate the topic, here's a sample that shows how you can write a common data access layer to target against SQL Server (Express included) and Compact (SQLce) As outlined in this presentation, you can get far better scalability from your database by moving the logic out of the database as you can create several front end services to a single database, but you can only scale up a database so far before you need to scale out, which today is a difficult task.
Logical Queuing
In a service oriented world, is it really practical to assume all "services" can be synchronized? Or, is it a mixture of synchronizing some data, and submitting to existing, non synchable services that really touches on reality? In this demo, associated by this blog post, I demonstrate why using a database as your "queue" to services provides much more practical and realistic methods for working with existing services than expecting all the existing services to rev to support "sync". Sync is a very important technology, but no one technology serves all. In this blog post I noted down some thoughts, but not as polished as I was hoping to post.
Using Compact within Excel
Ginny Caughey and I co-presented at Tech Ed US in 08. Ginny assembled some great demos on using SQL Server Compact within VSTO, particularly within Excel.
Database Viewer
Every wanted to just look inside a SQL Server Compact Database, but didn't want to install Visual Studio or SQL Server Management Studio Express? With this little utility you can see the list of tables, and the data within each table. Not a full featured app, but rather a utility I use to show encryption or the ability to open a database across multiple users. It does show how to query the system views to get the list of tables.
Creating & Managing Local Database Versions through Scripts
When deploying applications with a local database, deploying the database with the app can seem easy at first, but once the user starts making changes to the local database, it gets messy quickly. If you're not careful, you can even lose the local data created/updated by the user. In this presentation, I created several animated slides that explain the complications and why script based deployment and versioning is the only practical way to manage local databases. This sample walks through the creation and versioning of local tables. To focus on the script based versioning aspects, I excluded any interaction with synchronized tables as that just gets even more complicated.
Versioning Local Databases with Scripts when using Sync Services for ADO.NET
In this demo we see how to version schemas when using Sync Services for ADO.NET. This includes two projects. One for the initial installation of V1, and another for the upgrade, or initial creation of V2. V1 includes creating a set of tables that aren't synchronized, such as state management for submitting orders to an existing service. Once sync completes, there are a set of additional scripts to create foreign keys between the synched tables, and between the synched tables and the local tables.
V2 enhances the synchronized tables with additional columns. The setup of this demo is a bit more complex as I've configured the server side sync components in a dll, then hosted the dll in a WCF Web Project. The WCF Web Project is published to an IIS instance, but uses different sub directories: for V1-http://localhost/VersionSchema/V1/LookupSyncService.svc, for V2-http://localhost/VersionSchema/V2/LookupSyncService.svc. Using this versioning scheme we can publish V2, allowing apps to slowly migrate over to V2, while the V1 apps continue to function and the business continues to function. The animation in this presentation helps explain this somewhat complex subject.

· Deploying Express with Scripts
Similar to the Compact deployment model, but with the additional steps required to create the physical mdf/ldf combination.

Private Deployment using the ADO.NET Entity Provider
One of the most popular features of SQL Server Compact is its ability to privately deploy the Compact runtime as a set of dlls directly within your application. But when using the ADO.NET Entity framework, things get a little more difficult as the Entity Framework uses the Provider Factory model for loading the individual data providers. I discussed this in more detail in this post, but here's a sample showing how to include the dlls and changes in app.config to work properly.
Common Programming between Desktop & Device
While SQL Server Compact provides the same apis between desktop and device (.NET Framework and the .NET Compact Framework), it can get a little more complex as the surrounding apis, such as the lack of the |DataDirectory| macro, and the lack of settings make it more difficult. This project shows a strategy for filling in the missing pieces of the .NET Compact framework so you can compile the same sourcecode for desktop, then device.

Some great partner tools

Data Port Console by Primeworks
Great tool for scripting tables from SQL Server Compact. For only $50, it's hard to beat
Remote SQLce
Great tool for managing a Compact database on the device, from the desktop
CodePlex
Codeplex is starting to collect several great code projects related to SQL Server Compact. I'm sure this will continue to grow, so it's a great place to look for what pain someone else has already endured

Great books

HitchhikerGuides.net - Bill Vaughn
Bill has a great, no BS style that just helps you get to the facts. It's a quick read, and at only $10, it's hard to pass up when you want to get up to speed quickly on Compact.
Microsoft SQL Server 2005 Compact - Prashant Dhingra
Prashant originally worked in the Compact team, and provides a great insiders look at SQL Server Compact
SQL Server Compact (In Spanish)- Jose M. Torres
If you're looking for a book on Compact in Spanish, here you go. I wish I could say I've read it, but, it's been years since I was at all fluent in Spanish. From what I have flipped through, it looks like it's covered all the topics. Jose has been active in the community, so I'd say it's a great bet.
Windows Mobile Data Synchronization - Rob Tiffany
Need some help, or want to know about Merge Replication? Might as well get it from the mast of Merge - Rob Tiffany. Rob spends his time traveling around the world helping customers scale and configure Merge. If it's been done, Rob has seen it, and likely has helped get it working.

Other Support/Info Channels

SQL Server Compact Blogs & Forums

Steve Lasker's Blog
The blog you got this document from, :) Lots of information on how we got here, demos and powerpoints. But, since I've moved off the team, won't be able to maintain the information going forward, so I'd recommend the following blogs going forward.

SQL Server Compact Team Blog
Where most of the team posts info. Everything from our encryption details, Entity support, query processor details, etc. You can think of it as the authoritative source. Even Laxmi posts to the Team Blog as well as his own...

Laxmi's Blog
One of great and passionate developers on the SQL Server Compact team. Be careful what you ask for, ‘cause Laxmi will tell you J. Seriously, Laxmi spends a lot of time in the forums listening and answering the issues and has a lot of experience with the product.

SQL Server Compact Forums
Where the team and our MVPs hang out to answer your questions. In addition to the product team, you'll also find answers from those that are actually using the product. We've gotten some great info here as well for how the product is actually used, as opposed to what we thought developers would do with Compact <g>

Sync Framework/Sync Services for ADO.NET Blogs & Forums

Sync Development Center
The home for the sync team and discusses the Sync Framework as well as Sync Services for ADO.NET.

Sync Team Blog
Less formal information on Sync Services and the Sync Framework

Sync Framework/Sync Services for ADO.NET Forums
A great place to post questions and find answers from the Sync team

Syncmaster Rafik website and Blog
Rafik Robeal was one of our core developers for Sync Services for ADO.NET and has all the nuts and bolts knowledge for what we originally built. Unfortunately, Rafik has moved onto other ventures. However, he's still got some great content on his site.

Enjoy the holidays,

Steve

Evolution or Revolution for moving to offline architectures

Steve.Lasker — Sat, 18 Oct 2008 03:15:00 GMT

There's been a lot of talk, momentum and questioning for where and how occasionally connected designs fit into the application landscape. There have been a lot of questions for "if and how" developers can take their existing apps "offline". There have been a number of efforts for enabling offline apps and some longer term plans. In VS 2008 (Orcas) we introduced Sync Services for ADO.NET as a developer focused way to synchronize data. The roadmap continues with the Microsoft Sync Framework releases. We've started to show "Astoria Offline" as a means to enable sync over REST based HTTP protocols enabling more generic services. But do any of these "solve the problem". It's been a while since I've done a brain dump on some thoughts related to the evolution vs. revolution of app models, so what better way to dump thoughts than a blogicle.

Can you take your current app and make it offline?
The reality is "it depends". There are so many app designs, it's hard to say definitely what works and what doesn't. There are some well established things that have worked and haven't, but it's not fair to say these apply 100% of the time. One size doesn't fit all.

Intercept/fall back
Do you go with the intercept model? When online and connected, the app communicates directly to the service. (Note I'm using "service" here to represent any remote source. It could be a database "service" a Web Service, a WCF service, or some other API that's only available when your device is connected to "the network"). When the network falls away, the app "falls back" to a local "cache".

This is generally a bad (opinion), or complicated (fact) model. This assumes one of two things. Either your user knows they're going offline and they synchronize before they yank the cable or they predict when the network fails. Of course the application can constantly synchronizing data in the background. Crystal ball? When do you really know or have time to sync beforehand? You're working in your office, and Outlook pops up reminder. Or worse, you get an IM or Text message asking "where are you". You grab your laptop and run... oh, wait, you forgot to sync. Do you have the info needed for the meeting?

For the background sync, one of two things could be happening. When you "fall offline", your view of data suddenly changes because your local copy is so out of date compared to the data you were just looking at, or your synching often enough that there's no difference, asking why you're even trying to work online in the first place. Or, you've effectively created a denial of service attack by asking, has anything changed, has anything changed, has anything changed?

Outlook 2003 (I think that was the version) tried this fallback model. It was awful. You're sitting in your office, writing an email, looking at your inbox. The network goes down, your inbox view completely changes, or worse Outlook froze, and you lost that message you were carefully wording.

Always work locally
In this model, you synchronize everything you need, and make all your interactions against the local store. This is sort of the Outlook model today (Outlook 2007). There are equal problems here. Is it realistic to have all the data locally? Even Outlook data can be significantly large, and that's clearly your data. What about public folders? By default, these are only available online. If you're online, they work. If you're not, they don't. Fairly straight forward; but what about historical data for all the products the company has shipped? What about your list of customers, or the current list of stocks and their prices?

The reality is data volume is growing at an exponential rate. Storage continues to get cheaper and faster. 1TB disks and Solid State storage are becoming mainstream. The problem is while connectivity is getting better; the bandwidth isn't increasing at the same rate. And, even as it does, is it realistic to have everything local? Do you keep one of everything that Home Depot or Safeway keeps in stock? Would be really nice, but not all that practical.

One size fits nobody
The reality is there's no easy answer. This is really an architectural and user model change is required to make this happen. We've been through these before. In the "old times", families ate what they grew. Corn, milk, meat, etc. Others only had Ice or Milk that was delivered to their house daily. You could think of this as the "online model". Today, we go shopping to Safeway, D'Agostino, or your local grocery store. The stores don't grow anything locally. They stock goods they get from somewhere else. You take stuff home and stock it in your pantry, frig, freezer. When you throw out the garbage it goes into the can. The can gets picked up on Thursday. It gets taken to the transfer station, and then off to the dump. The point is we have lots of "store and forward"/sync models already in place. What's really interesting is the "online" things are actually more expensive. It turns out it's cheaper to stock goods that may be used, and accept a percentage of loss for things that don't sell than it is to create on demand. Why do we think electronic bits and bytes should be "online" only? Why are 1's and 0's more expensive than physical goods?

Evolutionary approach: Mapping concepts
If we look at the concepts we have today in web/service/stateless models, they break down into two common, and one advanced models:

Get
Get maps very easily to HTTP:Get. Essentially you make a request to a domain, application and method. You likely pass parameters and of course all the authentication goo. The result of the get is returned and you now have a copy of information relevant to that point in time, and the specific question you've asked. Most likely, but no guarantee it's accurate by the time you quickly display it on your 64bit, quad laptop with a gigabit connection to the internet. Even historical data is subject to "correctness"- remember the Florida elections J But, we live with "copies" all the time. Copies are tangible, things that are "just there". There's a separate question of how "out of date" the copy is.

Submit
You have some information you're sending back. You expect some action to be taken on the data you're submitting. That submit can be accepted, rejected or modified. You get an immediate response, but no guarantee what you've submitted will be accepted. That might happen later on, it might not. You hope, or expect to be notified if something changes. But is that concept built into our app models? Or, do we just assume the world is globally connected, and everything is always running so things can be asked and answered immediately, with 100% accuracy, in one big transaction so no two people can allocate the same "goods".... Whew, that's as ridiculous to assume as it is to type.

Can Get and Submit evolve?
With Get, you can implement a "caching" model. Rather than Get directly from the source, imagine you Get through an abstraction layer. For each Get the abstraction layer keys off the domain/app/method and name/value pairs for parameters. Let's say I make a service call to: http://AcmeServices.com/Books/GetBookByName.asmx. I pass in: Title=SQL Server Compact

In the GetCache, it looks for the service and name/value pairs that match. If it finds a result, it may not have to actually make the network call. It could just return the cached result. But what about stale data? You can put an expiration policy on the cache. For a list of states, a day is likely more than generous. For pricing, maybe an hour. The point is you can customize this per source. For many things, one could argue most queries, the data is fairly static and the app could benefit immensely by caching the "gets". If, however, you were to look online first, than only if the resource wasn't available look in the local cache than what benefit are you getting? Sure, the app would "work offline", but you don't see any benefit in the online mode. Each request still takes the time to roundtrip. If you implement a smart caching model you can provide dramatically faster user responses. ...and in most cases, the data is perfectly accurate. Now it would sure be nice to know when something changes, so if California does sink, Iraq or Canada become the 51^st state, you don't have to watch CNN and ask all your clients to either wait for the cache to update, or "invalidate" the cache. I talked about notifications a bit here, so I'll keep going.

Submit
This one gets interesting as well. You have an order to submit for some widgets. Sure, you can submit directly to a "Web Service", or web page. But in many situations the order submission doesn't actually mean the order will ship. Accounting needs to verify your credit. The products that were supposed to be in stock may have been routed to a bigger customer, or "fell off the truck". Again, the point is just because you may get an immediate acknowledgement the order was accepted, doesn't mean it will be fulfilled. So, why not accept this as the model, and when it works, it just works. When a problem occurs, it's not really a problem because it's built into the system. What if you "queued it up" for sending? In this case we save the message locally, in a "logical queue", and when the service is available, we send it on its way. I used the term "logical queuing" as I'm not implying you must use something like SQL Server Broker, MSMQ or WCF Queues, etc. These tend to be a bit over complicated for what you need on the client, and it makes it difficult to act, query or evaluate the data in its transient state. A while back I wrote a blogicle on and some samples for Logical Queuing.

Sync
This is what some might assume is the answer to all of these problems. If I can synchronize changes from other nodes (the server and other clients) with my local store, and I can make changes locally and have them synchronize back "up" to the other nodes, doesn't that solve everything? In the land of demos, sure. But in the real world there are just too many complications. The volume of data, requirements for business logic, and workflow make it difficult to assume Sync can solve all the problems. Where sync does do really well is for synchronizing reference data. That list of states, codes, or even larger volumes like the product catalog. The Logical Queuing blogicle and sample demonstrate some thoughts here. I recently saw some work the Microsoft Mobile Line of Business CRM team, and it also uses a similar model.

Revolution is on the horizon
With all the complications and half way solutions, you have to wonder what's the real answer to all this mess. Will this problem just go away because we'll have high speed internet available everywhere? Even if you could be guaranteed internet access everywhere, do we think that every service will be available all the time? As the world gets more connected, will systems be more reliable and capable of enlisting in massive distributed transactions? Or, will computing systems evolve to what every other large scale system as evolved to. Queuing, Caching, Reserving, Buffering, Acknowledgement, Conflict Detection & Resolution and Notifications.

While I talked a bit about the food supply earlier, this is also a bit like the VB Classic to Web transition. For those old enough to remember the great 90's there was a big transition from "fat clients" to "thin clients". No subtle suggestion of which is better there J When developers first started building ASP Classic (pre .net) apps they simply moved their session state to the ASP Session object. Which meant web servers could serve about 5-10 people before falling over. Not exactly the promise we had all hoped for. It took a while to realize the app models had to change. But, moving from Client apps to Web apps was a bit more obvious. Mostly because the UI changed (for the worse), but at least users could get their work done because we couldn't get the VB apps deployed. (yes, I'm over simplifying things, but run with me for a minute).

Since developers had to re-write their UI anyway, it was an obvious change. Making the transition from online to offline mode apps isn't as obvious. The only UI required is the UI really telling them when problems occur. Who wants that?

The reality is things are a changing. Nothing to announce, nothing to promise, but there is a revolution on the way. Revolutions take time for people to live through denial that it's coming, but it comes as a wave of reality that just smacks you with "duhh, I guess that was a stupid assumption".

While we all wait for the revolution, you can look at things like ADO.NET Sync Services, the Sync Framework, Astoria Offline, and lots of goodies the Patterns and Practices team has done.