>No, it isn't...unless you're saying SQL Server is less powerful than VFP.

Do you really want me to explain the differnce between VFP and SQL Server? I didn't feel like wasting my time earlier, but I will if you need it.

>And how does that exlude Crystal reports? The Crystal designer is a COM component. The interfaces could be written so that it integrates seemlessly with the VFP IDE.

Like I said, why the integration at all? It just adds a hook to VFP developers that I thought we could pull out after we left VS.

>That's a big stretch given today's application requirements. Interaction with other components and applications is almost a requirement for anything but the simplest apps.

It doesn't make MS as much money if thats what you mean. It also makes the learning process easier, to learn one set of syntax and you don't even need to know what COM or ADO are. Does MS want you to build apps like that? No, thats why they've got VS.NET, the complete tool for distributed programming. Guess what, VFP7 isn't in it. Why shoudl VFP7 compete with that? What does MS offer as a simple all in one tool to build either share ware or desktop apps? Access? Either that or something that isn't MS. VFp can fill a very nice void as long as you make it contained, and flexible enough to be exposed.

>Ahh... but think of the marketing possibilities that are opened up by showing the powerful reporting capabilities you could do with CR bundled in the box.

I think it cheapens the procuct. You show a VFP app that uses SQL Server and Crystal Reports.... hell, that could be done with some VBScript. That came free with my Web Browser!

>There's nothing that requires you to use what is there now or any other report writer. CR will be another tool that ships with the product.

Since the VFP report writer wouldn't be enhance, it means the users should learn how to use CR (its a different syntax and methodology than the rest of the VFP) and how to deploy it. And as for "Just another tool", see my comments below.

>Ummm... no. Their job is to provide the best developement tool in the most cost effective way. If that means bundling CR rather than enhance their own, then it makes sense.

Are you talking about the VFP Team? I was talking about SeaGate's job. I don't know how teh VFP team will be able to sell VFP at a low price (I recall Robert trying to get $VFP7 + $VS.NET = $VS6) by including ISExpress, CS, and every other third party under the sun. If we keep doing that, all we have is 4 thrid party products and a command window.

SeaGate's job is to get me and my customers to like their product. The Report writer is simple enough for me and my users right now. If anything, we could add 3 enhancments to it, and it woudl hold over most Report Writer problems for quite a while:

1. Create DYnamic properties like in grids.
2. Add support for multiple detail bands
3. Better support for graphics

Is that asking too much? I don't know, but I'm guessing its not extreme. Will having a native VFP report writer give us more flexibility in the future? I think so, say they move VFP to all OO, woudl it be more benificial to have a consitant elegant reportwriter included, or is everything done through CR gonna be akward since it Seagate won't go out of their way to cater for VFP? If they are tightly integrated, will choosing another Report Writer in teh future break backwards compatiability or deprecciate your VFP investment?

Using CR is great, go for it, but I don't understand the tight integration, thats all my point here is.

>I'm curious. Has your views on this changed since VFP was pulled out of VS?

Which views in particular?

On a related note, when we discuss the future of VFP, I notice alot of the active debators are the MVPs or long time users that would rather keep doing what they're doing now, but sometimes you need to think about users that have never used the product before. After all, if I wanted to sell a product and make money, I would sure try and get that money from more people that currently use the product.