开始部署时，因为我先测试sqlCE的，出现“无法找到PInvoke DLL“sqlceme35.dll””的错误，原因是因为在VS自动部署的时候没有将sqlceme35.dll部署到模拟器上面去，导致编译通过，但是运行出错。

在网上找了些解决方案，很多不能用，以下解决方案能行：http://blog.csdn.net/flyjimi/archive/2008/12/11/3500606.aspx原文地址是：http://blogs.msdn.com/sqlservercompact/archive/2007/10/26/can-t-find-p-invoke-dll-sqlcemenn-dll.aspx但是在解决方案中，没有写明白具体的操作方法，具体是哪三个CAB文件。然后我就到以下目录下

在这个目录下有很多个CAB，因为我用的是WM5的，所以关于WM5的我都拷贝到模拟器上去，将选中的文件拷贝到WM5上面，然后到WM上面执行一下，在执行这些文件的时候会出现“已经安装了之前的版本，需要重新安装的点击确定”。点击确定就好了。我的安装顺序是：从下往上依次安装。重新编译，部署，运行，sqlCE通过。

轮到sqlite了，还是按照原来一样将数据库拷贝的目录下面，这里数据库支持的类型暂时我知道是有“.DB”，“.DB3”.后来通过用UltraEdit打开sqlite的数据库发现里面有sqlite3的关键字，所以只要有这个关键字，后缀名不管用什么都是支持的。没有后缀名也是可以的。

还是按原来的一样。部署运行，出现了“无法找到PInvoke DLL 'sqlite.Interop.064.DLL'”原因当然也是VS部署的时候不会将这个部署上去。郁闷，没有先例的东西就是问题多。没办法，只有尝试。找到sqlite.net的安装目录下。我的是：D:"Program Files"sqlite.NET"bin"CompactFramework，在这个目录下面找到一个“sqlite.Interop.064.DLL”的文件，拷贝到模拟器上，发现还是不行，然后在同一目录下面找到

“sqlite.Interop.064.lib”这个文件。想想这两个么应该是一样的咯，然后也复制到模拟器上，这里注意，拷贝的路径是在跟应用程序同一目录下。当然会出现要不要覆盖的问题咯。点击覆盖。

编译，部署，运行。通过。非常欣慰！
后来装了个6.0的SDK，然后就部署到6.0的上面去了！
第二：一切编译通过，开始执行。


这张图是主界面，作为导航用的，主要的增删改操作，已经对字符串的支持，和日期类型的比较。
这里的日期类型的比较用了一个简单的sql语句：select * from t4 where Birthday>'2007-09-05'；这里稍微解释一下，我在数据库中设置这个日期为nvarchar
类型，而sqlite支持的是弱类型的，所以当我在界面中选择一个日期类型，然后存入数据库是不会出现任何问题的。也就是说我可以将日期类型直接存到类型为nvarchar的类型的字段中去。

这张图是用对数据库数据插入时，两个数据库的性能的比较。在这里我用到了插入5000条数据，上面的用时的单位是MS。当然这里只给出了一次的测试结果，经过多次的测试，测得sqlite插入5000条数据的用时在4500到5000左右，而sqlCE是在23000到25000左右。所以在性能能可以看出sqlite是sqlCE的4到5倍左右。当然这里我用到了事务，因为我在桌面程序上测试过，如果用事务比不用事务的性能要高出几十倍。最搞笑的时候我在桌面程序上测试插入10000条数据到sqlCE数据库，没有用到事务，我中午一觉睡醒还没插入完毕。可见这效率。

这个图是用来查询出t2,t3表中的数据量的，为了之后的联合查询做准备的。这里我在每个数据库中的t2,t3表中都插入了25000条数据。

这里用到了联合查询，语句很简单：select * from t2,t3 where t2.id=t3.id;非常简单。这里记录了一次的查询结果，经过多次测试，得出查询的效率sqlite比sqlCE的效率高出4到5倍。
总结：
无论在桌面程序上，还是在PDA上，sqlite的效率都比sqlCE高的多。所以在轻量级数据库的选择上，我们最好也尽量选择sqlite的数据库，而且是开源的。在测试的过程中发现，不管是哪个数据库，第一次的查询效率相对会比较低一些。