Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Blatant attack on VFP database/tables at DevTeach
Message
 
À
14/05/2003 15:11:51
Information générale
Forum:
Visual FoxPro
Catégorie:
Conférences & événements
Divers
Thread ID:
00788302
Message ID:
00788325
Vues:
24
Jim,

I would disagree with your reaction to Jim Duffy's paper. Jim Duffy's paper was purposed to introduce SQL Server to VFP developers and as such I fully it expect it to be biased in favor of SQL Server.

As for your critique of Jim's benefits of MSDE some of them are right on and point out weaknesses in Jim's arguments however some of them are not on target at all, for example;

>"Benefit" #1 - MSDE is free.
>- That's good... ship something that you barely understand as the prime storage medium for your application!

What does your reply have to do with MSDE being free?

>"Benefit" #3 - Use client/server architecture from the beginning ("...even if there will be only one user for that application").
>- There's real good common sense at work!!!

If fact I fully agree with Jim on this one, every application on earth should be built on a multi layered architecture. There is no good reason not to do that. It reminds of the olden days when most apps were single user and folks would argue over whether they should make their apps multiuser when there was only going to ever be one user. They were wrong then it turns out.

>"Benefit" #4 - Scale very easily at any time.
>- Yep, be ready for something that's never going to happen (in 99% of small/medium businesses)!

See my comment on the previous point.

>The article then describes some options for deploying MSDE-based applications using VFP.
>Stored procedures have lots of advantages.
>- I guess I can just go ahead and write these in VFP?...oh, you mean I have to learn a different language AND the particulars of how stored procedures work in SQL Server!
>- How, again, do I arrange installation of fixed/enhanced stored procedure at existing user sites????

First it took me about 30 minutes before I was writing stored procs in SQL Server as the language is SQL. Secondly, deploying changes to SQL Server database stored procs is as easy as a right click and select the option to make a script file. Then run that script on the client's installation of SQL Server.

>All in all the article describes grossly over-simplified "arguments" in favour of SQL Server, all at the expense of VFP/DBCs/DBFs.

This comment is purely opinion and apparently by someone who has absloutely no experience with SQL Server so I have to question how valid the evaluation can be.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform