Showing posts with label OCS Sync Framework. Show all posts
Showing posts with label OCS Sync Framework. Show all posts

Saturday, May 12, 2007

Synchronization Services Runtime Beta 1 for ADO.NET 2.0 Is Available

Rafik Robeal announced in his Just Published! Microsoft Synchronization Services for ADO.NET Beta 1.0 post of May 12, 2007 that the Beta 1 version of the Sync Services runtime for .NET 2.0+ and Visual Studio 2005 is available here. These bits are the same as those for the Sync Services runtime in Visual Studio "Orcas" Beta 1.

Updated documentation for runtime Sync Services, which also applies to the Orcas Beta 1 implementation, is available here. (It must be a cold day in hell, because the documentation preceded the binaries.)

You'll need to make a few changes to using/Imports directives and altered object and property names than have changed from the earlier versions used in Rafik's samples.

Update 5/17/2007: Rafik has updated his six sample applications for the Beta 1 runtime release.

The runtime doesn't include the graphic Sync Designer that opens when you add Orcas Beta 1's Local Database Cache template to a VB or C# project. My A Sync Services Bidirectional Test Harness blog of March 23, 2007 describes a Windows form app that synchronizes the Northwind Orders and Order_Details tables between an SQL Server 2005 Express (SSX) instance and an SQL Server 2005 Compact Edition v3.5 (SSCE) database.

Note: Converting the Test Harness from the Orcas March 2007 CTP to Orcas Beta 1 failed due to issues with the Sync Designer's generation of the Northwind.sdf database. Specifically, the Sync Designer didn't add the required LastEditDate and CreationDate fields to the SSCE Orders and Order_Details tables, which causes replication to fail with error messages about the missing fields. For more information see my Sync Designer/SSCE Version Problems with Orcas Beta 1 post in the Microsoft Synchronization Services for ADO.NET forum and Bad Error Message Connecting to SSCE v3.5 from Orcas Beta 1 in SSMSX SP2 under Vista post in the SQL Server Compact Edition forum.

Monday, April 02, 2007

SQL Server Compact Edition and Synchronization Updates

Steve Lasker's Creating your SQL Server Compact Edition database and schema in code post proposes to create your local SSCE database on the fly from T-SQL commands that you store as an application resource. SSCE's DDL doesn't accept multiple (batched) commands but SQL Server Management Studio [Express] (SSMS[X]) SP2 hides this limitation from you by allowing GO to separate batched commands.

Steve suggests the neat trick of adding the batch file that you tested and saved in SSMS[X] to the project's resources, and then use String.Split in code like the following to obtain an array of commands:

Dim commands() As String
commands = My.Resources.DatabaseCreation.Split( _
   New String() {"GO"}, StringSplitOptions.RemoveEmptyEntries)

If you use Orcas's Sync Designer to generate the local database cache from the server database's metadata, you must add foreign key and other constraints, as well as indexes, to SSCE with code. So Steve's approach applies to the SSCE Sync Framework, too.

Click here for a table that describes the most important SQL Server 2005 [Express] features that are missing in SSCE. My "Lighten Up Your Local Databases" article from the March 2007 Visual Studio Magazine issue shows you how to take full advantage of SSCE as a local data cache.

SyncGuru Rafik Robeal's sixth Sync Framework demo, Decoupling of Change Tracking Metadata, separates tracking information (for example, CreationDate, LastEditDate, and ClientID fields) into a separate tracking table. Using a separate tracking table minimizes the effect of synchronizing client caches on a production database's schema. Rafik says:

The good news though is that the building a decoupled change tracking layer is not a big deal. In the decoupled model, the base table schema remains intact. As the demo shows, three triggers (insert, update, and delete) and separate tracking table are enough to build equivalent change tacking model. Although, the sync commands need to change since it needs to grab corresponding tracking information by joining the base table with the tracking table, the changes are simple and easy to understand.

Wednesday, February 28, 2007

Orcas March CTP Available from MSDN

