>>>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?

Well it depends on the application. Typically it's long processes that take more than a few seconds that open the application up to the possibility of corruption.
>
>
>>>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?

Well folder level is fine for smaller companies but for larger ones it's simply not enough. In HR and Payroll applications this is a big issue. New privacy requirements make it manditory that only supervisors for given departments have payroll and HR data. Unless you divide a system up with a different folder or at least different tables for each supervisor, you don't have a lot of options to protect the data.

Identify theft is now huge!! With VFP it's far to easy for an employee with access to a payroll data folder to copy the table to a CD-R.
>>
>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?
It becomes more and more likely the larger your install base. With a small company of only 5 employees you can watch your people pretty close. In a company with 700 employees however it's much more likely someone will challenge your security at some point.

I once again would point to identify theft as the #1 reason that you can't be too safe with any data related to HR or Payroll.

>
>>>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?

what I was saying is that a future VFP should support SQL tables directly as the default database format for VFP. So when you make new tables, new indexes, and use the wizards that the DBF as we know it is gone. I believe Microsoft neeeds to transition VFP off the old DBF structure on to something like SQL by default.

If the database under VFP was as robust as MS SQL (or was MS SQL) then VFP would be a lot easier sell down the road.
>
>
>>>
>>>Greg