>>With executive types and dealing with management that only cares about solutions, then you can still do new work in VFP and make a strong case. But I can tell you from firsthand experience VFP can be a very tough sell when dealing with seasoned corporate IT departments. Walking into a mid to large-sized company with knowledgable IT personel and getting them to choose VFP for new development projects is dicey at best.
>>
I've also witnessed this.

>... Once you get over about 20 users, VFP becomes increasingly difficult to support. If a client machine locks up for whatever reason, indexes can get corrupted forcing everyone out to rebuild them. Large companies can't afford to kick 50 users out of a system so they can rebuild an index or pack deleted files.
>
Do these systems use SEEK and REPLACE, or do they employ select statements and cursors, or are they DBC?


>>Another thing that really hurts VFP in the corporate market is there is no real security in VFP databases.
>>
Does XP allow folder level security?
>
For example it is impossible to give supervisors access to data only from their departments or for only certain rows in a table. All they need is a copy of VFP and any security constraints you wish to have on data is completely gone.
>
What is the likelyhood of this happening?

>>I strongly believe that unless Microsoft reverses it's decision to support VFP as a .NET language platform that it will not be accepted well in corporate America for new projects. Not unless you already have a strong team of VFP programmers in place.
.NET is not the only tool out there. And corporate projects are not that big of a market - most of the market does not need or care to pay for enterprise tools.

>>
>>Another strategic move would be to create a new version of VFP that natively supports MS SQL as an alternative to DBF files.

Pass through? I hear some gossip regarding VFP 9. The native file (DBF or DBC?) will have new character field types. The speculation was it might be a variable length field type.

>> If Microsoft could integrate the SQL engine seamlessly into a new version of VFP and provide solid migration tools there could still be a chance to make VFP a more compelling platform.

Is not SQLEXEC() [at least] as seamless as other client language tools in this regard?


>>
>>Greg