>Hello, again. Many thanks for the info so far.
>
>Its looks good for VFP and WC as being our development environment, but before we make the commitment, I have been asked to look at the potenital problems (such as scaleablity, reliability, security, etc). I have found most of this from the extensive information from your website.

As for scalability, performance and reliability I think you'll find that Web Connection excels at these three these areas compared to other products. Scalability is virtually unlimited with Web Server farming (there's an article on Load Balancing with Win2000 Advanced Server's NLBS in our White Paper Library). On a single processor PIII 450 note box I've tested Web Connection with over 1.5 million VFP hits in a 24 hour period (see the Stress Testing article above) for a Web store application - imagine some high end multi-processor hardware!

Performance of WC is much better for example than using VFP COM components in ASP due to the efficient pool manager and persistent server instances that cache data and code in running instances. Reliability - well, that's highly subjective and depends on the installation of NT/2000 and stability of the OS more than the Web application. All I can say is that we've deployed apps that have been running medium volume (100k hits a day or so) for over 2 months without any downtime. Plus the monitoring tools that come with the product can handle auto-restarting of servers should there be a problem with VFP or your code.

>I still have a problem understanding how we could write a DLL component which is accessable through script and a browser (no internet server!) I wonder if you could expand a little on your previous statements.

You can't use the same codebase. A Web app is completely different from a standalone app. But you can build an app in such a way that HTML is its user interface. You can then reuse the same generation engine inside of of the app to present the UI and write a small wrapper application that allows using it for the CD or use Web Connection for the Web app.

The idea is that both front ends (CD app/WC App) are just that: Front ends to your generation HTML engine.

>If Web Connection is server side, does this mean that it cannot be sent out on CD without distributing a Web Server Service (Personal Web Server) so that it can be used on a standalone machine?

Web Connection is a Web Development framwork and it needs a Web server.

But many of the HTML and XML generation routines can be used independently of the Web framework. Basically the Response objects, all utility classes can be used externally and can provide HTML generation for non-Web applications.

>
>Can a DLL be called from a script within the browser to access calculations and return results?

Yes, but that approach is usually backwards - I would use a front end application like VFP to host the Web browser to provide the UI. That way you have full control over the application and the userinterface without having to force things through a limited scripting language.

Take a look at the Internet Enabling article on my Web site. It describes how you can interact with IE through Fox code including passing objects and data back and forth for data binding etc.

Again, if your goal is to provide the same UI for Web and offline I probably wouldn't do much with that - but instead keep it simple pulling data on submissions and using common processing routines.