In-Memory Database: Waypoint #1

I have narrowed my search for an  in-memory database to support unit testing down to SQLite (here and here) and SharpHSQL (here and here).  Both are open-source implementations of in-memory SQL databases.  SQLite is written in mostly C# (there is a smattering of straight C code) and SharpHSQL is written in 100% C#.  Both have some tweaks to handle the Pocket PC environment.  Both have the ability to save the contents of the in-memory database to disk and retrieve it later.  To my surprise, neither has a set of unit tests. 

As far as I can make out, both are aimed at the small embedded application space.  I have convinced myself that my needs are sufficiently different that I should create something new.  Both of the packages have a lot of what I want, so I am going to start with their code as a base.  I anticipate that I am going to make a lot of changes (e.g., add unit tests for one).   I am going to start with the SharpHSQL base because it seems less cluttered than SQLite.  I thought for about 30 seconds of converting to VB.NET but I have not done any serious coding in C# for a while and this seems to be a good time to practice. 

Here are some preliminary thoughts on the target architecture:

• I, of course, want to be able to handle the commands that come in as strings but I also want to be able to build what I am calling "command blocks" that have a true object structure.  The command blocks provide support for populating the schema and the database from an existing database and for the database setup/teardown for individual tests.  That means that I will have to decouple the string parsing at least to the extent that the command execution will accept strings (to be parsed to create internal command blocks) and command blocks (to be executed).
• I want to create someway to build up a database that I can re-use for a set of related tests.  That is, create the base, clone it for each test, run the test against the clone, examine it for the assertions, and discard the clone.
• I will need to decouple a lot of the classes so that I can do an adequate job of unit testing.  There is not much point in building a package to support unit testing that is not unit tested.