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...