>>Hey Menachem,
>>
>>I think what we need is a database object. An object that has an events like OpenDataBase, CloseDataBase, OpenTable, CloseTable, RecordPointerChanged and so on. With a DB object there are a number of requested features that could be incorporated by a developer like security and data encryption.
>>
>>Just my $0.02!
>
>I'll buy that for a dollar. All I want is the ability to control out of app access to my data.

I agree with you both wholeheartedly, and have some more objects I'd like to see. The following is a suggestion I sent to the VFP development team recently. I'd like your input as to whether this is possible, or even desirable. Admittedly, I know nothing about the internals of building a language or compiler. See what you think:

I think a good way to draw new developers to VFP while maintaining
backward compatibility would be to reduce the reliance on XBASE style
code. Even though VFP is OOP, much of the code inside an object can still be XBASE in origin. You can still retain this for compatibility, but
there should be an option in building a project (and coding) to disable
backwards compatibility and XBASE style code. The debugger could
enforce more object-like syntax. While things like set statements,
sys commands, VFP's native sql and array commands are powerful, the syntax is not very easy to get used to, especially because the syntax can't be drilled
down on using things like Intellisense. You could refine VFP's object model to have something like the
following:

_vfp.application.arrays.***
where off the arrays object would be remove, insert, copy, dimension and
other array functions

_vfp.application.errors.***

_vfp.application.filefunctions (for low-level file I/O)

_vfp.application.variable (for variable manipulation and operations)

_vfp.application.datatypes.characterfunctions
.dataconversion
.datefunctions
.numericfunctions

_vfp.application.databasefunctions (or you could provide direct
access to ADO here, where all child objects are really ADO objects) Better yet, model VFP's own internal data object after ADO, with additional properties and methods for those really cool VFP functions that ADO does not have.

_vfp.application.systemvariables

You get the idea. You could redesign the object model to fit this
structure, and internally map old XBASE style code into these objects,
so that backwards compatibility is maintained (For the time being
anyway. Eventually with the new syntax, you could build a conversion
tool that would automatically change the XBASE code to object-based
code, while developers would be getting used to the new objects. Over
time, you could drop support for XBASE code which would reduce runtime
file size.)

If you had separate objects that could be drilled down (with
Intellisense) for each of the 'language categories' that you define in
the online documentation, you would have a mechanism for a reduced
learning curve. You could also say that you have a more object-based
method for programming than current XBASE commands. VFP would attract
lots of attention then! I really like VFP, but this would help the
product further evolve.