Zlatin,
For VFP 6 SP5 and VFP 7, don't forget that you can just call VFP mtdlls from ASP and ASP.NET. We prefer doing it this way since you can take advantage of the technology Microsoft is putting it's muscle behind and still use VFP code. It has a lot advantages over FOXISAPI including: less complex to install and distribute, stronger objects and methods to manipulate web information(ASP built-in objects), just as fast as FOXISAPI (since ASP.DLL is just another ISAPI extension), and blends in very well with existing ASP and ASP.NET sites...
>>We have a large, complex VFP7 application that is used by numerous clients. Is it possible to move such an application to the Web? We would want a client to be able to access their system and data from anywhere. How would we go about it? What factors are there to consider? I know absolutely nothing about Web programming or anything related to it, so I have no idea where to even start. Any suggestions would be appreciated.
>>
>>Elyse
>
>As a general conclusion to all postings before mine I can say the following:
>1. Make sure your app is properly designed - n-tier design is the key factor of sharing the processing between the client and the server.
>You should think separately at least on 3 base tiers: Data provider (data servicies), Logical engine (business servicies) and Interfacing part (user servicies)
>Each of this tiers can be separated on other ones, depending on the fact how complicated is the problem you solve.
>Also in some cases they can be mixed, interlaced. Think about the following example: basic data validation on a Web Form before this data is send to the server. This is part of the business logic integrated with part of the interface.
>
>2. Possibilities for future grow. In other words sugestions for scalability.
>If you suggest that your app is going to grow in the nearby future, you should keep in mind that through the entire development process and finally test your application (after it is developed) with an overload.
>
>3. Learning curve. When you select the technology in which to develop, consider the qulification and knowledge of your current IT stuff. You may need special training, hire additional employees or do some B2B subcontracting (why not with our firm?)
>
>4. Technology amortization - if you have to learn, and in all the cases you will pay money for training/hiring/subcontracting then the appropriate decision will be to choose the latest (or nearly the latest) technologies. If you have some knowledge in some obsolete technology - you should make trade-off decision.
>
>5. The Budgeting plan. Keep in mind that a good IT project may suffer from bad financial management. Key points here are the licences of additional software and hardware needed, additional training and HR, etc.
>
>6. Last but not least - the customer needs. If you make some ultra-new but ultra-expensive solution, the result will be the same as making some really-"lame" and cheap "solution". You will be not able to return your investment.
>
>After making all the trade-offs you will have choosen a technology:
>
>If it is Web&Windows based it is supposed to be some kind of IIS extension: ASP, ISAPI, etc.
>
>As it is supposed to be a database application - maybe with SQL Server backend.
>
>As it is based on an existing VFP one - it may use COM together with FoxISAPI or you may rewrite it to use Web Application servicies that are part of VFP7.
>
>-or-
>
>you may choose to change the platform - to make it .NET based application (if you can afford the time and money for that task)
>
>Well, I think there can be said more... but I'll stop now, so that I'll not push you in the "wrong" direction. Anyway you should make many decisions before strating porting your app.
>
>Kind Regards