Eric,

I feel that I'm thinking reasonably far ahead, while looking out too far is suicide in this business. Remember how MS initially neglected the Internet, and now tries to claim it as it's very own!?

Why doesn't the VFP Team make it so that VFP is the *premier tool* for full Internet applications, doing the whole job which now must be done by a variety of tools. As it looks to me, VFP is almost there!

Mid-tier trades off VFP's native speed for:
a) more complexity;
b) more cost;
c) much slower performance.

As I stated earlier: "...*OR* the VFP team is augmented to continue to develop for those of us who deliver 'low tech' but well accepted business solutions" I don't really mind that VFP is aiming at mid-tier so long as that is not the ONLY thing they work towards.

Cheers,

Jim N

>How about another 2 cents...
>
>While I agree that VFP has historically been a top choice for small and medium sized business applications, the problem with investing huge resources in developing that part of the product is this:
>
>How far ahead are you thinking?
>
>It's only a matter of time (in my opinion) until Internet/intranet applications start supplanting the traditional LAN application that VFP has been so well suited to. Currently it is still harder to implement a full-featured database app via the Web Server/browser than using a tool like VFP (or even VB), and this may be true for the next couple of years. But before long, the light client requirements, improved maintenance, and connection possibilities of TCP/IP based apps will become the standard, once development tools catch up with with the underlying structures.
>
>I, for one, am glad that MS is focusing on making VFP a middle-tier tool, since it gives me a chance to leverage my existing skills under this new approach to software devlopment. I'm annoyed at their marketing practices (they made lots of promises for VFP6 that won't be implemented properly until "6.1") but in general I'm happy about the direction. Also, I think VFP is ideally suited to this middle tier stuff - in what other tool can you get data from a variety of sources, manipulate it natively (including SQL support, of course!), and then post to original source. Not even mentioning the presence of a local fast DB engine!
>
>No offense intended here of course, just a point of view...
>
>>Joe,
>>
>>You reflect my sentiments exactly.
>>
>>Of course, my concern is rooted in VFP's direction toward mid-level tier. I am convinced that this means a virtual end to development of improved/new GUI capabilities while there remains a crying NEED for much more in that area.
>>
>>Same goes for database/table capabilities, including the need for things like VFP-to-VFP for (at a minimum) SQL commands / records&recordsets; *any* actual I/O command handled by a (designated) VFP 'server', improved security capabilities (though the foregoing would permit a greater degree of that), etc *and* development improvements like OOP menuing and/or OOP reports. These are just a few things which will now likely stagnate in VFP!
>>
>>All the while, of course, other products will come up with fancier UI stuff which users will cry for and which we will not be able to deliver using VFP.
>>I suspect that even full ActiveX capabilities will elude us!
>>
>>Meanwhile, no matter how cheap and how easy to use MS makes SQL Server, the added cost and complexity will deter most small/medium businesses from adopting it. And,let's face it, it can never be as fast as VFP is itself!
>>
>>So it can be argued that "we can do these things today", but the fact is we cannot do all that we would want to do AND we likely never will now. Unless this direction is changged *OR* the VFP team is augmented to continue to develop for those of us who deliver 'low tech' but well accepted business solutions.
>>
>>Cheers,
>>
>>Jim N
>>
>>>>>
>>>>>There is a real need to continue to have s SINGLE product (VFP) which can meet the needs of thousands of small/medium businesses, with at most the concomitant deployment of DCOM but with nothing else being mandatory to keep afloat and to be able to grow.
>>>>>
>>>>
>>>>Jim, this exists now. With a web-based application you can get all the good stuff with less support. The COM/DCOM component runs in either IIS or MTS or even ISAPI. VFP will not solve all the problems. We have users spread all over the world that need access to a centralized database. VFP alone can't solve that problem.
>>>
>>>Jim mentioned "small/medium businesses." Most small/medium businesses do not have users spread all over the world. I am not adverse to using new technologies when they are applicable. But in a lot of cases, VFP alone does a great job. I think a lot of programmers want to incorporate new technologies just for the sake of using the latest, greatest. Well, the main objective in business is to make money (in a moral fashion). And if you spend a lot of money (time) developing using new and different tools all the time, you are in conflict with the main objective. As a developer, my main goal is to give the users a program that will make them most efficient. When we had a need to deploy a VFP OLE server, we made the DLL. But we didn't waste time learning the technology before we had a need to use it. I can spend my time in two ways: Learning a cool new tool/technology, or using that time to give the users a new tool or feature or enhance an existing feature. I spend my time
>>doing
>>>both, but when a new idea for the system comes along that will make users more effiecient, that is the priority.
>>>
>>>I think the need to do something in a different way is driven by the users' needs. I think sometimes we think it is the other way around.
>>>
>>>Anyways, COM/DCOM is a good solution to a lot of problems.
>>>
>>>Joe