A separate 1099 for Hood Canal Press tells me that my SQL Server Merge Replication books are still killing it!  Our world of disconnected devices require efficient data sync now more than ever.  Despite a variety of sync technologies out there, Merge is still the best!

The new Sync Framework Toolkit found on MSDN builds on the existing Sync Framework 2.1′s ability to create disconnected applications, making it easier to expose data for synchronization to apps running on any client platform.  Where Sync Framework 2.1 required clients to be based on Windows, this free toolkit allows other Microsoft platforms to be used for offline clients such as Silverlight, Windows Phone 7, Windows Mobile, Windows Embedded Handheld, and new Windows Slates.   Additionally, non-Microsoft platforms such as iPhones, iPads, Android phones and tablets, Blackberries and browsers supporting HTML5 are all first-class sync citizens.  The secret is that we no longer require the installation of the Sync Framework runtime on client devices.  When coupled with use of an open protocol like OData for data transport, no platform or programming language is prevented from synchronizing data with our on-premise and cloud databases.  When the data arrives on your device, you can serialize it as JSON, or insert it into SQL Server Compact or SQLite depending on your platform preferences.

The Sync Framework Toolkit provides all the features enabled by theSync Framework 4.0 October 2010 CTP.  We are releasing the toolkit as source code samples on MSDN with the source code utilizing Sync Framework 2.1.  Source code provides the flexibility to customize or extend the capabilities we have provided to suit your specific requirements. The client-side source code in the package is released under the Apache 2.0 license and the server-side source code under the MS-LPL license.  The Sync Framework 2.1 is fully supported by Microsoft and the mobile-enabling source code is yours to use, build upon, and support for the apps you create.

Now some of you might be wondering why you would use a sync technology to move data rather than SOAP or REST web services.  The reason has to do with performance and bandwidth efficiency.  Using SOA, one would retrieve all the data needed to the device in order to see what has changed in SQL Server.  The same goes for uploading data.  Using the Sync Framework Toolkit, only the changes, or deltas, are transmitted over the air.  The boosts performance and reduces bandwidth usage which saves time and money in a world of congested mobile data networks with capped mobile data plans.  You also get a feature called batching, which breaks up the data sent over wireless networks into manageable pieces.  This not only prevents you from blowing out your limited bandwidth, but it also keeps you from using too much RAM memory both on the server and your memory-constrained mobile device.  When combined with conflict resolution and advanced filtering, I’m sold!

I think you’ll find the Sync Framework Toolkit to be an immensely valuable component of your MEAP solutions for the enterprise as well as the ones you build for consumers.

Keep Synching,

Rob

Since Windows Embedded Handheld uses an advanced version of the operating system kernel used by Windows Mobile 6.5.3, many of the techniques and best practices I’ve taugh customers and developers all over the world still apply.  While it still uses the slotted memory model found in Windows CE 5 with 32 processes and 32 MB of memory per process, you’ll find that numerous enhancements and tuning has taken place to give your line of business apps more of what they need.  I’m talking about more memory per process and improved performance.  Therefore, I’d like you to sit back and watch the video of a presentation I delivered at Tech Ed in Los Angeles a couple of years ago so you can better learn what this mobile platform has to offer in the form of better memory management and improved performance:

A recent Gartner report recommends that organizations should stay with Windows Embedded Handheld as the best mobile platform for enterprise line of business needs.  Great devices are available from OEMs like Intermec, Motorola, Psion, and Honeywell just to name a few.  I hope this video helps you with any memory management or performance issues you may need to deal with in your enterprise mobile apps.

Best Regards,
Rob

Great stuff for those of you who need a database on your device!
-Rob

The Beta Distribution Service allows developers to distribute pre-certified apps to an access-controlled set of beta users.  How does it work?

• The developer selects a list of up to 100 testers.  This number is subject to change based on feedback we get.
• Developer sends an email to the designated testers that includes a private deeplink that points to the app in the Marketplace.  This allows only the testers to access and download the content since the app is not discoverable in the Marketplace via Search.
• Only testers selected in the App Hub based on their Windows Live ID can test the app and provide feedback for 90 days.  Yes, the app will “time bomb” after 90 days.
• The beta cannot be updated.  If you have multiple updates based on testing feedback, you must resubmit them like the first beta and send updated deeplinks to testers.
• Testers won’t have to unlock their phone in order to beta test the apps.
• Since there’s no certification requirement, there’s no latency between when you publish a beta app and when your private list of testers can access and download your content.
• The cost of the beta app must be free.

Takeaway: No matter who you’re building apps and games for, the Beta Distribution Service will allow you to create higher quality content since you can now include beta testing in your development cycle.

The Private Distribution Service allows developers to privately distribute certified apps to a targeted group of users.  How does it work?

• The app must be certified by Microsoft before distributing.
• Developer sends an email to the targeted group of users that includes a private deeplink that points to the app in the Marketplace.  Keep in mind that the app is not discoverable in the Marketplace via Search by the general public.
• A private app can be updated and pushed to the targeted group of users.
• There are no limits on the number of users or the duration of time that those users can use the app.  This works just like the public Marketplace rules we have today.
• There is no access enforcement based list of targeted users.  In other words, if an employee at a company shares the deeplink with a fellow coworker, that new person can download the content.  By including appropriate authentication and authorization mechanisms in published apps, you can prevent unwanted users from being able to do anything with the app.
• Private apps can be free or paid
• These private apps can be published to the public Marketplace at any time.

