One of the biggest challenges I have been having is keeping the checked in db in line with the version of the db under my bin folder.  Like with Parent Usage, I had tried to keep it updated, but screwed it up.

I have also been trying to keep the SQL Script up to date as I go. 

So one thing I would like to do is

1. Get the SQL script all up to date
2. Have cruise control generate the database
3. Run an expanded set of unit tests against this generated database.

I think that might catch some of these types of problems faster.

Does this sound possible?

Maybe we could consider writing some C# code which regenerates the DB for now upon startup; this would give us the benefits of source control, much better merging, etc. Basically there'd be the DROP/CREATE TABLE commands and a sequence of INSERT statements in a C# file that would be easier to manage at this point than trying to deal with the crappy SQLite manager programs.  Maybe that'd be easier for various developers, regardless of their SQL experience, to work with for now.  Also the recurring "File Not Found" issues would go away for now so new users would be less likely to hit such a roadblock.

Some time nearer to v1.0 we'd likely want some other process here, but I'm not sure what that is yet. I did run into what claimed it was a DB Version Control software but after reading deeper, it didn't end up doing anything at all what such a theoretical thing should do; no rollbacks/merging/diffing/etc.

This is called Migrations in the Ruby world. I remember seeing something like "Rik Migrations" a while back. I believe that there at least a couple frameworks for .NET Migration operations. I'll see what I can dig up.

Here's a roundup of the currently available Migration frameworks:

http://flux88.com/blog/net-database-migration-tool-roundup/

I'm of the mind that simpler is better. Running a sql script looks simpler to me. Lets just try that for now.