SQL CE Console Updated

SQL CE Console was just updated to version 1.2.605. Besides supporting SQL Everywhere on the desktop, I corrected a few minor bugs and added timer and row count reporting to both table dumps and SQL command results. Get the updated setup here.

Supporting SQL Everywhere

I have just updated SQL CE Console so that it supports the Microsoft SQL Server 2005 Everywhere Edition CTP. The news bit can be read in this page, where you will also find the links to the downloads.

Adapt your application to exotic screen resolutions

Microsoft has just launched the Adapt Your App site to help all the Mobile developer community to better adapt to the new exotic device screen resolutions. Here you will find all the resources and downloads to help you adapt you app to, say, landscape Smartphone.

SQL Everywhere CTP

In the same day I returned from MEDC Europe, I'm greeted with some great news: Microsoft released the SQL Server 2005 Everywhere Edition CTP! Thanks to Alex Yakhnin for the heads up.

Migrating Sync to SQL Server

The first phase of the Data Port Sync migration to SQL Server (2000, MSDE, 2005 and Express) is over with the port of the Jet preparation code. It is quite interesting to see how Microsoft implements the "same" features in all of these databases. With Jet, one can do everything with OLE DB whereas with SQL Server one must resort to T-SQL to get some of the schema information. As I found out when I was developing Data Port Wizard, SQL Server does not allow you to mix direct table access (inserts) with IDENTITY_INSERT: you have to use an SQL INSERT command. Also, Jet and SQL vary wildly in how they manage IDENTITY columns: Jet makes it a piece of cake, SQL is a bit harder especially when you have to know the current seed. Finally, I found out that there is no way to create the equivalent of a ROWGUIDCOL column in Access through a SQL CREATE command - you do have to go through OLE DB.

Having said all this, I am not sure that this will be the final preparation code for SQL Server. As a matter of fact, with a more advanced database engine I will ba able to use triggers to flag any changes to the tracked tables (or so I hope...).

Data Port Sync Released

Version 1.0.500 of Data Port Sync has been released. I will be adding more samples to the code to better illustrate what is an arguably complex piece of software. If you want to take a look at how the whole process works, I advise you to start by the JetSync sample (only available in C# but I'm porting it to VB). This sample does the whole synchronization process for one database:

1. Prepares the Access database for synchronization by adding the tracking columns and tables
2. Exports the database to the device in SDF format (either SQL CE 2.0 or SQL Mobile)
3. Tracks the changes on both ends and
4. Merges them according to a very simple rule: the Access database always wins

There is another C# sample (Prepare) that you may use to prepare and "unprepare" Access databases and I have used it together win an end-user sample that I am also shipping (this time it's a VB sample that I will port to C#) that does steps 2 to 4 and is supposed to act as a template for a custom solution.

All thoughts and suggestions are most welcome for this product.

Standalone device emulator

Good news: the standalone device emulator is here!

Synchronization stability

Data Port Sync is now undergoing a testing phase and although things are looking bright, I had overlooked one important detail: what happens when something fails?

There are four phases to the synchronization process: 1) preparation of the Access database; 2) exporting the Access database to the device in SDF format; 3) tracking changes on both ends and 4) merging the changes. When I designed the tracking code I assumed it would be okay to immediately mark the changes in the database, both in the user table and in the tracking table. As a matter of fact, this is a reasonable solution if you just want to track changed data, but it is not very safe if you need to process this information subsequently. If that process fails, you essentially lose the tracking information (at least with the way I was doing it).

To solve this issue, the data tracker now makes no change to the database. It generates a list of changed rows (for both databases) and the generation of this list is only affected by the posterior changes made to the database. The importance of this is that if the merge process fails, I can roll everything back and rerun the data tracker. All changes will be there.

Data Port Sync will become a product by the end of this month, before I go to MEDC Europe in Nice. Stay tuned.

SQL Mobile DateTime parameters

Looks like I have found another small issue with SQL Mobile. I found out about this after a customer reported not being able to run a parameterized INSERT command with a DataTime parameter through DesktopSqlCe. The OLE DB provider reports the DateTime value as having 8 bytes when it in fact has 16. The ADO .NET provider seems to work correctly.

Preparing for SQL Everywhere - II

After figuring out how to make SQL Mobile work on my XP PC (I have VS 2005 installed so the license works), I decided to port to the desktop the device component DLL I use in all my products. Most of the code (like 99% of it) was immediately reused, barring the occasional precompiler tweaks. The major challenge was not to change too much on the support code and this implied simulating a RAPI or TCP/IP connection and the corresponding data streams.

The solution I came to was quite simple: two asynchronous data buffers. The first is written to by the client code (dssce.dll) and read by the server (LocSqlCe.dll). The second data buffer is used in the exact reverse way.

When I finally managed to make the whole thing work I was amazed by how slow it was... The data streaming code was the culprit because it was chewing up too much CPU bandwidth in its own thread, especially while waiting. The solution? A criteriously inserted Sleep(0) on the reader thread.

The bottom line is that DesktopSqlCe users may now develop their applications against a local SQL Mobile database. Look Ma: no PDA!

Preparing for SQL Everywhere

Since Microsoft announced that SQL Mobile would run on all desktop platforms under the "SQL Everywhere" name, I have been wondering how easy it would be to set up my development PC in order to start testing the native OLE DB interfaces.