Takeaway: This enables the private distribution of released apps to a small or large community of users.  You could use this as an extension of your application beta testing cycle if you want to send out a release candidate to a broader group of testers than the 100 allowed via the Beta Distribution Service.  It’s also a great way to privately send your app to magazines, blogs, and other media channels to be publicly reviewed.

What does this mean for the enterprise?  Those of you who have worked with or administered enterprise software distribution systems, will quickly recognize that the Private Distribution Service doesn’t allow an administrator to push out and restrict software usage to specific organizational groups or roles.  It also doesn’t allow an administrator to uninstall specific apps  from the phones of specific users or groups either.  Lastly, it doesn’t map to an enterprise LDAP service like Active Directory.  You’re probably thinking System Center and this is definitely not that.

That being said, the Private Distribution Service overcomes the single-biggest blocker that company executives have expressed to me as a reason why they might not create and publish apps for Windows Phone.  They don’t want their private corporate apps publicly viewable and/or accessible by the broad general public searching for apps in the public Marketplace.  When they build B2C apps to reach their own customers, this is no problem, but when they build line-of-business apps meant just for their employees or partners, they don’t want these apps to be discoverable.

This means IT departments will be able to build undiscoverable Windows Phone apps for private internal use by the users they designate.  Some of the administrative issues around software distribution can be alleviated by having a corporate IT authority publish Beta and Private apps via a single Windows Live ID.  That publishing administrator can then map users, groups or roles to existing or new Windows Live IDs of employees that need to use the app.  That administrator will be able maintain the application lifecycle through beta testing, publishing, updating and decommissioning.  As I alluded to earlier in the post, once a designated employee has access to the app, her ability to run and access data and various parts of the app can be controlled by on-premise or cloud-based authentication and authorization mechanisms.  This includes things like passing Domain credentials or using claims-based auth.  Your data-in-transit is protected by SSL and your data-at-rest in Isolated Storage is protected by AES encryption.

We’ll be seeing a new Windows Phone, App Hub, and Marketplace before the end of 2011.  Its line-of-business credentials include encryption, private software distribution, server auth mechanisms, the ability to call SOAP and REST web services, socket support, multitasking, background agents, and a local SQL database just to name a few. 

You’ll soon be looking at the most enterprise-ready smartphone on the market.

-Rob

We’ve come a long way and you’re probably wondering what qualifies this new embedded database to take on the Internet:

• Native support for x64 Windows Servers
• Virtual memory usage has been optimized to ensure the database can support up to 256 open connections – (Are you actually using 256 pooled connections with your “Big” database today?)
• Supports databases up to 4 GB in size – (Feel free to implement your own data sharding scheme)
• Developed, stress-tested, and tuned to support ASP.NET web applications
• Avoids the interprocess communications performance hit by running in-process with your web application
• Row-level locking to boost concurrency
• Step up to Government + Military grade security SHA2 algorithm to secure data with FIPS compliance
• Enhanced data reliability via true atomicity, consistency, isolation, and durability (ACID) support
• Transaction support to commit and roll back grouped changes
• Full referential integrity with cascading deletes and updates
• Support ADO.NET Entity Framework 4 – (Do I hear WCF Data Services?)
• Paging queries are supported via T-SQL syntax to only return the data you actually need

Wow, that’s quite a list!  SQL Server Compact 4.0 databases are easily developed using the new WebMatrix IDE or through Visual Studio 2010 SP1.  I’m loving the new ASP.NET Web Pages.  It reminds me of the good old days of building web applications with Classic ASP back in the 90′s with Visual InterDev and Homesite.

What about Mobility?

Since SQL Server Compact owes its heritage to mobile and embedded versions of Windows, you might be wanting to know what our story is there.  The good news is that you can build and deploy v4.0 databases on Windows XP, Windows Vista, and Windows 7.  If you want to implement an occasionally-connected solution that utilizes the Sync Framework, Remote Data Access (RDA), or Merge Replication, you’ll need to stick with SQL Server Compact 3.5 SP2.  Time and resource-constraints prevented the Compact team from enabling these features.  Luckily, single-user WPF/WinForms database applications running on Windows Slates, laptops and Windows Embedded Handheld devices will work just fine with the v3.5 SP2 runtime.  Get a jumpstart with this by pickup up “Enterprise Data Synchronization with Microsoft SQL Server 2008 and SQL Server Compact 3.5 Mobile Merge Replication” at   http://www.amazon.com/Enterprise-Synchronization-Microsoft-Compact-Replication/dp/0979891213/ref=sr_1_1?s=books&ie=UTF8&qid=1281715114&sr=1-1 to start building those MEAP solutions.

With the tidal wave of Windows Slates hitting the market, a secure, powerful mobile database that allows users to work offline and syncs with SQL Server is definitely going to be a hot item!