Microsoft released on February 28, 2007 the Microsoft Pre-release Software Visual Studio Code Name "Orcas" - March Community Technology Preview (CTP) as a self-extracting install or VirtualPC image. The Release Notes are here. According to the Overview on the download page, highlights for LINQ and ADO.NET 3.0 are:

  • LINQ

      The LINQ Project: this CTP represents a major milestone in the LINQ project. For more information about LINQ click here

    • VB 9.0 Language Support: This CTP contains the following language features:
      • Query Expressions: Basic querying, filtering, and ordering support
      • Object Initializers
      • Extension Methods
      • Local Variable Type Inference
      • Anonymous Types
      • XML literals
      • XML properties
      • New Line and Expression IntelliSense
    • C# 3.0 Language Support: This CTP implements all of the C#3.0 language features from the May LINQ CTP including:
      • Query Expressions
      • Object and Collection Initializers
      • Extension Methods
      • Local Variable Type Inference and Anonymous Types
      • Lambdas bound to Delegates and Expression trees
      • Complete design-time support: IntelliSense, Formatting, Colorization
    • LINQ to ADO.NET
      • ADO.NET is fully integrated with LINQ and offers many options for using LINQ in various scenarios: LINQ to SQL provides direct access to database tables from the programming environment, LINQ to Entities enables developers to use LINQ over EDM models, and LINQ to DataSet allows the full expressivity of LINQ to be used over DataSets.
      • LINQ to Entities enables developers to program against a relational database using a view of the data that is appropriate for the application they are building, independent of the structure of the underlying database. The use of the Entity Data Model (EDM) enables developers to design models that follow the concepts built into the application, instead of having to map them to constructs available in relational stores. LINQ to Entities is built on the ADO.NET Provider model and will support working against different back end relational stores in addition to Microsoft SQL Server. This CTP includes a LINQ to Entities provider for SQL Server and SQL Server Compact Edition.
      • LINQ to SQL (previous name DLinq) has enhanced the functionality from the May 2006 LINQ CTP. You can find it in System.Data.Linq namespace in System.Data.Linq.dll. New in this release is that DataContext provides optimized modes for read-only use and serialization . Also new is that DataShape streamlines eager loading capabilities and adds the ability to set queries on relationships
    • LINQ To SQL Designer
      • Methods can be created from stored procedures and functions within the designer.
      • Better handling of database schemas.
      • Improved inheritance support in the designer.
    • LINQ over XML (XLinq)
      • System.Xml Bridge Classes added – There is a set of extension methods allowing XPath / XSLT to be used over LINQ to XML trees, allow XSLT transformations to produce an LINQ to XML tree, and to validate an XElement tree against an XML Schema.
      • Event Model - This allows LINQ to XML trees to be efficiently synchronized with a GUI, e.g. a Windows Presentation Foundation application
      • Class hierarchy changes - XObject class added, XStreamingElement class (temporarily) removed
      • Various understandability / usability improvements – There have been a number of relatively minor changes done in response to internal reviews, usability studies, and external feedback to make the API more clean and consistent.
    • LINQ to Objects API
      • The LINQ to Objects API supports queries over any .NET collection, such as arrays and Generic Lists. This API is defined in the System.Linq namespaces inside System.Core.dll.
  • ADO.NET
    • Extended, more powerful data APIs with the ADO.NET Entity Framework
      • With the ADO.NET Entity Framework developers will be able to model the view of the data that is appropriate for each one of the applications they are building, independently of the structure of the data in the underlying database. The use of the Entity Data Model (EDM) enables developers to design models that follow the concepts built into the application, instead of having to map them to constructs available in relational stores. Once the model is in place, the powerful ADO.NET Entity Framework API is used to access and manipulate the data as .NET classes or as rows and columns, whatever is appropriate for each application.
    • Added paging and stored procedures for update (“update customization”) for ADO.NET Entity Framework:
      • Paging: the paging support in the ADO.NET Entity Framework allows developers to “page” over data in a database by indicating the start row and number of rows to be included in the result. Paging is available through Entity SQL (using the LIMIT AND SKIP keywords) and through the query-builder methods in the ObjectQuery <T> class (Top and Skip). In a future CTP the feature will also be enabled to be used in LINQ queries by means of the standard Take and Skip LINQ operators.
      • Stored-procedures for update customization: the Entity Framework by default automatically generates SQL statements for insert, update and delete operations when processing changes to entities in memory to be sent to the database. With the stored-procedures update customization feature developers have the option to override the automatic SQL generation and instead provide stored-procedures that will perform the insert, update and delete operations, which the system will call during entity change processing. Among other things, this enables scenarios where direct access to tables is restricted in the database and the only way to make changes to the data is through stored-procedures.
    • Microsoft Synchronization Services for ADO.NET
      • Provides an application programming interface (API) to synchronize data between data services and a local store. The Synchronization Services API is modeled after the ADO.NET data access APIs and gives you an intuitive way to synchronize data. It makes building applications for occasionally connected environments a logical extension of building applications where you can depend on a consistent network connection.

