>>>>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,
>
>
>Ed,
>
>Gosh, didn't expect to make anyone grumpy. *g*
>

Btrieve is a specific product, noty a general approach; what its lock strategy is i can't say off hand. A backend can do locking at many levels, file, page, record and field locking strategies. An ISAM mechanism can implement locking at many levels as well; there have been xbase variantys that implemented field-level locks, and everything I'm aware of had a file level lock available. So that argument is not corre4ct. Again, B-Trees are data structures, bTrieve was actually an add-on ISAM that was marketed in the lat 1980s and early 1990s and has no impact on any existing backend product as far as I know.

You can have record and page level locking without having B-Tree indexes; hashed indexes frequently have page locking strategies.

>Let me ask you this then, doesn't Btrieve use page locking and ISAM use record locking? That was essentially my point; that ISAM will be faster *typically* because with record locking you can "get in and out" more deftly. I do know that a LOT has to do with how hard you "push" your system with respect to editing.

Nope; again, you can deal with a recordset-oriented file record-at-a-time if necessary and traverse it sequentially. There are times where procedural processing pays big dividends; the cost of programming and the use of bandwidth is extreme on a record by record, local processing basis. Whenever bandwidth is a scarce resource, a backend will pay high dividends by minimizing what has to pass over the wire to find what you're looking for.
>
>My experience has been that page locking can be slower than record locking -if- the system has a lot of editing activity, for obvious reasons.

That runs contrary to my experience; if multiple records under edit reside in a single page, fewer locks are being tossed about. The issue of record locking vs page locking is one of granularity of the lock, not the efficient nature of the lock mechanism. With variable-length records, page locking offers huge advantages in terms of lock management - a pae is a fixed-size object, while a record is not, and it's harder to maintain the table of variable-sized locks in general. During data addition, page-level locking pays off well, because a single lock may siuffice for several insert operations.

>
>Best,