>We are looking for a solution that allows us to maintain the affordability of >our package. We don't want to buy SQL Server license(s) and our smaller >clients don't want to either.

Your only choice then is MSDE for the small clients and SQL for the big ones (or those willing to pay for the licenses). Unless you want to use Access.

>The clients don't want the MSDE part of SQL Server, nor do we,

Why not? It's free, it works, and it gives you a clear upgrade path to a large database when needed.

>and we need a local database because our package is designed to run in the >field off a network.

You said you can't use VFP (or dbf's) because of your client's concerns... you have to go to a client/server layout.

>We would like to stay with the front and middle tier bing VFP if we can do it, >but it has to be something that we can manage with 4 developers.

Either you are or you aren't... you said your client's didn't want VFP. Well if you have to move to something else, you have to.

>Our .exe is already over 25MB.

I can't see where that makes any difference...

>We are looking to breaking that into dlls and that may move us away from Fox >in part. It is a question we as the developers will answer over the next one >to two months before design work starts.

I would say that you are looking at this from a VC view only... VFP can create dll's quite easily, and using VFP as your middle-tier should allow you to reuse code you already have in your application.

I think you need to really get together as a group and determine the road you want to travel... from the posts here, I would say that you are still not sure what you want/need to do. Your clients are saying no VFP, but you are looking at Codebase to access free tables - well, that is still VFP. To me, your path is obvious - MSDE, SQL as the backend - VFP as the middle - anything as the presentation. That will address your client's concerns of scalability, and remove the DBF's from the server.