Hi, Jeff.
>
::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.
Not in all cases. Yes, VFP is very fast, but for some complex SQL operations, the SQL optimizer is a lot smarter than VFPs.
>
>
::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.
SQL Server architecture fits perfectly well into COM+ architecture, much better than VFP. Again, the difference can't be terrible in small cases, not too complex scenarios. And this has nothing to do with tables or database size. It has to do with the conection pooling, memory allocation, etc.
>
>
::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.
Well, that's why SQL Server is more robust. You don't need to do any internal mirroring. SQL transactions are absolutely reliable. Of course, disk can crash, network problems *can* lead to some corruption problem, but the potential problems with DBFs/DBCs are in a total different scale.
>
>
::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 :)
Me too...
>
>
::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?
VFP SPs are a totally different animal. They are actually database-centralized functions that can return simple values. You can build a lot of logic in SQL Server SPs, and then return one or several resultsets (cursors in VFP parlance).
>
::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>
No, you're perfectly fine in your case, maybe, but once you actually know all that MSDE/SQL can do (for example, after one of Jim Duffy's great sessions), you discover why many of us are using it as our preferred back-end, no matter the project size.
See you,