Well, it's easy enough. First, make sure you have Visual Studio 2005 installed (one of the versions that carries the SQL Mobile bits). Second, go to the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE directory and copy all the sqlce*.dll files to your C:\Windows\System32 directory. Third, register the sqlceoledb30.dll file using regsvr32.exe Finally, open the ssceoledb30.h file and copy the SQL Mobile definitions to a header file of their own.

After this very simple routine, I was able to quickly write a desktop C++ application to create an SDF file on my desktop using code borrowed from eVC3/4! You just need to include your new header file after atldbcli.h and you are done... I will give all the details in an upcoming article.

Ah, and don't forget: this only works on development machines with VS 2005 and Windows XP Tablet PC edition. These license limitations should be lifted when we get the Everywhere bits by the end of this calendar year.

SQL Server Everywhere Edition

Paul Flessner has just announced what many of us have been asking for: SQL Mobile on desktop PCs. Read all about it here.

Synchronizing multiple PDAs - success!

I write this post after my first successful synchronization of one Access database and two PDAs with SQL Mobile (an iPAQ 2210 and an i-mate K-Jam). The sync code now recognizes each client through a GUID value that is stored by the client PDA. IDENTITY space partitioning is working and all PDAs are generating non-conflicting negative IDENTITY values where the Access database generates positive ones. All of this can be configured by the user or consuming application.

My final hurdles are to implement conflict rules and constraint-directed updates. Right now, there is only one conflict rule: if both the PC and the PDA have updated the same row (as identified by a GUID), the PC wins. As for constraint-directed updates (this is a pompous term that means "insert, update and delete in foreign key order") I have already devised a means to calculate an "INSERT order", the order by which it should be safe to insert new rows without FK clashes. It so happens that it is the reverse order for DELETE.

Lots of tests ahead...

MEDC Europe 2006

I am going to MEDC Europe 2006 - are you? This is the place to be if you want to stay ahead on Windows Mobile technologies. As the banner says, register now for an early-bird rebate. See you in June!

Synchronizing multiple PDAs

So far, the Data Port Sync preview has already some synchronization capabilities. It will only work safely with one PDA and still has no collision handling code. When the same row is updated on both ends the PDA prevails, but this will change soon as collision-handling policies become available.

The day's work was spent on calculating INSERT order for tables (reverse of DELETE) so that database structure and constraints are not violated. Also, work is under way to support multiple PDAs synchronizing against the same database.

Hope that by the end of the week I will have more to write about.

DataPortSync pre-released

I finally managed to get the code to synchronize an Access database with a SQL Mobile one. There are still hundreds of little issues to solve like retrieving error information from the custom Access provider and making sure the IDENTITY values are correctly recorded. But it is working!

If you want to take a look at how the code is coming, download the latest version of DesktopSqlCe (1.3.200) and the DataPortSync pre-release 1.0.200. Be prepared for a bit of a rough ride!

Second step to Sync

Before synchronizing two databases, one must know what has changed in both of them. Getting to know what changed involves some exercise, especially when using two database engines that will not support any data tracking (at least with exposed APIs). Microsoft Access and SQL CE / Mobile fall in this category and require some work and data in order to track changes.

After figuring out a simple means of doing this, using additional tracking tables and columns on the tracked database, I wrote a new sample using the pre-release code of Data Port Sync and DesktopSqlCe (some minor errors were corrected meanwhile). After selecting an Access database, this sample prepares it (according to the user's selection of tables and columns) and exports it to the device. Preparation involves adding new tables to the database and new columns to the tracked tables.

After all is ready, you can start playing with both databases and the code will report what changed and in what table. Tracked rows are uniquely identified across both databases with a GUID value. I expect to upload the sample to the site very soon. Stay tuned.

First step to Sync

Today, I published the first sample for a new product - Data Port Sync. This is a .NET component that handles most of the chores required to synchronize a Microsoft Access database with either SQL CE 2.0 or SQL Mobile. It's ultimate purpose is to help developers build their own customized synchronization solutions and builds on three fundamental components:

1. A Microsoft Access data tracker - prepares a database for tracking and tracks changes made to the database. Tracking is achieved by adding some control tables and columns to the tracked tables.
2. SQL CE / Mobile data tracker - uses the same data tracking algorithms to track changes made to a mobile database.
3. Data transport - building on DesktopSqlCe, I'm adding some direct access features for Access databases (so that .NET developers don't have to bother with INSERT commands).

The challenge I'm facing now is to build a number of samples that will cover all the bases, from simple database export and import, to complex merging procedures. So, I'm spending most of my time writing a C# object model to wrap my C++ code, but then I'm starting to get used to it.

Here is the first sample: an Access to SQL CE 2.0 / SQL Mobile export tool. You will need to download the latest version of DesktopSqlCe (soon to be renamed).

Enjoy.

Another issue with BLOBs and SQL Mobile

I just received a kbAlertz with this interesting title:

An .sdf database file in SQL Server Mobile is larger than the same .sdf database file in SQL Server CE 2.0 when you use the ntext data type or the image data type

SQL Mobile is a rewrite, not an upgrade of the SQL CE 2.0 code, so one should expect some differences in behavior. I am collecting a list of these, both high and low-level and will publish them soon.

The Bookmarks and BLOBs Bug

I can now officially discuss this bug on SQL Mobile: you should be very careful when running a SQL command that returns a scrollable cursor and has BLOB columns in it.

Read more about this issue here.