>Size is of no relevance here. Security includes more than security of the >data after a "catastrophe", like just keeping prying eyes off the stuff and >generally limiting who can actually see the information, even outside of the >'native' creating product.

I think Jim's point was with regard to security itself. I did not see where Jim was attempting to correlate the two.

>While it is generally the case that 2 gigs is ample for small/medium >business, my most significant prior app (FPD 2.x) was made up of 36+ gigs of >data. The company was less than 300 staff, 250+ of the "connected" and using >the system. The customer database alone was approx. 10 gig. It would have been >far easier/faster to maintain if there had been the ability to store it as one >table. I guess the good old Chunnel project serves as another example.

If memory serves, there were big cost issues involved with the Chunnel Project. That is why Val chose VFP. Nobody in thier right mind with implement a multi gb application using VFP as thier primary data store - at least - unless a gun was held to his/her head.

There is an old expression - just because you *can* do something - does'nt mean you should. The right data storage for the Chunnel Project is either SQL Server, Oracle, or another RDBMS of that class and caliber.

Just curious, what type of fault tolerance was in your 36+ gb system???


>FP then VFP was continuously improving SQL capabilities, version to version.
>This is what I'd like to see continued. My concern is that, as mid-tier, there >really is no need for more sophistication of SQL within VFP, so here again the >developer toiling to deliver a comprehensive VFP solution to his customer is >disadvantaged in the longer term.

What basis do you use to make this conclusion???? How is the developer disadvantaged in the longer term???