Tuesday, December 27, 2005
When Microsoft shipped SQL Mobile, we got a new header file to include in our applications: ssceoledb30.h. Unfortunately, this means that you cannot have both the old include file and the new include file on the same exe. You can use the preprocessor to include either one, but this is not what I was looking for: I wanted an integrated solution that would allow me to consume any database (2.0 or 3.0) from the very same exe.
The solution is to merge both header files into just one. While I wait for Microsoft to tell me if I can publish the one I wrote (due to copyright issues, of course) you can have a go at it yourself by diff'ing the two files and figuring out the differences. Not many, actually.
Friday, December 23, 2005
Monday, December 05, 2005
Friday, December 02, 2005
Wednesday, November 30, 2005
Thursday, November 24, 2005
Wednesday, November 23, 2005
Tuesday, November 22, 2005
Step by Step: Introduction to the New Native APIs in Windows Mobile
Device Debugging and Emulation in Visual Studio 2005
Using Visual Studio 2005 to Design User Interfaces and Data for Device Applications
Saturday, November 19, 2005
Sunday, November 13, 2005
Friday, November 11, 2005
Setting this registry key corresponds to the following provisioning script:
<parm name="4097" value="1">
Read all about this at its original source.
Thursday, November 10, 2005
In one of the recesses, I was approached by one of my customers complaining about DesktopSqlCe performance when inserting data in bulk. After comparing the insertion performance of Data Port Wizard, DekstopSqlCe was an order of magnitude slower...
My customer's code also needed to be optimized, but that was not the root of the problem. It was in my code. How could that be if both products share most of the base code? On one hand DPW was blasting 11,000 rows in less than 30 seconds over RAPI, while DesktopSqlCe was performing in the tens of minutes range. But wait, I thought, I've seen this before.
When DPW was being developed, I soon realized that synchronous messaging was very slow over RAPI. If after inserting a row in a table (even if the cursor remains open) and you wait for the device to send an acknowledgement message, then you are going to be very slow. So slow as to justify the tens of minutes scenario.
To solve this, DPW uses an asynchronous method of communicating and that is why it does not stop when it finds an error - all errors are reported at the end and are collected asynchronously. This is fast, very fast indeed.
When I wrote DesktopSqlCe I wrongly assumed that my customers would make occasional and rare direct table inserts and updates, so inserts and updates were being delivered in a synchronous fashion, i.e. waiting for a confirmation after insertion or update. This situation is now solved by adding a new attribute to the SqlCeRowset class (similar to the CF 2.0 new SqlCeResultSet class): ReportError. This attribute is of type SqlCeReportError and has two values: Sync (default) and Async. Now you know why.
Saturday, October 29, 2005
Friday, October 28, 2005
Just to remind everyone of the Tools support matrix. Actually, this is a funny way of bookmarking this page, huh?
It reminds us that we have to keep all tools under our belt, from eVC3 to VS 2005 (if we are targetting all sorts of devices, that is...).
Waiter! Another Pilsener, please!
Saturday, October 22, 2005
Most databases that use IDENTITY columns will do so for primary key or index support, meaning that these values are generally laid out in row creation order. For a table with few deletions, it is very likely that you can find large continuous ranges for which you can let the IDENTITY column do its job - generate the next value.
I write this after finishing my first tests on Data Port Wizard and a new version of the device component. For "well behaved" databases such as the Northwind sample, the code only needs to change the IDENTITY seed twice per table and performance does not seem to be an issue. On databases with sparse tables (where the number of gaps in IDENTITY values is large) performance may be a concern because the base table cursor must be closed before the seed is changed, and reopen again to continue data insertion.
Friday, October 21, 2005
From: Windows Mobile Update
Subject: ActiveSync 4.0 Issue Alert
Microsoft wants to alert you to an issue regarding ActiveSync 4.0 and the immediate steps the company is taking to resolve it and meet customer needs.
Specifically, some users of ActiveSync® 4.0 have reported challenges when using the USB connection of their personal computer to connect to a device with Windows Mobile 5.0. In many cases, these challenges are likely caused by interoperability with desktop firewall applications or applications that manage network traffic. These applications appear to conflict with the TCP traffic between a device and the PC.
An update for ActiveSync is scheduled to be available in late November, but customers may also resolve the issue manually immediately by visiting visiting http://www.microsoft.com/windowsmobile.
This issue only affects people with new devices just coming to market and running Windows Mobile 5.0 software, and only when synchronizing directly to a PC (wireless synchronization via Bluetooth, infra-red or directly to a server or other services are not affected).
- In the U.S., these devices include the Sprint PPC-6700, iMate JasJar, iMate KJam, iMate SP5, Dell Axim X51v,HP iPAQ rx1955 Pocket PC, HP iPAQ hx2495 Pocket PC, and the HP hx2795 Pocket PC.
- In Europe, these devices include the Orange SPV M5000, iMate JasJar, iMate K-Jam, T-Mobile Vario, T-Mobile MDA Pro, O2 XDA Exec, O2 XDA Mini S, O2 XDA Phone, FSC Pocket LOOX N500, Dell Axim X51, Dell Axim X51v, HP PPC series (rx1950, hx2190, hx2490, hx2790).
- In Asia, the devices affected are the iMate JasJar, iMate KJam, iMate SP5 and iMate SP5m.
Microsoft is committed to solving this issue for its customers and its partners.
For more information, please contact the Windows Mobile PR team at 425.452.5400 or email@example.com.
Sunday, October 16, 2005
The answer? OLE DB, of course!
Saturday, October 15, 2005
Now let's wait for some good news on the IDENTITY column issue.
Wednesday, October 12, 2005
SQL CE 2.0 allowed consumers to write on IDENTITY columns, a feature that enables copying desktop databases. The table is created on the device with the IDENTITY column set at the given seed and increment. When copying the table data, the column values are forced (the OLE DB provider complains mildly) and the resulting table behaves exactly like the source one. Interestingly, both Jet and SQL Server allow this so why wouldn't SQL Mobile allow it as well?
Monday, October 10, 2005
Note: If you are developing against SQL Mobile, you might want to install the error messages DLL - sqlceer30EN.dll.
Sunday, October 09, 2005
First, the whole project was ported from eVC3 to eVC4. This was not a strict requirement, but since I was targeting a Pocket PC 2003 device I decided to do so. The result was interesting because I ended up dropping some dead code that still hangs around on the SQL CE 2.0 version... Now I have a smaller DLL (87 KB).
When porting to eVC4, I had to drop Giuseppe Govi's STL port and use the one that ships with the Pocket PC 2003 SDK. Apparently the old STL code will create a number of compile-time conflicts with the XML headers...
After changing a few constants and applying the small correction I mentioned on my last post, the code started to work - in less than one hour (most of this time was spent with the eVC3 to eVC4 migration).
The SQL Mobile component can be downloded from here. Please note that this will retain a Beta status while SQL Mobile is also a Beta product. To install it, just copy it to your device's \Windows directory and you are done.
Saturday, October 08, 2005
Bookmarks are now unsigned integers (DBTYPE_UI4) when they were integers in SQL CE 2.0.
Another interesting difference occurs when you open a table with an index. With SQL CE 2.0, using an empty string for the index name would be interpreted as no index selection. No so with SQL Mobile - an empty string seems to be a valid index name and the table will refuse to open. Here's some code I had to change in my previously published CIndexTable class template (in bold):
if(szIndexName && wcslen(szIndexName))
idIndex.eKind = DBKIND_NAME;
idIndex.uName.pwszName = (LPOLESTR)T2COLE(szIndexName);
pIndex = &idIndex;
I am testing the whole code against SQL Mobile and will post my findings as they come up.
Tuesday, October 04, 2005
Jet lag was one of my biggest problems. It was so big that when I met Alex Feinman, I thought I was talking to Andy Wigley and complimented him on his book... Foot: meet mouth! (Sorry Alex!)
Tuesday, September 27, 2005
Sunday, September 25, 2005
My first approach to consuming RAPI was quite simple: a static link to rapi.lib. This meant that all the products were tied to a particular version of ActiveSync and would not run in another. By linking to a specific version's lib file we are actually precluding the possibility of linking to other versions, both older or newer.
It so happens that util recently all applciations were statically linked to ActiveSync 3.8, meaning that you had to install this particular version in order for the applications to run. Incidentally, I got a request from two different customers, one asking for ActiveSync 4.0 support, and the other was asking for version 3.6 support. Now what?
Publishing different versions of the applications was obviously out of the question. There had to be a better way of supporting mutiple versions of RAPI. Then I recalled something I read in one of Doug Boling's books: use dynamic linking. The idea is to dynamically load the RAPI.DLL file and retrieve the entry points to the functions you need by using GetProcAddress. To make things easier, I wrote a very simple helper class, of which I'm highlighting a few snippets.
First, the class declaration:
HRESULT InitEx(RAPIINIT* pRapiInit);
HRESULT Invoke(LPCWSTR pszDLL,
I'm only including a few methods to illustrate the technique. You should be able to extend your own version with the calls you need.
Let's look at the constructor and destructor:
m_hDll = LoadLibrary(_T("RAPI.DLL"));
As you can see, we dynamically load and unload the RAPI.DLL on the constructor and destructor. You should have no problems in nesting these - you will only be incrementing or decrementing the module load count. Now, let's see how to implement one of the methods:
typedef HRESULT (__stdcall *CERAPIINITEX)(RAPIINIT*);
HRESULT CRemoteAPI::InitEx(RAPIINIT *pRapiInit)
HRESULT hr = E_NOTIMPL;
hr = pfnCeRapiInitEx(pRapiInit);
You now get the idea on how to implement all other methods. The beauty of this is that by using this approach, you can support all versions of ActiveSync (provided that the target version does implement the function call you need...).
Thursday, September 22, 2005
I'm still recovering from the shock of realizing that all desktop code was being linked to the sinlge threaded versions of the runtime libraries. At least two threads are used in all products (DPW uses more) so you may now understand why some of my users were getting random memory addressing crashes...
Wednesday, September 21, 2005
This explains why RemSqlCe.dll leaks memory (arrgggh!). Now, I have to roll up my sleeves and produce new releases of all my products...
Wednesday, September 14, 2005
P.S.: The new version is now 1.0.30.
Monday, September 12, 2005
Monday, September 05, 2005
There are two different kinds of SQL commands: the ones that return something and the ones that return nothing. The first class of commands are the classical SELECT commands - they always return something, even if it's only a single row count. On the other hand INSERT, UPDATE and DELETE commands (as well as all the DDL commands) do not return rows for you to process.
Making this distinction is very important when you use CCommand: what accessor and rowset types will you use? All non-SELECT commands typically use a CDynamicAccessor and a CRowset where all others may get away with CNoAccessor and CNoRowset. This means that you need to know what kind of SQL command to execute before instantiating the proper template parameters in CCommand. This is a nuisance when running generic SQL commands. Why?
Let's look at the code in CCommand::Open. Somewhere near the bottom of the method, you can see (ATL 3):
if( bBind &
This is bad. By default, bBind is true (default function parameter) but the HasOutputColumns function is defined by the accessor class you provide as a template parameter for CCommand. Gotcha - you need to now if the command returns rows before instantiating CCommand. So how do you go around this? How do you run generic SQL commands without having errors thrown at you, no matter what accessor you use?
Easy. Just change the last code snippet so it reads:
if (bBind && GetInterface() != NULL)
Now all commands will run without having assertions thrown at your face. To see if you actually have an accessor and a rowset, just test GetInterface(). If it's NULL then your command returned nothing.
Thursday, September 01, 2005
One guy, though, kept it cool. In his note on Pocket PC Thoughts, Ed Hansberry said:
I am sure someone will fine a practical application for this, but for now, it falls under the W?BIC category.
Actually we started this stunt with a challenge from César. Why don't we try and connect?
Ed has a good point. The practical implications of this are still a bit limited by the technology. On one hand, the client must know the IP address of the server PDA. This will change very often due to the connection methods available. Not everybody will be able to have a fixed IP address to use on the PDA. So one may wonder if the a half-a-world-away scenario is feasible, but on a WiFi scenario this may actually happen.
On the other hand, while the server is actually busy serving data, the PDA user cannot edit his data. This is obviously a limitation of the current SQL CE 2.0 engine that will be lifted with SQL Mobile. When it becomes mainstream, one may see real-world applications of this technology, where the backoffice accesses the mobile database to update it while the user continues to work.
So that's right, Ed: Why did we do it? Because we could, and was a lot of fun! ;)
Tuesday, August 30, 2005
I don't know how, but he did manage to get his PDA connected to the Internet with a fixed IP address, which is all that my Pocket PC server software needs to start serving a remote client. On my end, I used SQL CE Console to edit his data. We were using ADSL on both ends, which means that our real bandwidth was limited by the upload bandwith which is typically 128K.
It took us some time to get the connection settings right (especially with César because the server PDA was on his end), but we finally managed to make it work. I could successfully connect to César's PDA, open the Northwind database, insert some new records, and disconnect without a hitch. No data were lost.
A simpler site was in order and, not being an HTML geek, I turned to FogCreek's CityDesk to help me in publishing content on the site. Interestingly, I'm using it exclusively to manage the entire site. A final note: it took me one day to rewrite the whole site. Not bad, huh?
Check the new lean and mean Primeworks website.
Thursday, August 25, 2005
Such was the case when I started to implement SqlCeDataReader.GetSchemaTable. This one was a bitch to do. One of the best clues I actually got from the MSDN documentation:
The GetSchemaTable method maps to the OLE DB IColumnsRowset::GetColumnsRowset method (...)
It's not enough, but it's a big step forward. After implementing this using the Consumer Templates, I deceided to write a small article on this subject:
Using IColumnsRowset with the ATL OLE DB Consumer Templates
Friday, August 19, 2005
You might already have read this on the MSDN help page for SqlCeCommand.Prepare. Have you ever wondered why you need to set the size of variable-length data types before preparing the command? The answer is easy: you cannot use a BLOB in a parameter. I have a strong belief that this is not necessarily so but, at most, you could use one BLOB type as a parameter.
This happens due to a limitation of SQL CE 2.0 and of OLE DB. As you may know, SQL CE 2.0 can only handle one storage object at a time. Storage objects such as ISequentialStream are used to copy BLOB data between the provider and the consumer. One of the workarounds for this is to use more than one accessor handle per row. I described this in two articles:
Managing Blobs Using the ATL OLE DB Consumer Templates
Inserting non-nullable BLOB data in SQL CE using the OLE DB Consumer Templates
This solution breaks down with the current OLE DB implementation. As it stands, ICommand::Execute only takes one accessor handle for all parameters in the DBPARAMS structure. So this means no BLOB command parameters.
The workaround Microsoft devised is actually the only one possible - preset the parameter size before preparing the command.
Monday, August 15, 2005
Thursday, August 11, 2005
Friday, August 05, 2005
It fails. Yes, it fails. Works wonderfully when one assumes that BLOB columns are meant to be nullable (i.e., to accept null values). And then suddenly here comes a customer who thinks otherwise. He likes his NTEXT columns NOT NULL. Gosh: the whole thing crumbled.
If you are using my ATL OLE DB C++ code, heed these words of advice, so you can merrily trod in the garden of arcane delights.
By the way, DCD rocks (or rocked)...
Thursday, August 04, 2005
Another subtle bug has also been corrected: importing empty NTEXT fields into SQL Server. Apparently the SQL Server provider does not like to be given an empty stream object - you must really pass a NULL pointer as the parameter value.
Wednesday, August 03, 2005
Tuesday, August 02, 2005
Sunday, July 31, 2005
Sunday, June 26, 2005
Wednesday, June 22, 2005
SQL commands (SqlCeCmd objects) may be executed either as queries (when they return a SqlCeRowset object) or as simple commands with no data returned (only status info). Interestingly, version 1.0.17 is incorrectly reporting an out of memory condition after a non-query SQL command is executed. Brilliant. So how useful is a tool like SCC when you cannot even create a table???
The version 1.0.18 is out now, with my apologies.
Friday, June 17, 2005
Too bad we don't get all the code-generation support that eVC has for MFC, but I'm getting over it pretty fast.
Monday, June 13, 2005
Thursday, June 09, 2005
Friday, June 03, 2005
Wednesday, June 01, 2005
Monday, May 30, 2005
The CEDB code implements a record containing a collection of properties. Each property maps to a CEPROPVAL structure directly, meaning that the contained value is accessed through bit conversion methods. This is pretty stupid. My early reasoning was that this would make it so much easier to read and write the binary info to and from the database.
When I tried to fill a DataTable object using this approach, I was surprised with the poor speed. At first I blamed the DataGrid but realised that, although it is a slow loader, the bulk of the time was being spent loading the DataTable. I turned my attention to the DataTable and applied all the tricks of the trade to make it load faster. Nah... no way.
But wait! Could it be...? Was it in my code to load the records? Like Michael Abrash used to say: "Assume nothing: Test everything".
Bingo! As any Scorpio worth his salt, I rewrote the whole thing. Upon loading, the record now converts all its properties to boxed values or string references (blobs are just byte arrays, but references as well). These are all packed into an object array which makes it a breeze to load into a DataRow. Buffers are reused to avoid heap fragmentation and the undesirable visit of our friend the garbage collector.
The Suppliers table of the converted Northwind database now gets loaded into a brand-new DataTable object in under 200 ticks on my iPAQ 3850 (I cannot get enough of this machine...), down from almost 600 ticks using the old code. Impressive, huh?
Tuesday, May 24, 2005
Before you deploy the project to the device, make sure that the fssce.dll file is copied to either the target project folder or to the \Windows folder.
Functionality is now limited to browsing the database structure and to renaming tables, something that seems to be deprecated on SQL Mobile. By the way - what does "deprecated" mean? I'm feeling linguistically challenged here: does it mean that the feature is not supported or that it is supported but should not be used? Comments are welcome.
Monday, May 23, 2005
Friday, May 20, 2005
Uninstalling calls for a different approach. First, you have to make sure that the DLL is not being used by the SMS-handling process. My answer to this is to shut down the tmail.exe process. Here is some code:
BOOL KillProcess(LPCTSTR pszProcName)
BOOL bRet = FALSE;
hSnapshot = CreateToolhelp32Snapshot(
if((int)hSnapshot != -1)
DWORD dwID = 0;
pe.dwSize = sizeof(PROCESSENTRY32);
for(bOk = Process32First(hSnapshot, &pe);
bOk = Process32Next(hSnapshot, &pe))
dwID = pe.th32ProcessID;
if(dwID != 0)
// Kill the process
hProcess = OpenProcess(0, FALSE, dwID);
if(hProcess != INVALID_HANDLE_VALUE)
bRet = TerminateProcess(hProcess, 0);
After killing the process, you have to unregister the DLL (sample code here) and finally soft-reset the device.
A sample setup dll project is available on demand.
Tuesday, May 17, 2005
Monday, May 16, 2005
This project shows how the Data Port Component must be used from VB6 and uses new code (the dplib.dll is now on version 1.1.25) that is not yet compatible with the published C# wrapper. The C# wrapper will be updated to comply with the changes and will also be published with the source code (it's a very thin wrapper, really).
To make things work reliably, you should put the dplib.dll in the search path or you risk getting a run-time error from VB...
Sunday, May 15, 2005
Check out the "Recent Updates" list next to the May 2005 entry: they're about Windows Mobile 5.
Saturday, May 14, 2005
Friday, May 13, 2005
Wednesday, May 11, 2005
There is also another one, also by Nisham, on Migrating Microsoft eMbedded Visual C++ Projects to Visual Studio 2005 where he discusses the Upgrade Wizard and other issues.
At first it seemed quite straightforward. First, I had to change all __cdecl exported functions to __stdcall. The need for the second change was very hard to detect. The supporting DLL was designed to either be P/Invoked from .NET or to be directly consumed by a C++ application. This meant shielding all database-related functions with COM initialization code. This also meant exit exceptions when the DLL was consumed by VB6, either on the IDE or on the standalone runtime. After discovering this, there was the threading issue. Apparently one cannot safely call back into VB6 from an external thread, something that is safe in C++ and even on the .NET framework (that is how the C# sample works). The final solution is to start a timer to poll the import or export progress data. A kludge, but it works.
The nice thing about the whole process is that I had to instrument the whole code just to make sure there were no memory leaks or invalid pointers. A typical case of spring cleaning...
Monday, May 09, 2005
Friday, May 06, 2005
To use this functionality in your applications, use the following code:
BOOL NLedGetDeviceInfo(INT nID, PVOID pOutput);
BOOL NLedSetDevice(INT nID, PVOID pOutput);
void SetLedStatus(int wLed, int wStatus)
nsi.LedNum = (INT) wLed;
nsi.OffOnBlink = (INT) wStatus;
Wednesday, May 04, 2005
Sunday, May 01, 2005
Meanwhile, I published a small QA on Pocket PC Developer Network based on a year-old piece of code that shows you how to turn on the WiFi radio on a Dell Axim X30. There was some detective work involved in writing this one, especially using Remote Spy++. Fun stuff!
Friday, April 29, 2005
- ProcName - Procedure name
- SQLText - SQL command
This table is generally empty (I've never seen an instance where it wasn't).
Now, let's look at column types. We cannot confuse CEDB column types with Pocket Access column types. CEDB types are limited to (C/C++):
#define CEVT_I2 2 // short
#define CEVT_UI2 18 // unsigned short
#define CEVT_I4 3 // int
#define CEVT_UI4 19 // unsigned int
#define CEVT_FILETIME 64 // FILETIME
#define CEVT_LPWSTR 31 // LPWSTR
#define CEVT_BLOB 65 // BYTE*
#define CEVT_BOOL 11 // BOOL
#define CEVT_R8 5 // double
I defined these in C# for my previous article as:
public enum CeDbType : ushort
Int16 = 2,
UInt16 = 18,
Int32 = 3,
UInt32 = 19,
FileTime = 64,
String = 31,
Blob = 65,
Bool = 11,
Double = 5
Pocket Access types resemble SQL types and are more varied. From the online documentation found on the Windows CE SDKs, we can derive the following C# enum:
public enum SqlDataType : short
Unknown = 0,
Char = 1,
Numeric = 2,
Decimal = 3,
Integer = 4,
Smallint = 5,
Float = 6,
Real = 7,
Double = 8,
DateTime = 9,
Time = 10,
TimeStamp = 11,
VarChar = 12,
LongVarChar = -1,
Binary = -2,
VarBinary = -3,
LongVarBinary = -4,
BigInt = -5,
TinyInt = -6,
Bit = -7
Monday, April 25, 2005
- MSysFields - Contains all the columns of all tables in the database, including the columns of the system tables.
- MSysTables - Contains all the tables in the database, including the system tables themselves.
- MSysIndexes - User indexes are all declared here.
- MSysProcs - Stored procedures?
An empty Pocket Access database has all four tables created and the first two have some information: the system metadata. System tables are all created as type 3 (see below) and none contains a sort order with the exception of MSysFileds which has a sort order (type 0 - undocumented) on column zero.
To create a Pocket Access database, we must create all system tables an fill them with their default values. This process must be done in a very specific order: 1 - Mount a new CEDB volume; 2 - Create the databases and store their OIDs (the preferred order of creation is MSysFields, MSysTables, MSysIndexes, MSysProcs); 3 - Fill the MSysFields database; 4 - Fill the MSysTables database.
Each record on the MSysFields database has 5 columns (names taken from MSysFields itself):
- TableID - (int) Table OID
- FieldName - (string) Field name
- FieldID - (int) Field property id
- Len - (short) Field length
- ODBCType - (short) Data type
The MSysTables table contains only 3 columns:
- TableName - (string) Table name
- TableID - (int) Table OID
- TableFlags - (int) Table flags (system tables = 3, user = 0)
MSysIndexes has the following columns:
- TableID - (int) Table OID
- IndexName - (string) Index name
- FieldID - (int) Field property id
- IndexFlags - (int) CEDB sort order flags
Sunday, April 24, 2005
Friday, April 22, 2005
Common CE database questions
More CE database Q&A
My own experience, from C++ of course, tells me that is is possible not only to access but even to create a Pocket Access database without using ADOCE at all. As a matter of fact, as as Sue Loh explains, Pocket Access cdb databases are CEDB databases with a special format. They have metadata tables with a predefined format and support more types than CEDB does natively. Once you know this format and how to manipulate it there is no difference from approaching the database from ADOCE or from CEDB, with the exception of SQL. The SQL processor exists only on the ADOCE stack, so accessing these databases from the CEDB API means you don't have SQL to play with...
Wednesday, April 20, 2005
Tuesday, April 19, 2005
Friday, April 15, 2005
Wednesday, April 13, 2005
Tuesday, April 12, 2005
Then I tried filling in a DataTable. The early results were also stunning: managed code was faster. Can't be, can it? After revising and tweaking the code I noticed that the less you P/Invoke, the better performance you get. After a full morning of tweaks I got the better of it and now I can (grimly) smile after squeezing a 15% improvement. Hey, native is faster.
But then I noticed how some SQL CE features are missing altogether, like schema management. How do you rename a table? How do you rename a column? How do you check if a column is marked as IDENTITY? Well, there may be some room for another data access layer after all. Enter FastSqlCe. Enter? Hum. It's not ready yet, sorry. But you can take an early look at it here: FastSqlCe online documentation. Comments and suggestions are welcome. I will post an early sample as soon as it is ready.