::go a step beyond an make it work at least with an MSDE back-end

Why even fiddle with MSDE at all? A well-written VFP Data Server (VFPDS) will far outperform MSDE in all situations -- including code maintenance and updates. In fact, I was thinking about extending your idea to run as a service, just as MSDE/SQLS each do.



::if your usage gets too many hits, you'll have to scale to SQL Server, but you'd be in troubles as well with VFP

How so? VFPDS accepts an incoming connection request, hands it off to a new connection handle, and sets back to listening for the next one. Surely we're talking about a matter of only a few milliseconds here. Yes, as far as raw data capacity, we're subject to standard VFP limitations -- but those can be overcome as well, as we saw with the 132GB Chunnel application.



::It's more robust.

My first guess, if I'm understanding correctly what you mean by "robust," is that the reason for that is because MSDE/SQLS are running as services and therefore can handle a high volume of hits.

Data reliability? Build an internal mirrored table setup, with self-repairing capabilities. Two mirrors not enough? Build three.



::From the service consumer perspective, it's exactly the same thing. The service interface would be exactly the same.

That's what I like about it :)



::You can write Stored Procedures in VFP, but the power is definitively NOT the same.

Oops, I guess I got lost. Can't we create a SP in our VFPDS client, upload it, and call it just like we do in MSDE/SQLS?



::Anyway, yes, VFP alone will do it good in lots of situations

Gosh, call me silly, but I just can't see the need for anything else <g>