>Ok, I guess it's about time for me to chime in here. < s >
>
>Blatant attack huh? Yeah I think I like the sound of that. < g >

I found nothing about VFP's native DBCs/DBFs in the report that could be interpreted in a positive light - not a single word.
The whole tone was that native VFP tables are very passé and that one is DISserving his customer if they continue to use them when MSDE is free anyway.
And you make it all sound so simple and easy, implying that all one really needs to do is to learn how to use VFP's SPT features and you're off to the races.

>
>>"Benefit" #1 - MSDE is free.
>>- That's good... ship something that you barely understand as the prime storage medium for your application!
>
>While it is very apparent that you know little, if nothing at all, about SQL Server, my "Benefit #1" assumes that you have the necessary knowledge and skill level to deploy an MSDE-based solution. If you don't have that knowledge then by all means, PLEASE do not use MSDE as you're data storage medium.

You're almost right. I had a project where I was told to design a database in ACCESS that was ultimately to be transfered to SQL Server so I got permission to buy Office 2000 Developer and used it's ACCESS/SQL Server functionality to go directly to SQL Server. But that project was cancelled just as I finished the inital cut of the database. And I have read "Inside SQL server 7.0" cover-to-cover, and while it was very dry reading it did serve to confirm to me that SQL Server is a very complex (and extremely capable) product.
The issue I have is that the tone was that MSDE is a free and simple piece of cake and that anyone who doesn't implement it is bordering on stupidity. I saw no mention that there is a learning curve, no mention of gotcha's, no mention of differences to be aware of. To me it definitely read as VFP + SPT is all you need to know!
It remains a mystery to me how logging and backups and performance tuning and several other required activities are handled in a MSDE deployment. It's easy to make the statement that "MSDE is the SQL Server data engine" but that really isn't telling someone a whole lot!

>
>>"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 suggestion not mentioned so far is to use Microsoft Access as a admin tool for SQL Server. What I typically do though is once I am on a client's network, I register their MSDE/SQL Server in my Enterprise Manager, a very simple thing to do. On a related note, I can also register their server and do admin tasks right from my desk in my office. (no PC Anywhere or other communcation softwear required, just an Internet connection)

Well isn't that something that is at least worth warning people about? Now there is a strong possibility that one actually has to show up at the customer's site ('from your desk at your office' is not likely to be amenable to all customers, especially in these days of security awareness) to analyze problems... and bring their tools along too. And I guess they'll look pretty lame if they have little experience at interpreting SQL Server diagnostics and how to fix them.

>
>>- Not to mention the need to license full SQL Server as one of your development tools.
>
>As I believe Cindy mentioned, the Developer Edition is included with a MSDN subscripiton.

And what is it that makes you think that all of your listeners/readers have a subscription to MSDN?... Was this mentioned as the assumption?... was the cost of that or the required product mentioned?

>
>>"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!!!
>
>Actually, yes it is good common sense to use a database that does not suffer the corruption problems, HUGE security holes, inability to do live backups without having to kick everyone off the system, and lack of scalability offered by the VFP data engine.

While it's great that SQL Server doesn't suffer from corruption problems, there is the implication that native VFP tables are highly susceptible to corruption problems and I say that is a crock of crap! Sure we hear of some corruption problems here from time to time but it is quite apparent to me that the incidence of corruption of VFP native tables is actually extraordinarily low across the whole community. If that weren't so I seriously doubt that VFP would have survived as a viable product.
And it should not be forgotten that at least some of the VFP "corruption" problems are a result of a bug or bugs in the VFP code (I'm thinking specifically here of the "record count off by 1" problem which has yet to be stamped out because no reproducible situation has arisen yet) and it should be remembered that SQL Server is also only software and so can have some "corruption" introduced by a bug at any time too!
"HUGE" security holes are at best subjective and also typically application-specific. Small/medium businesses make those decisions all the time, and the trend to date is that SQL Server costs too much, both as a product and for support. For instance, I'm satisfied with a single dead bolt on my door but New Yorker City residents seem to 'prefer' 2 or 3 of them. Data security, especially in small/medium businesses, is a similar issue, where some will opt (or need) for the whole 9 yards while others count on common-sense security to do the job.
"Live backups", again, are not the kind of thing needed by most small/medium businesses. And what about these live backups in terms of procedural changes?... A business likely has to change their long-used proven adequate backup strategy to adopt live backups and to learn the "rules" surrounding them (impact of bulk inserts and the like) and log file management. Did you mention any of this stuff? If you did I didn't see it in the report.
Scalability is a concern to very very few small/medium businesses. And in such cases, if it becomes a factor then native VFP tables offer lots of latitude for 99.9% of them. This is one of those issues that rings nice with the techie crowd but has little real impact on the actual user community (of your potential MSDE users/customers).

>
>>"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)!
>
>Even if it never does happen, the items listed just above are VERY SOUND reasons for moving to a database-server architecure.

Well your 5 simultaneous queries limit combined with the 10 connections limit of Windows peer-to-peer networking put your MSDE "solution" into the realm of SQL Server licenses and a server OS real fast as compared to native VFP.
So what you are really espousing is a fast-track adoption of SQL Server and some windows server OS when that scalability becomes 'necessary'. Doesn't sound like a real good deal for most small/medium businesses to me.

>
>>"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!!!
>
>Don't take my word on it. Head over to the FoxWiki and search on MSDE. You'll find some documented testing results.

I'll let the above (and other contributor's similar comments) speak for this one.