Supported operating systems are Windows Server 2003 and Windows XP. Vista support is conspicuous by its absence.

Update 3/1/2007 9:00 am: Microsoft modified the System Requirements section for the VirtualPC image as follows:

Note that the Orcas Base Image is Windows Server 2003 Enterprise Edition, not Windows Vista, for the Orcas January 2007 CTP. I haven't tested the current Orcas Base Image.

As of 9:45 am, the System Requirements section for the self-extracting install remained:

  • Supported Operating Systems: Windows Server 2003; Windows XP
  • Processor: 1.6GHz Pentium III+
  • RAM: 1 GB of available physical RAM

Lack of Vista support for the self-extracting install is surprising when you consider this post from Somasegar's blog: "Our goal with Orcas is to build the best tool set for Windows Vista ... For the first time, we have a WPF designer in the product, enabling a more complete WPF development experience."

Notice the missing SP2 requirement for Windows XP in both CTP versions.

Related Posts:

  • Charlie Calvert's C# blog has a link to a video about the CTP starring Luca Bolognese and other members of the LINQ team.
  • The XML Team's announcement is here.
  • The Visual Basic Team's annoucement is here.

Question of the Week: Where's Microsoft's VB.NET evangelist who corresponds to the C# group's Charlie Calvert?

The Feature Specifications for Visual Studio and .NET Framework "Orcas" hasn't been updated for the March 2007 CTP and contains only one reference to LINQ (the LINQ to XML Core Specification).

Monday, February 12, 2007

Microsoft Sync Services 1.0 Books Online CTP

Microsoft promised documentation for the Microsoft Synchronizaton Services CTP would be available in "early February" when the Occasionally Connected Services (OCS) team released the Microsoft Synchronization Services for ADO.NET v1.0 CTP (OCS-CTP) on January 22, 2007. Surprise! The OCS team posted the Microsoft Synchronization Services for ADO.NET Books Online Community Technology Preview (OCS-BOL) on February 12, 2007. The download site offers SYNCSVCSBOL-ENU.msi, the 16.7-MB installer for OCS-BOL and SyncServicesCtpSamples.exe, which generates a "Two-Tier Download-Only Sample" application. The sample app synchronizes the Adventure Works sample database's Products table with an SQL Server Compact Edition (SSCE) client database. You need the OCS-CTP, which also installs an updated SSCE v3.5 CTP, the Orcas successor to the SSCE v3.1 RTM bits, which Microsoft released on January 11, 2007. (The prerequisites are the same as those for Rafik Robeal's four OCS demo applications that I've previously described here and here, plus a current version of AdventureWorks.) The SyncComponents_Sample1 Project SyncComponents_Sample1.sln is a C# project that generates a new 276-kB SSCE 3.5 database from AdventureWorks' Customer, Employee, Product, ProductModel, ProductSubcategory, UnitMeasure, SalesOrderHeader, SalesOrderDetail, and Store tables. Synchronization is DownloadOnly, so changes only propagate from the server to the client. Here's an overview of the steps required to test the sample project:

  1. Prepare the server tables for synchronization. Execute the ServerDb_CreateSyncObjects.sql script to add InsertOriginatorID, UpdateOriginatorID and CreateDate tracking columns, a TableName_Tombstone table, and a trgDel_TableName delete trigger to each of the nine tables.
  2. Create the SSCE database and populate its tables. Build and run the project, and then click the Synchronize button. The DataGridView displays changes, not rows added for initial table population.
  3. Add insert, update and delete stored procedures. Execute the ServerDb_DMLSyncObjects.sql script to create uspProductInsertCommand, uspProductUpdateCommand, and uspProductDeleteCommand stored procedures.
  4. Make changes to the server data. Execute the stored procedures a few times to generate changes to the Product table.
  5. Synchronize the client. Click Synchronize to pull and display the server changes.

The following screen capture reflects inserting 21 rows with the uspProductInsertCommand.

This sample project won't win any awards for comprehensive coverage of Sync Services code. Unlike Rafik's demos, it doesn't support Bidirectional synchronization. On the whole, Rafik's projects provide a much better overview of Sync Services programming techniques. Tip: If you receive an unhandled exception that starts with "Table '[ProductSubCategory]' could not be created," you have an old AdventureWorks version in which the the ProductSubCategoryID had the smallint data type. The GetSchema method attempts to add it to the SSCE ProductSubCategory table as a smallint identity column, which SSCE doesn't suport. Update your AdventureWorks database from the link provided. You must delete the AWClientDB.sdf file in the \Program Files\Sync Services\Samples\SyncComponents_Sample1\SyncComponents_Sample1.Client\bin\Debug folder before you can successfully populate the client database. Technorati tags: , , , , , , , , .

