>>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.
>
Warning - grumpy programmer mode is on. BTREIVE is a specific (ISAM) file product; the B-Tree data structure is the underlying mechanism of most indexes found in use todsay 9there are LOTS of others, but b-trees and variants on them represent the bulk of index mechanisms in widespread use. I'd recommend Donald Knuth's Sorting and Searchning if you want to look at the mathematics of sorts and indexes at a theoretical level; most decent college textbooks on algorithms and data structures have at least a couple of chapters devoted to the topic, and will probably be a whole lot more approachable.)

I think you're badly mistaken here. VFP uses balanced tree structures to implement its indexes, as do most other index mechanisms for other data products. The availability of record-oriented operations is a carryover of xBASE language rather than an artifact of the file system itself. The VFP engine can be made avaialble to another programming environment; the record-level metaphor can be implemented in another language, and VFP can handle the data for you through the ODBC driver or a VFP COM Server.

In fact, the introduction of the DBC and the availability of things like parameterized views makes it possible to operate outside of the record-by-record approach of older xBASE programming, without affecting the performance of the underlying file manipulation. We're actively encouraged to move away from the older procedural model of application implementation.

IOW, the underlying file system implementation and the language can vary independently. there are things inside of the VFP runtime that make VFP's native file manipulation very fast, in temrs of how memory resources are handled, the optimization technology, etc, but there's nothing preventing another language from encompassing the same engine s long as the engine's appetites and requirements were satisified.

>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,