Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
VFP 6.0 Don't seem to be what we were waiting for
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Conférences & événements
Divers
Thread ID:
00100091
Message ID:
00101462
Vues:
63
Josh,

While I of course respect your opinion (along with everyone else's here!), here we are making excuses for MS again!

Neither you nor I actually know what you postulate to be true. I agree that it may well be likely, but it could just as likely *not* be so too.

We need a way to have MS respond to these types of concerns/issues/desires. And don't tell me about the FOXMKTG address, unless you happen to know for sure that they have changed their policy, because feedback is next to nil on serious submissions to that place.

I've accepted (even with thanks) the version 6 content. But there are more than a few things which USERS want and need, and it is HIGH TIME that those were delivered.

Cheers,
Jim N

>Jim,
>
>There's no such thing as an environment where a server can't crash or loose power. By the time you get VFP to the point where it will offer the features of SQL Server, it will be just as expensive and complex as SQL Server. In the mean time, Microsoft is working hard to make SQL Server easier to use.
>
>VFP just isn't a server database. I think if MS tries to make the product do anything, it will end up too big and unwieldly to do anything well. It seems to me that the best way to do things is to choose the right tool for the right job. VFP isn't best for everything any more than VB, Access, and SQL Server are.
>
>>Two major reason always given for going to SQL Server (or any other SQL-type back-end) are:
>>1) much greater protection offerred by a back-end solution;
>>2) much greater data sizes available.
>>
>>Well, the "protection" aspect could quite well be taken care of *IF* we could run a VFP Server which would be in a controlled, power-protected environment where pulling the plug or sudden turn-off or power failures couldn't happen. It could be responsible for all database read/write actions, SERVING clients the data they request.
>>Sure, this might be much like what SQL provides, but it would be at a much lesser cost and it would involves far less secondary costs like education/training or overhead, etc.
>>There would still be a use/need for SQL Server type capabilities, but a much wider scope for VFP-style applications. Users would then have a legitimate CHOICE.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform