I was looking for answers to my sql/e question today (still nothing) and found the team blog for the sql/e team. One cool bit I found there was the "|DataDirectory|" syntax (scroll down a bit) for specifying the location of your data file. I don't know how (if?) I would have ever found that in the documentation. MSDN Blogs rule.

 

I mentioned recently that I am trying to use SQL/E as an embedded database for unit testing my applications. Aside from the less than I was hoping for performance boost, I have so far only run into one problem, detailed in the below newsgroup post. Basically, it seems as if there is a limit to the number of parameters you can add to a query with sql/e.

If I find out that this isn't the problem, though, this will be the most extensive test I've done yet. This is a huge database, and I am trying to build up then modify a 30 day snapshot of just the data that I need - easily several GB -  so I can verify that my application draws the right conclusions and shows the right answers from data designed to hit all edge cases.

I am noticing more and more interest building in using embedded databases, not just for testing purposes, such as this post. I kind of hope this becomes a trend, because there are a lot of great applications for embedded databases, where most developers would be stuck in the mindset of having to use a database as a remote service.

Link to Limit on # SqlCeParameters in a SqlCeCommand in sqlserver.ce

 

I mentioned in a previous post that I was going to investigate using SQL Server Everywhere edition for a database to unit test against, when the database really can't be removed from the picture.

Since then I have been swamped with work, and have not had time to post.

I did end up using SQL Everywhere for unit tests on a project. I had to copy-past-edit some code from the NHibernate Sql2000 family of driver classes, but it was pretty easy and I only had to open the sqle documentation once (...to find out that they don't support TOP.)

I will try to post more details later, but it was basically the same as my previous post on SQLite - I didn't notice any performance differences, nor does it support lots of functionality that SQLite doesn't, but it is SQL Server's little brother and it can replicate with SQL Server (very exciting!), which is a feature I plan on using for something else soon.

Anyway, just wanted to post something...

 

A short description of how I use SQLite to do unit tests that want data access.
 

Yesterday afternoon, I was talking with one of my co-workers, Michael. I was yammering on about how much I liked SQLite for unit testing and how much faster in-process databases engines were for applications that didn't need all the features of relational databases.

Then he mentioned SQL Server Everywhere Edition. It's in process, light weight (the same configuration as what runs on Windows Mobile), and free to distribute. I don't think it supports views or stored procs (installing it now, so I might edit this later) but I avoid those types of database dependencies anyway.

SQL Server Everywhere Edition sounds exciting for a number of reasons.