>Mike, Why are you flaming Jim? Your response is not helpful to our communtity. If you disagree, clearly state why. It is not appropriate to make a personal attack.

Well, based on how useful explaining things to Jim has been in the past, I hardly see it fit to respond to his sloppy arguments against Duffy's paper. But for fun, sure:

>but the implication is that there is absolutely nothing good about "file-based"!

First of all, this is an emotionally charged claim that takes JimD's reasoning to "absolute" levels where it was never intended to go.

In the Milwuakee Hyatt, JimD and I have discussed DBF vrs. SQL Server and I recall (correct me if I'm wrong, Jim) arguing for DBFs in particular applications where the data store is only secondary to the purpose of the application. For example, a widely distributed Help Builder like tool that creates a CHM from data makes more sense to house the data in local tables. Web Service clients with minimal impact on the desktop installation also fits this description. JimD agreed that in these types of applications, it may make more sense to use a DBF.

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

This is a completely bogus counter argument. If JimN doesn't want to take the time to learn a tool, he should just say it; but using his ignorance to prove the point that JimD "blatanly attacked" DBFs is laughable.

>"Benefit" #2 - Use the full product during development (to use the administrative tools).
>- Another goodie... what do you do when a user has problems and you have no administrative tools handy?

Another bogus arugment. We can say the same thing about DBFs. If a user has a problem with a VFP app, and you have no VFP handy to troubleshoot... OMG! Phhh.

>- Not to mention the need to license full SQL Server as one of your development tools.

As Cindy stated, this is untrue.

>"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!!!

No justification for JimN's dismall of JimD's advice was given, therefore theres nothign to respond to.

>"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)!

Use the right tool for the job. If there is no case for scaling, there is no case for using a scaleable tool. Thats correct, but its hardly contradictory to JimD's advice.

>"Benefit" #5 - "...“5 simultaneous queries” limitation... should not impact at all" (in an environment with 20 connections).
>- Go ahead, bet your business and reputation on that!!!
>- That VFP affords hundreds of connections is not a factor I guess!

Obviouslly, there should be some kind of analysis of a systems requirements before its implemented. If MSDE's connections don't cut it, scale up.

Chaim, this is why I flamed JimN. Jim Duffy does this stuff all the time. He's got the apps to prove it. I wouldn't bet a business on his advice without analysing it, but to dismiss it entirely because JimN, who has absolutely no experience with these products, thinks that its unsound advice would be foolish.

>"Benefit" #6 - 2GB limit same as VFP's table size limit.
>- Bzzzzzzz wrong answer! - VFP's is a per table limitation while MSDE's is a all the data limit.

This is perhaps a squirrely worded fact, but it can be defended. In either case, VFP has no easy options for scalability once it hits 2gb on a table. With MSDE, its just a matter of the client buying some enterprise licenses of SQL Server.

>"Benefit" #7 - "...it's just a matter of the client buying some enterprise licenses of SQL Server...".
>- That's so easy and so cheap that ALL small/medium businesses will no doubt be chomping at the bit to do that right away. Absolutely no other problems involved with such a move!

I'm not sure what JimN is complaining about here, unless he knows of any pitfalls related migrating from MSDE to SQL Server. If he does (and he doesn't), he should mention them instead of making stuff up.

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

Translation: "You mean I have to put in the effort to learn a new tool to reap its benefits!" Laughable, just as it was in the beginning of his post.

>- How, again, do I arrange installation of fixed/enhanced stored procedure at existing user sites????

No idea what this is even getting at.

There, I doubt Nelson will care, but I thought I'd do this because you asked.