>
>>- That VFP affords hundreds of connections is not a factor I guess!
>
>Oh please... yeah, maybe it can be done but how effective is a VFP application with hundreds of users?

Very effective, apparently.
Unfortunately I haven't had recent experience with hundreds of users, so I can't cnfirm from true experience with VFP (though I do trust those here who have said they run with hundreds of users). I can say categorically that I saw 250+ users on a FPD application that was vey busy and had over 35GB of data and response for "interactive" work was sub-second. This was in the days of 386/33mhz processors and 10 mbps network connections and a Pentium 90mhz Netware server with 256MB.

>
>>"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.
>
>Actually, my statement "2GB limit same as VFP's table size limit" is absolutely correct. MSDE's 2GB limit per database is the same as VFP's table size limit.

So I can conclude that your statement was deliberately calculated to mislead. That's nice!

>
>>"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.
>
>I don't expect small and medium sized business to go out and but a Standard or Enterprise license of SQL Server if they don't need it. MSDE can serve them very well for free.

Right, but so can VFP native tables. But not on reading this report of your session, which for all intents and purposes says that VFP tables are crap, not worthy of use.

>
>>Absolutely no other problems involved with such a move!
>
>Um, actually you're right on the money. I couldn't have said it better myself. Migrating from MSDE to SQL Server is very simple because MSDE IS SQL Server. The database storage structure is EXACTLY the same, the T-SQL code in the stored procs is EXACTLY the same, the security model is EXACTLY the same... you get the picture.

So I'm a small business running my application with 7 staff on a peer-to-peer network with Windows 2000 PRO and I'm going to triple my staff because of the big customer I just signed for multiple years. Because my application designer had the foresight to use MSDE for my database all I have to do is install SQL Server on Win2000PRO and it will automatically find the database and everything will be hunky-dory. My 14 new staff can start tomorrow and all I have to do is use the application's admin functionality to identify them to the system and away I go! Yea, I like that a lot. Is that really all there is????

>
>>- 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!
>
>A closed mind is a mind unwilling to learn new things. Can you imagine if the aviation industry said "Jet engines??? Wouldn't we need to retrain our mechanics to learn how to work on them and retrain our pilots to learn how to fly jet aircraft? And for what, just so we can provide better customer service by getting passengers to their destinations sooner?"

As I hope is clear by now, it's not an unwillingness to learn but rather reading the report to imply strongly that there really isn't anything extra to learn. MSDE is free and it is the SQL Server engine. You do leave the distinct impression that there is positively nothing to learn if you already have used SPT and that only SPT needs learning if not. That's what I'm getting at.

>
>>- How, again, do I arrange installation of fixed/enhanced stored procedure at existing user sites????
>
>Stored procs are not fixed. They can easily be altered by a script. Are the stored procs in the VFP DBC fixed? Are their tools/techniques available to modify them on the fly?

Once again it is your "simplification" that is the problem here. As best I could read there was no mention of changing/maintaining stored procedures or of differences in doing so when one uses MSDE.

>
>>All in all the article describes grossly over-simplified "arguments" in favour of SQL Server, all at the expense of VFP/DBCs/DBFs.
>
>Um, the decision really is pretty simple and yes, it is at the expense of the non-secure, non-scalable, DBF file format used in the VFP data engine.

Well you've made it sound far too simple. And why you have to just outright trash native VFP tables to do so is way beyond me. Surely you could find some other way to make the sale than to trash the product you "love".

>
>Now before you throw something at me, know this. I love VFP. I use it all the time to develop applications for clients. The only difference between you and I is that I have abandoned the VFP data engine and moved on to a more powerful, secure, scalable, and lets not forget, more respected and more strategic data engine.
>
>>Were coupons for your developer copy of SQL Server handed out at the session's end? Sure sounds like they should have been.
>
>If I could hand out coupons like that I would in a heartbeat. Don't think of me as a VFP-hating basher. Quite the contrary, I'm trying to open the eyes of the community (and people) I care so much about. The yellow brick road ahead leads to the future. Like it or not, the future of data storage in the Microsoft world is spelled S-Q-L S-E-R-V-E-R. I'm interested in helping make sure that you and others are not left behind...

I see, it's a purely altruistic effort on yuor part. I don't suppose that DataClas (or whatever it's called) sales has anything at all to do with this position. I suppose that you deliberately chose to disregard the CursorAdapter functionality for our benefit too.

You could have made your points without trashing VFPs native tables, and all that your sales pitch really accomplishes is to add fuel to an already volatile situation as regards VFP's standing/future. Help like this we really don't need!
Just as there are Kia, Chevy, Cadillac and Rolls', so there are many flavours of database systems available to satisfy disparate customers' needs and wants. You've essentially stated that the Kia/Chevy/Caddy option is crap and that all people ought to move to the Rolls as soon as possible, for their own good.