Wednesday, February 07, 2007

Conflict Resolution with Sync Services

Rafik Robeal has posted the fourth Microsoft Synchroniztion Services (OCS) demo project, Offline Application—Conflict Handling, on his The Synchronizer blog. This C# project demonstrates handling Sync Services' ApplyChangesFailed event to determine the failure location (server or client) and type of concurrency conflict, and then specifying an action to ignore or resolve the conflict. Rafik's post, which augments three preceding Sync Services demo projects, describes the ApplyChangesFailedEventArgs.Conflict.ConflictType enumeration:

  • ClientInsertServerInsert also known as PK Collision; occurs when both client and server insert a row with same PK
  • ClientUpdateServerUpdate the most common conflict; occurs when client and server make changes to the same row independently
  • ClientUpdateServerDelete occurs when the client updates a row and the server independently deletes the same row
  • ClientDeleteServerUpdate occurs when the client deletes a row and the server independently updates the same row

The SyncForm has four added buttons to generate random conflicts on the client or server:

Actions available to attempt to resolve concurrency conflicts are:
  • ApplyAction.RetryApplyingRow without changing to the datarow the retry will fail causing the event to be raised again. The demo does not allow you to edit the datarow though.
  • ApplyAction.RetryWithForceWrite has support built in the ClientSyncProvider. On the server side, you need to add support in your sync adapter commands; the demo shows an example for update-update conflict.
  • ApplyAction.Continue ignores the conflict
  • Abort the sync operations by throwing an exception; all changes will be rolled back and re-synced in the next sync session.
The ConflictForm's four action buttons are enabled as appropriate for the conflict type and location:

After taking the appropriate action, the ProgressForm opens: Rafik explains that the synchronization framework defines the following two commands to find the rows in conflict:
  • SyncAdapter.SelectConflictUpdatedRowsCommand this command finds conflicting rows in the base table. The sync runtime executes this command if insert, update or delete command failed (i.e. returned 0 row count)
  • SyncAdapter.SelectConflictDeletedRowsCommand this command finds conflicting rows in the tombstone table. The sync runtime executes this command if the conflicting row was not found in the base table. This is how ClientUpdateServerDelete conflict is detected.

The two commands are implemented for the two tables—orders and order_details—by four T-SQL stored procedures on the SQL Server 2005 [Express] server.

Note: Be sure to run the demo.sql script (to the -- Test Sample comment only) to create (or recreate) the pub database and the four server-side tables (orders, order_details, orders_tombstone, and order_details_tombstone) on an SQL Server 2005 [Express] instance, then run the server_procs.sql to generate the stored procedures, and finally build and run OfflineAppDemo-Conflicts.sln. Note that the tombstone tables have a new schema to support multiple deletions of records with the same primary key.

Technorati tags: , , , , , , , , .

Thursday, November 09, 2006

ADO.NET Sync Framework for Occasionally Connected Systems

WiFi Internet connectivity is becoming ubiquitous in first-world urban areas, but there are classes of data collection/management applications that must be operable during wired and/or wireless network outages—emergency and health services, for example—or exhibit dramatically decreased user productivity without a live network connection—field sales workers come to mind. Some occupations are inherently occasionally connected: governmental, academic, and corporate field workers in rural locations; land surveyors; forest rangers; environmental scientists; marine biologists and the like. Seldom, occasionally, and usually-connected users need the ability to cache data locally and synchronize local data with large back-end databases. The preferred caching and synchronization model is Outlook 2003/2007, where clients always work with their local data store and the server only propagates data changes to the client. Following are the most common methods of client-side caching and synchronization:

  • ADO.NET Datasets persisted as XML files
  • Remote Data Access (RDA) for SQL Mobile/SQLce databases
  • Merge replication to SQL Server 2005 (not Express)
  • Occasionally Connected Systems (OCS)Sync Framework (future)