So run, don’t walk to the Microsoft Download site to download the Next-Gen database for the web:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=033cfb76-5382-44fb-bc7e-b3c8174832e2

If you need to support occasionally-connected mobile applications with sync capabilities on muliple Windows platforms, download SQL Server Compact 3.5 SP2:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e497988a-c93a-404c-b161-3a0b323dce24

Keep Syncing,

Rob

Uniqueness is a key factor when synchronizing data between SQL Server/Azure and multiple endpoints like Slates and Smartphones.  With data simultaneously created and updated on servers and clients, ensuring rows are unique to avoid key collisions is critical.  As you know, each row is uniquely identified by its Primary Key.

When creating Primary Keys, it’s common to use a compound key based on things like account numbers, insert time and other appropriate business items.  It’s even more popular to create Identity Columns for the Primary Key based on an Int or BigInt data type based on what I see from my customers.  When you designate a column(s) to be a Primary Key, SQL Server automatically makes it a Clustered Index.  Clustered indexes are faster than normal indexes for sequential values because the B-Tree leaf nodes are the actual data pages on disk, rather than just pointers to data pages.

While Identity Columns work well in most database situations, they often break down in a data synchronization scenario since multiple clients could find themselves creating new rows using the same key value.  When these clients sync their data with SQL Server, key collisions would occur.  Merge Replication includes a feature that hands out blocks of Identity Ranges to each client to prevent this. 

When using other Microsoft sync technologies like the Sync Framework or RDA, no such Identity Range mechanism exists and therefore I often see GUIDs utilized as Primary Keys to ensure uniqueness across all endpoints.  In fact, I see this more and more with Merge Replication too since SQL Server adds a GUID column to the end of each row for tracking purposes anyway.  Two birds get killed with one Uniqueidentifier stone. 

Using the Uniqueidentifier data type is not necessarily a bad idea.  Despite the tradeoff of reduced join performance vs. integers, the solved uniqueness problem allows sync pros to sleep better at night.  The primary drawback with using GUIDs as Primary Keys goes back to the fact that SQL Server automatically gives those columns a Clustered Index.

I thought Clustered Indexes were a good thing?

They are a good thing when the values found in the indexed column are sequential.  Unfortunately, GUIDs generated with the default NewId() function are completely random and therefore create a serious performance problem.  All those mobile devices uploading captured data means lots of Inserts for SQL Server.  Inserting random key values like GUIDs can cause fragmentation in excess of 90% because new pages have to be allocated with rows pushed to the new page in order to insert the record on the existing page.  This performance-killing, space-wasting page splitting wouldn’t happen with sequential Integers or Datetime values since they actually help fill the existing page.

 What about NEWSEQUENTIALID()?

Generating your GUIDs on SQL Server with this function will dramatically reduce fragmentation and wasted space since it guarantees that each GUID will be sequential.  Unfortunately, this isn’t bulletproof.  If your Windows Server is restarted for any reason, your GUIDs may start from a lower range.  They’ll still be globally unique, but your fragmentation will increase and performance will decrease.  Also keep in mind that all the devices synchronizing with SQL Server will be creating their own GUIDs which blows the whole NEWSEQUENTIALID() strategy out of the water.

Takeaway

If you’re going to use the Uniqueidentifier data type for your Primary Keys and you plan to sync your data with RDA, the Sync Framework or Merge Replication, ensure that Create as Clustered == No for better performance.  You’ll still get fragmentation, but it will be closer to the ~30% range instead almost 100%.

Keep synching

Rob

In my last Sync/Contention post, I beat up on a select group of SAN administrators who aren’t willing to go the extra mile to optimize the very heart of their organization, SQL Server.  You guys know who you are.

This time, I want to look at something more basic, yet often overlooked.

All DBAs know that Joining tables on non-indexed columns is the most expensive operation SQL Server can perform.  Amazingly, I run into this problem over and over with many of my customers.  Sync technologies like the Sync Framework, RDA and Merge Replication allow for varying levels of server-side filtering.  This is a popular feature used to reduce the size of the tables and rows being downloaded to Silverlight Isolated Storage or SQL Server Compact. 

It’s also a performance killer when tables and columns participating in a Join filter are not properly indexed.  Keeping rows locked longer than necessary creates undue blocking and deadlocking.  It also creates unhappy slate and smartphone users who have to wait longer for their sync to complete.

Do yourselft a favor and go take a look at all the filters you’ve created and makes sure that you have indexes on all those Joined columns.

Keep synching,

Rob

Sync technologies like Merge Replication and the Sync Framework track changes on SQL Server using triggers, stored procedures and special tracking tables.  The act of tracking changes made by each SQL Server Compact or Silverlight sync subscriber can cause a lot of locking and blocking on the server.  This diminishes performance and sometimes leads to deadlocks. 

Therefore, don’t listen to your SAN administrator when he says the RAID 5 will do.  RAID 1 or 10 must always be used for all databases, tempdb, and transaction logs.  Furthermore, each of these database objects must be placed on their own dedicated RAID arrays.  No sharing!  Remembers, as a DBA and sync expert, knowledge of SAN configuration must always be part of your skillset.

Keeping synching,

Rob