Gene, there are companies out here that have systems that have been developed over many years. This is not something that you convert just for the sake of speculation of the discontinuation of a product.

Let me give you an example of where VFP would be the solution of choice for a WWW site: We have a system that does, among many other things, claims adjudication for extended health care claims. The calculations are rather involved given the highly flexible EHC plans that are available. This code is in place and used virtually every business day. Now, say we want to allow the employees of clients to connect via the WWW and enter a claim for a pre-determination to see what would be paid if they incurred an expense for whatever type of benefit (this applies to dental coverage also). Well, we can take existing VFP code and compile to a DLL and use that in our WWW page. Or, we can try to re-write the adjudication method in another language. Did I mention that group insurance is a fast-changing business with many plan options being added regularly? This means changes to the adjudication calcs. By not using VFP for the WWW page, we would essentially double our maintenance of the adjudication portion of the program. Well, probably more than double, since the other stuff would be written in non-VFP ;~)

Do you see my point?

Joe


>Maybe my choice of words was not correct. Yes, web development
>can be done in VFP, but it is a Microsoft solution. It takes
>third party tools to make it work as easily as ASP. Try to find
>a developer that has created VFP web solutions versus ASP (or Java).
>They are few and far between. Yes there are top notch VFP web
>developers that can do anything that ASP\Java\etc can do. I've read
>there are still people running BBS's with Commadore 64's also. No
>I'm not putting down VFP as old technology by comparing it to an
>old computer, I'm just saying there are easier solutions that
>have a following of hundreds of thousands of developers. Why
>use obscure products that have few followers when there is a
>perfectly good Microsoft solution? Why complicate the issue?
>Most important to me (and to many developers) is what about
>technical support? Tech support!!! Tech support!!!
>
>A special note: I am only pursuing this discussion, even taking
>an adversarial position, to understand why VFP and third party
>products need to be used. I've used xbase since dBase II but
>don't understand the benefits as a web development platform.
>I just left a web project where I had the choice of developing
>in anything I wanted (usually I'm told what language to use).
>I've just got the go ahead on another client (after developing
>a small prototype in ASP) and can use any platform on this
>project but I don't want to say:
>
>USE bastard_system_to_develop_website ALIAS job_security
>
>
>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>And unfortunately, VFP is not suited for this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>Just two questions,
>>
>>Isn't Universal Thread written in Visual FoxPro ?
>>
>>Isn't Visual FoxPro + Internet integration what West Wind Technologies
>>specialize in ?
>>
>>Michel.
>>
>>================== Original message follows =======================
>>
>>>>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.
>>>
>>>I'm actually surprised to see how many companies are
>>>starting to ask to put the application on the web instead
>>>of in the traditional exe. The added cost (twice in many
>>>cases) is less an issue then having applications that can
>>>be coninuously updated and users that can access\update the
>>>info from anywhere.
>>>
>>>And unfortunately, VFP is not suited for this. Microsoft's
>>>solution is ASP\VB Script and MTS using VB (not VFP).