ADO.NET Datasets Microsoft's developers designed ADO.NET Datasets to support data management applications for usually, occasionally, or seldom-connected mobile users. Datasets persist dynamic (read/write) and a subset of catalog (read-only, slowly changing) relational data in XML files. Datasets replace combinations of merge and snapshot replication with a lighter-weight, XML file-based system that uses DataAdapters to communicate with back-end RDBMSes. I described disk and RAM resource consumption issues with large ADO.NET 1.1 and 2.0 Datasets in my May 2004 "Store Large Lookup Tables in DataSets" article for Visual Studio Magazine (reading page 2 requires free registration.) The article's Table 1 shows the time to load Datasets of various sizes from XML files Although multi-MB Datasets are practical for today's laptop, tablet, and ultra-mobile (portable) PCs, their resource consumption precludes use on Windows CE, PocketPC, SmartPhone, and similar devices. Single-file relational databases, such as SQL Server 2005 Compact Edition (SQLce), are better suited than Datasets for portable PCs and devices when data storage requirements exceed a few MB. Remote Data Access RDA is the basic application for synchronizing data between SQL Server Mobile or, more recently, SQLce—formerly called SQL Server Everywhere (SQLEv). RDA pulls data from a remote SQL Server 2000 or 2005 table to a client's SQLce table. The SQLce database keeps track of changes changes to the pulled data and, on demand, pushes the changes to the back-end server. RDA also can execute CRUD (CREATE, RETRIEVE, UPDATE, and DELETE) operations on the remote server with Transact-SQL (T-SQL) statements. SQL Server doesn't push changes in its data to SQLce; thus, RDA is a one-way replication technology.

RDA connects to the back-end database with the HTTP or HTTPS protocols to Internet Information Services (IIS) on the server and pass compressed data through firewalls. Custom C#/VB code or the Connection Manager application handles the details of the connection. RDA is the only method of replicating data between SQL Server 2005 Express (SQLX) and SQLce, because SQLX (unlike MSDE 2000) isn't a merge replication publisher. RDA can detect but doesn't handle concurrency or referential integrity conflicts, and schema changes aren't allowed.

Merge Replication Replication is the traditional means of updating data between SQL Server instances, and merge replication is the most common type. Merge replication uses a different Connection Manager to handle communication with the back-end database using HTTP or HTTPS protocols to pass compressed data through firewalls. Merge replication is two-way, supports referential integrity, handles concurrency conflicts, and allows schema changes. Merge replication, including subscription and publication, is a heavyweight process compared to RDA push/pull operations, but is quite reliable. OCS Sync Framework The OCS Sync Framework involves a SyncAgent on the client that uses a SyncTable to manage a ClientSyncProvider for each type of local store, such as SQLce or SQLX. Server-side components include a ServerSyncProvider, SyncGroup, SyncAdapter, and SyncAdapter commands. The SyncAdapter and SyncAdapter commands (DBCommand objects) are ADO.NET database-agnostic objects so synchronization can occur with SQL Server, Oracle, IBM DB2 or any other RDBMSes that have an .NET native data provider. IncrementalInserts, IncrementalUpdates and IncrementalDeletes enable clients to request the server to update catalog data. The client and server can push changes directly with SQL Server TDS or another RDBMS's wire protocol when a physical network connection is available. Otherwise the client can push and pull changes with a proxy that connects to a service. Synchronization methods can be:
  • Pull only from server (unidirectional)
  • Push only to server (unidirectional)
  • Push and pull (bidirectional)
  • Snapshot (no synchronization)

The OCS Sync Framework appears to fall midway between the lightweight RDA and heavyweight merge replication method in operational complexity and resource consumption, but the current (very early) implementation requires a substantial amount of client code to specify synchronization type and SQL statements for DBCommands.

Live From Redmond: Smart Client: Offline Data Synchronization and Caching for Smart Clients is Steve Lasker's 94-minute Webcast that covers Dataset, RDA, merge replication, SQL Query Notifications, and a preview of the OCS Sync Framework (requires free registration). Steve is a Microsoft program manager/technical lead and informal evangelist for OCS, Windows forms, VB .NET, and ADO.NET Datasets. Steve also delivered a more general Live From Redmond: Visual Studio: Developing Local and Mobile Data Solutions with SQL Server Compact Edition Webcast on December 4. Steve also offers an Occasionally Connected Systems slide deck and a screencast that demonstrates how the OCS Sync Framework operates and VB WinForm code to synchronize a client with SQL Server. Most public OCS-related information presently comes from Steve's blog. His "Tech Ed 06 Slides and Demos on SQL Server Everywhere Edition" post has links to DEV351: Developing Local and Mobile Data Solutions with SQL Server Everywhere Edition and DEV343: Offline Data Synchronization and Caching with SQL Server Everywhere Edition.

Update: 12/9/2006: 12/4/2006 Webcast name updated.

Technorati tags: , , , , , , , , , , , , ,

Wednesday, November 08, 2006

SQL Server 2005 Compact Edition RC1 Available

Microsoft accounced on November 7, 2006 the availability of SQL Server [2005] Compact Edition (SQLce) 3.1 Release Candidate 1 (RC1). SQLce—formerly named SQL Server Everywhere Edition (SQLEv) 3.1—is a lightweight, in-process cousin of SQL Server 2005 and SQL Server 2005 Express. SQLce is the successor to earlier SQL Server Mobile 3.0 and SQL CE 2.0 and 1.0 editions. You can download the SQLce RC1 runtime and readme, as well as SQLce RC1 Books Online. SQLce is an embeddable, small-footprint, single-user database for mobile and desktop applications. As an example, you can substitute SQLce for SQL Server 2005 Express (SQLX) when you need local storage for usually, occasionally or seldom-connected systems. SQLce uses the ADO.NET programming model, supports most SQL Server 2005 data types and T-SQL reserved words, and is freely distributable.

According to the "Microsoft SQL Server 2005 Compact Edition Overview" white paper, SQLce:

  • Occupies only 1.8 MB of disk space
  • Supports single-file databases up to 4 GB in size
  • Uses 128-bit SSL for secure and reliable functionality, even through firewalls
  • Uses 128-bit RSA file-based encryption on devices for database file security
  • Provides an encrypted data format with password protection
  • Will use the ADO.NET Sync Framework in Visual Studio vNext ("Orcas")

A separate OakLeaf blog post, "ADO.NET Sync Framework for Occasionally Connected Systems" has the details on Microsoft's new approach to SQLce synchronization that's coming in Orcas.

I wrote about Mobile Edition's morph to Everywhere Edition in my May 1, 2006 "SQL Server 2005 Mobile Edition Goes Everywhere" article for Fawcette Technical Publications Online's "Special Report: SQL Server." "SQL Everywhere" had a "déjà vu all over again" ring to me. It appears that I wasn't the only one non-plussed about the "Everywhere" suffix, which appeared to me to encroach on Sybase's SQL Anywhere trademark for a similar database product. Sybase also claims here that SQL Everywhere is their trademark. Here's what Microsoft has to say about renaming SQLEv to SQLce:

SQL Server 2005 Compact Edition, was previously named SQL Server 2005 Everywhere Edition during the product development phase. Customers have communicated to Microsoft through the pre-release community technology preview (CTP) program and other channels that this product name may cause potential confusion with other database product names in the industry. Microsoft has taken this feedback seriously and has accordingly changed the official product name.
Of course, this isn't the first time that Microsoft has done an about-face on product and architecture names. Remember .NET Everything? Steve Lasker's "SQL Server Everywhere Gets a New Name" post has more to say about the name change and SQLce's features in the forthcoming RTM bits. Steve is a Microsoft program manager/technical lead for Occasionally Connected Systems (OCS) and the forthcoming ADO.NET Sync Framework. Steve's Live From Redmond: Visual Studio: Developing Local and Mobile Data Solutions with SQL Server Compact Edition December 4, 2006 Webcast provides a detailed overview of SQLce's capabilities. His presentation includes a substantial amount of VB (!) ADO.NET code. (Free registration required.) Several comments about the post complain about SQLce's 4 GB size limit, which is a significant problem for local document storage. In a reply to a comment by John, Steve says, "Again, the current 4gb limit is purely a device optimization that we will definitely remove now that we’re running on larger desktop scenarios. ... The 4gb limit isn’t a 'free' restriction as we’ve done with Express." Microsoft's product page for SQLce hadn't been updated from SQLEv to SQLce terminology when this post was written. If you're working with the SQLEv CTP on devices, you can download the CTP for SQLEE Access Database Synchronizer to synchronize data between Access 2000 - 2007 databases and SQLEv CTP or SQLce RC1. There's more information on all these topic, plus details for the Microsoft SQL Server 2005 Compact Edition Tools for Visual Studio SP1 Beta, which Microsoft says updates the VS 2005 SP1 Beta smart device development components with the design time environment for SQLce, at the SQL Server Everywhere Edition [sic] blog. The SQLce newsgroup is here.

Updated 11/9/2006 with additional details about and links to SQLce, SQLEv, OCS and Sync Framework topics. 12/9/2006: Added 12/4/2006 Webcast link.

Technorati tags: , , , , , , , , , , , , ,