While it is true that a lot of options are available, but if you look at the original posting, we just feel sad that M$ continously ignoring to include that basic yet important feature on the next releases of VFP. What we can do now maybe is to resort to all the said options. Oh my, my, my....

Thanks for you suggestions.


>Hi Jess,
>
>>>Kamal, we want the native VFP database because of the Rushmore Technology. Cost is secondary to us. What we are longing for is just Basic Security features, and therefore, we are not expecting it to be a high performance database.
>
>ADO could be a possible answer for you. Its a pity that VFP does not have security for databases.
>
>Have a look at www.microsoft.com/ado
>
>BTW, Just a few things which ADO supports:
>
>.Batch updating helps improve performance by locally caching changes to data, then writing them all to the server in a single update.
>
>.Support for stored procedures with in/out parameters and return values.
>
>.Different cursor types, including the potential for support of back-end–specific cursors.
>
>.Support for limits on number of returned rows and other query goals for performance tuning.
>
>.Support for multiple Recordset objects returned from stored procedures or batch statements.
>
>.Free-threaded objects for efficient Web server applications