Hi Jim.
I have a question that is little bit off the subject, but a little bit related as well. Wait, did that make any since?

Anyways.
ALL of my clients are very small mam&pop shops. So the native VFP DBC and DBFs is all I need. And for the most part they have worked out well.

But, if I decided to use MSDE DB, I would have to setup the ODBC/DSN on all of my clients PC. Which means I would have to travel an awful lot, because 99% of my clients are computer illiterate.

Is there an easy way I can set their ODBC settings without doing it for them?

thanks Jim.

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