Well... let me see if I can shed some light here.

First off, MSDE *is* SQL Server. Therefore, when deciding to use MSDE, you really need to put it in the context of why you use SQL Server in the first place. Areas like replication, security, handling large data sets, transaction logging, need for C/S all come to mind. DBF's have pros and cons. On the pro-side, they are easy to implement. Keep in mind it's the VFP engine, not the DBF's that have superior performance. Then again, can you always say that DBF's outperform SQL-Server? I don't think so. Try accessing DBF's with large data sets over a WAN sometime. The slowest thing that VFP does is open and close data. VFP, being a file-server based environment operates in a completely different manner than a C/S based platform like SQL-Server.

Perhaps you want to implement stored procedures. Can you do this with VFP Data? In a VFP environment, yes. But, what if you need to expose your data to other clients? Then you begin to run into problems. Sure, you can go to SQL-Server. But, what if you have an environment were mobile clients exist? Sure, you can use DBF's. However, you will need to bridge the gap between DBF's and the SQL-Server. They are two completely different animals. And, that difference needs to be reconciled.

Once again, the advantage here or the DBF format is its portability. It takes nothing to implement DBF's on a laptop. Think of MSDE has the best of both worlds. The portability of DBF's combined with the power of SQL-Server. DBF's can be distributed royalty free and so too can MSDE.

Finally, I just want to comment again on the performance issue. The fact is, the DBF does not always out-perform SQL-Server. Often, it can. But, there are serious scaleabilty issues with DBF's. Also, DBF's are not secure. Often, if you pitch a solution and you make a pitch for using DBF's, you will encounter laughter and will be escorted to the door. With MSDE, there is a new alternative.



<<
I just can't see the sense in scaling up from MSDE when I can scale up from DBFs. Besides, no matter what anyone says, the good ole DBF format still whips the hell out of SQL Server in terms of performance.

So, John K - I agree with you. JVP - I fail to see your point.
<<