On the whole, I would agree that each tool has its place. You are right, it is not a DBF vs. MSDE issue. That is why I would refrain from making it an either/or situation. Then again, there is nothing wrong with outlining the strengths/weaknesses of each.


>>Finally, 80% of the work you do with data should be in a disconnected manner. There are only 4 instances where you need to be connected to the backend data source:
>>
>>Updates
>>Deletes
>>Inserts
>>Queries
>>
>>Therefore, if you have 20 or so folks, you may find that at no time, do you have more than 5-8 connections.
>
>Good point. This would be good for small workgroups which require much of what SQL-Server has to offer.
>
>>And yes, MSDE would make for a great prototyping tool. Then again, if you are prototyping with it, would'nt that mean that your implementation will be SQL-Server? That would make the whole DBF vs. MSDE argument moot.
>
>No. It would mean that I was developing for enterprise SQL-Server in the first place. It has nothing to do with DBFs vs. MSDE.
>
>I think that you would agree that the MSDE vs. VFP data engine is not the issue here. There are projects where SQL-Server is better suited, where the VFP data engine is better suited, or combinations of the two.
>
>I just wanted to see how I could utilize MSDE, if at all.