Web Site Development

[ramanjain]

Dear Programmers,
I want develop site in pure Foxpro/VFP without third party software.
I do not know about abc about development site in any other language.
Can some one help me to develop site in vfp. I have been used Foxpro since 1995 and developed lots of app for desktop and network environment but I did not developed any site. I love Foxpro programming and want develop site in Foxpro.



regards

 

[Olaf Doschke]

Well, I've heard other stories about cryptor from satisfied customers.
Xitech is selling it, at least their site is still online at

http://www.xitech-europe.co.uk/cryptor5.php

The more standard approach would be using a hosted database, but that's a major rewrite of the data access of the application and you trust your database hoster in a) not using that confidential data themselves and b) protecting it good enough against hackers and other threats.

Bye, Olaf.

 

[ramanjain]

actually I am trying that - users who are from different - different city are access my data base with help of my foxproapp.
So I will deploy my foxproaap to user and a username and password. Presently myapp running on LAN environment now I want this app world wide web.

Is It possible in VFP without third party software ?

If Yes How?

 

[Olaf Doschke]

No, you need a hosted database, your installation needs a driver to access it.
Do you really need a central database. It's unnecessary to explain all users will need your data, as you could also install it on each single client.
The question rather is: Do the users share data, or does any user only see the stem data you install plus his own data?
Then this still is no candidate for creating a central database.
Do you often need to update your software or stem data?
This on the other hand would again be a good reason to host a web application.

If you want users be able to use your software after subscribing/creating an account (and paying a fee) that would rather mean your customers need nothing but a browser and you create a web application plus database you host at some company, eg GoDaddy or Rackspace in the US or something appropriate for your country.

Then we're back to square one, but you can't run your foxpro app with foxpro data centralized. The only solution for that would be allowing access to remote desktop clients, but that's quite expensive per terminal server client access license. It's also only a typical solution for company employees or service contractors to which you have a higher level of trust, and it requires lots more of resources of RAM and disk space, users will be running a virtual PC at the central terminal server in that case, which also adds to the cost of the access licenses and makes it less good scalable.

So let me summarize the scenarios
1. Independent traditional client desktop installations. Perhaps with regular updates of EXE and data.
Data can be stored encrypted for sake of not allowing access to your initial/stem data.
Pros: VFP EXE + encrypted DBFs. Easy with Crytpor. Good scalability, every user has his own computer.
Cons: need Cryptor or similar, setup/update process for users.
2. A Terminal Server and clients accessing it via Remote Desktop or similar software (eg Citrix).
Your software and your data as is runs remotely controlled.
Pros: VFP EXE + DBFs as is
Cons: High costs for hardware and licenses, less good user experience (remote usage can ideally feel live, but will have a lag time)
3. Web Application / Web Database
Pros: No installation for users, central place for data and application.
Cons: You trust a hoster at miniumum about your data and its security against hackers, etc.
Not possible in pure VFP, even if you can get a activevfp (or similar) hoster, your frontend will be HTML/CSS and Javascript likely also is involved.
Total rewrite of most parts, even with activeVFP the approach to react to requests is totally different from a normal desktop application.
4. Desktop application with centralized database (only database hosting)
Pros: Still an EXE in VFP
Cons: You still will trust a hoster hosting your data, your EXE data access needs to be rewritten for client/server remote data access, most likely that means a total rewrite in VFP with eg sqlpassthrough

In regard of 4 there is no such thing as DBF database hosting, file server protocols are not internet protocols, even if they share using TCP/IP and thus you can't host your data as is. As Dan said your requirements really don't allow any of these scenarios. Data can be read, if only record by record displayed, your application has to make use of it somehow. Especially with a web application such scraping off data with web crawlers is done, no matter if legal or not.

Bye, Olaf.

 

[Mike Lewis]

Olaf has summarised the situation pretty well.

The bottom line is that you do not need a web server. You need a server that will host your database. The users will access the database over the internet, but the internet is not the same as the web. If you had explained the situation at the outset, we wouldn't have had to waste time talking about HTML or Javascript or even Cryptor.

A perfectly satisfactory way of handling this would be to move your data to a back-end such as SQL Server or MySQL. You can use your existing VFP application on the desktop, but modified to access the database via ODBC. I'm mot saying it would be trivial, but at least you would be able to keep most of your VFP code, particuarly the user interface and the processing layer. And you wouldn't have to learn any new language - except perhaps the dialect of SQL used by your chosen database.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If I just assume the typical code used for a VFP application, changing from DBFs to MSSQL or MySQL or whatever database is a major rewrite, but otherwise Mike is correct, it's a possibility to do that in VFP.

It doesn't fulfill your requirement of the data confidentiality, you trust a database hoster, you'll not easily host the database on your own server, you'll invite quite a lot of problems, if you'd make your server available to remote users, even just as database server, opening the MSSQL server port, for example.

Bye, Olaf.

 

[DSummZZZ]

One option Olaf didn't mention was an internal/local server containing a VFP database, with a VPN tunnel from the remote users to the local network. But then, there would be some hardware and software that would be required. And a drawback to that would be speed. But it would be local data and it would be secure, and it could use strictly VFP code.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

I am connected to a customer via VPN regularly, almost every day. That alone doesn't put you into the LAN and make it a WAN. You don't open Ports 137 and 445 if not necessary to get NetBIOS and SMB file protocol. Next problem, clients are not in the same domain. Any file access control lists don't work for foreign SIDs. This is not something you set up as a novice, for sure, and I won't ever recommend it.
Just alone for turnaround ping times being much slower via VPN WAN, it's no good solution to share DBFs.

Even that setup is not something you do for any public customer client, but for people you trust, employees.

Edit: Aside of that it's breaking the requirement of confidentiality again, the extended LAN ives file access and people may find out howto address a file and get it fully. If you want control about who sees which data a hosted database with good security is preferable and if you keep a database backend separate by only handing out data via a web service, that gives even finer control of access, eg you may limit any client to say 100 requests a day, I don't know how you could do that with MSSQL, too. Maybe in the application logic. It's not a requirement, but it may become one.

Bye, Olaf.