Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Microsoft's position on Visual FoxPro and .NET
Message
De
06/06/2004 14:55:05
 
 
À
06/06/2004 05:57:23
Information générale
Forum:
Visual FoxPro
Catégorie:
Conférences & événements
Divers
Thread ID:
00908177
Message ID:
00910572
Vues:
50
Thomas, when I talk about not improving the VFP data engine I mean from a Microsoft perspective. If they don't improve the data engine they force you to juump to MS SQL at some point, thus selling SQL licences (where the real money is).

If we want to have VFP for long we have to do some trade off, and one of them is a weaker data engine than we'd like to, so that VFP is more attractive to Microsoft (and they will be improving it at a constant pace).

There are millions (indeed) of VFP applications out there helping companies of all sizes to go on. All of this applications run in Windows, and quite a lot use Office through automation (or XLS export), and quite a lot use MS SQL as the backend.
Even if MS would lose money on the development of VFP (which I don't know), it would still be a VERY profitable product.

What's more, should MS drop VFP from it's product line, how many VFP developers would change to a development environment able to compile programms for Linux, Mac or UNIX? Even if only 10% of VFP developers would do so it would be a lot of money lost for MS in the long run. I think they cannot afford it.

>Hi,
>>MS can use VFP to sell more SQL licences than we think.
>Agreed.
>
>>The 2GB limit should never be raised,
>Strong disagree: You will have a border to be afraid of.
>This border used to be 5 to 10 times the size of the
>"current" hard disk size, now it is about one to two percent
>of the current hard disk. Even if customer data has grown at a
>slightly slower pace, the borders of the amount of data you can
>process are now set by VFP and not by hardware anymore.
>
>Local Datamunging is done best on your local machine:
>here I prefer VFP to SQL Server.
>
>>native encryption and security should never be implemented, ...
>Agreed: It doesn't make sense to raise VFP's standards
>to the level of SQL server here.
>
>I'ld like to use VFP data in all situations where transactions
>and heavy multi-user write input are not asked for:
>scenarios you would use MyIsam or Heap table type in MySql.
>
>my 0.02 EUR
>
>thomas
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform