Myron, Here we are again, making excuses on behalf of MS and the VFP team.

It is time they found their voice and gave us some meaningful answers based on facts.

We can all go around in circles with fully UNinformed arguments pro/con anything regarding VFP. You know, MS doesn't really hand out Borwnie-points to those who always write beholdingly about them, much as you might wish tehy do.

Getting specific a little, it might be a "fundamental change to FoxPro" if security were implemented the way YOU picture it. But maybe there are several ways, and maybe the need is far more basic than you envision. Jumping to conclusions just to 'give MS an out' doesn't do any of us any good. I know whining doesn't do much either, so if you've got a better idea, I'm happy to listen.

Regards,

Jim N

>I am sure that MS does look at many feature requests and due to other products
>or services available sets a low priority. Also, requests that require a substantial
>impact on the base product and backwards compatibility they problem place
>lower on the priority list.
>
>Adding security to DBF's would fundamentally change FoxPro. They would
>need to encase it in some monolithic data server (like Access, SQL Server,
>Oracle, etc.). This would mean a massive re-write of the core of VFP data
>handling capabilities. Also, this would eliminate or significantly reduce
>data access speed. Many people have outlined the many system
>security feature that are available to maintain
>security. Additionally there are products that allow you to encrypt your
>data, add checksums, etc.
>
>How many of the main stream developers would have voted to put
>object orientation in VFP when MS did. By the number of people in our
>users group who adopted VFP the first year I would say less than 10%.
>Sometimes I believe we need to have some faith that the Fox team may
>know of things coming in the future that we don't. I believe that VFP6 is
>another step in this direction. I for one want to move my skill sets foward.
>Interoperatibility with the operating system and other products is the
>way the software industry is moving. I don't want VFP to be a legacy
>system. We have come to a point in technology that we can not
>be the master of everything in our environment unless we want to be
>confined to maintenance of legacy code or to small projects.
>-myron kirby-
>=============================================
>>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