>I have no (0, nada, nil, absolutely zip) information from MS on this, either, but I'd guess that it never will be implemented as a part of VFP; you need the backend engine to enforce access rules beyond the operating systems rules; if you can read a file, you can copy it, and so there is no such thing as security where you can manipulate the files directly. As long as VFP manipulates the tables directly and relies on the operating system to control file access, rather than relying on another process to handle access, I'd guess that philosophically (and from a marketing POV, since nothing prevents you from using a backend with enhanced security like SQL Server or Oracle) it'd be counter to Microsoft's best interests. VFP is not designed to be a backend product, rather, it's an application language that happens to have a native file system available to it. The only reason that you'd want to add it would be to make VFP a backend product, something that I doubt MS will do. VFP
>doesn't fit the niche.
>

Ed,

Not only that but MS has released the MSDE engine which is a SQL 7.0 distributable. My guess is that MS would really like to supplant VFP on the desktop but IMO that will never happen for one simple reason. VFP is an ISAM engine and Access et al are btrieve engines. ISAM is always going to be the fastest and in our world speed is king.

Seems to me to be a simple performance issue _and_ an issue of intelligently deciding when to opt for the kind of security a backend engine offers vs the speed and flexibility that an engine like VFP has to offer.

My bet is we wil always be trading speed for security in some fashion or other.

Best,