Has anyone developed a vfp app with data on differnt host?

[EzLogic]

I want to know how that scales.
what i mean is, the POS (Point of sale) application uses native dbf, and the clients (users), install the app and the data resides in their local server as dbf/dbc.

Now, some of those clients, want to have their POS be able to run from home, the store, etc..

that can be solved by having the data central and having vfp store the data and feth the data form a central server located in a data center or hosting company.

again, the data is owned by the client.

anyone done anything like this with VFP and remote server hosting?
sort of like a thin client vfp.

if you did, how did it scale?
is it descent speed (i know there are factors to the speed, internet connection, bandwidth, etc..)

we're talking about 500 users (each have their own applications), and each have their own data on the server (could be defined or filterd by LocID or something)
the exe is local to each client.

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[EzLogic]

for now, the users, use either RDP, logmein, gotomypc etc.. to access their own internal network and launch teh app.

but, some stores own multiple locations and want reporting on multiple stores.. instead of logging in into store 1 print report.. log in to store 2 .. etc..



Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[foxmuldr]

I've never done it remotely like that. In-house, we've had 150+ machines running production queries (each query is an average of 200KB or so in returned data), continually, using an IBM AS/400 box with IBM's DB2. It worked perfectly. Even in our heaviest use (10/100 Ethernet) we never saw any notable slowdown (more than one second).

Shifting that workload to a remote server should not be an issue provided your bandwidth is sufficient. 500 users doing POS should not generate an inordinate amount of traffic, but the communication pathway from A to B needs to be reliable. That's a huge concern right there, let alone bandwidth / response times.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Take alone the aspect of them owning the data. The normal solution is to give the home users access via Remote Desktop or any other version of it (Citrix eg or whatever Ali has mentioned).

Becuase moving data to a host will need a major application change, you can't open a dbf file via http protocol.

On the other side logging into the company lan via remote desktop is configured quite easily, can be made very secure via vpn tunnel (Cisco offers clients for doing that, ie) and on top of that no change to the application itself needs to be done.

Just a few things: Printing to home printers or sending files to USB drives at home isn't possible via Remote connection, without special modules (I think citrix offers such a thing). But the solution in regard of printing normally is to choose a PDF printer and therefore genereate a file, which you can again view or download via remote desktop and then print locally.

As it's a POS system you surely will want to print receipts, there are surley ways to also do this more directly.

Bye, Olaf.

 

[EzLogic]

Olaf,

I was thinking of using FoxWeb server (which i use alot for other vfp hosted site).
here's the scenario:

1- have a dedicated bad boy server in a data center
2- put FoxWeb server on it.
3- create a POSBizObj class that handles request (update/delete/saving data/fetching/reporting)
4- have foxweb return the requests in xml to the application that did the request
5- the POS will consume the xml and turns them to cursors and does whatever ( i would use whttp from west-wind to post/consume the posts)
6- pos sends the data as cursortoxml() to the foxweb and have foxweb consume and update data.
7- alot of the logic would still be in the POS vfp app data, forms, reports, buttons, etc.. just the data on the foxweb server..

hmmmm, intresting...
sort of like a web app, i guess....
the printing will be solved i think, since the vfp POS is hosted locally, and use xml/foxweb/http posts to submit data.

Like Olaf said, i would have to re-write the entire app.
But, i think it's worth it.


thoughts?

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[EzLogic]

Sorry, Point#7 would NOT have the data.. but, everything else...

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Olaf Doschke]

Even if you're fast with this, it will have to beat zero invest to make it RDP.

Well, the effort is a bit over zero, especially, if you need to solve the receipt printing, but there are solutions to that, as eg

http://www.uniprint.net/ProductUniPrintSuite.aspx?gclid=CPHMlbzLkbACFQW-zAodZnUEpg

As far as I observed what others are really doing, they ended up at remote use of the existing app rather than at redevelopment or extended development. It's a different thing, if the app is already web based, eg for intranet usage, to make it available in the internet.

There's another solution, that would work on local full installations and only add a synching component, which gathers all data centrally, but each shop would have it's own data and the internet connection would just be used to synch with central data.

Wasn't it you, Ali, who offered such code here, to rather easily synch data?

The advantage of this is your application code also can be recycled as is 1:1 and can work in conjunction with specific hardware, not only printers, but also touchscreens or keyboards.

But to make the cut between UI and business logic and the data needs the most effort, it's the last thing I would consider doing.

Bye, Olaf.

 

[Nigel Gomm]

look also at

http://www.foxincloud.com/index.php

i've not used it myself (yet) but it works in tandem with rick strahl's west wind and rick hosts a support forum for it on the west wind site.

hth

nigel

 

[EzLogic]

Hey Olaf, that was me. I do that currently.. but, that is for a chain where they 'own' all the retail shops and that works ok.

Now, it is for independent owners.
example:

Olaf, has his own retail store with 3 stations
Mike Lewis: another customer with 5 stations and Olaf's is competition of Mike etc..

so, Olaf and Mike, cannot afford to buy a server and do RDP etc.. besides, alot of the users are scattered through out the country. They are small retail shop owners. etc..

and Mike doesn't want Olaf to see his data etc..and vice versa.. (except no. of users is 100+)





Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Nigel Gomm]

Ali,

The customer doesn't need their own RDP server... there are companies that will host your vfp app and data for each customer.

google something like

virtual host windows server 2008

and there are plenty of ads.

i have several customers using

http://www.yourofficeanywhere.co.uk/

n

 

[craigber]

One of my friends has done it for a chain of convenience stores. You need to be concerned about connectivity. What happens if their internet connection goes down? They should still be able to sell stuff. Use SQL Server. The free Express version will work well for each location. So when a sale is made, the information is stored locally. At some point during the say, you use MSMQ to push the updates from each store to the centralized server. The reason to use MSMQ is that is reliable. You know the updates will be delivered. See

http://msdn.microsoft.com/en-us/library/ms917361.aspx

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

but, that is for a chain where they 'own' all the retail shops and that works ok.

Well, what hinders you to support several chains of customer retail shows, each chain will of course have it's seperate central database, but for each chain the situation is the same, each retail shop works local and synchs with it's central.

Bye, Olaf.

 

[foxmuldr]

Becuase moving data to a host will need a major application change, you can't open a dbf file via http protocol.

You know you could. If you wrote a new disk file format and driver, one which emulated the remote-server side connections as literal tables to be opened, and then parsed the header write commands, lock commands, etc., there would be no limits to what you could do with VFP's built-in DBF engine.

In fact, such a solution would actually be quite elegant as it would remove all the requirements of ever writing SQL pass-through or upsizing, as the new driver would mandate that NO application changes be made to still work, no matter what the DB solution is on the far end.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

What about security, Rick?

Why do sites work the way they work today? In general the accpeted idea of data stored byy webapps is an sql server, mostly perhaps MySQL, which most often is restricted to local access by php or more general webservices.

http:// is allowing mainly HEAD, GET and POST requests. The latter are meant for write access. But these low level requests would need to be taken several levels higher to make it a file protocol.

Users log in to a domain in a LAN and their access and other rights are maintained via LDAP or Active Directory perhaps, as per today. But there is Active Directory for the whole world. These mechanisms, that work for NTFS filesystem are not working via http and so all of foxpros low level mechanisms to determine access rights and to lock rows etc.

If you want to simply reuse your foxpro code, you would have to implement a lot of things the http protocol is not at all designed for.

Webhosters mainly allow write access via FTP and WEbDAV, to the webspace owners only. You can use POST requests mainly for html form data submission, you can allow users to also upload files via POST, but that's about what http offers for write access.

The point is, even if you implement all this, as a hoster I would only allow that on dedicated hosting, and on that level you already can do a lot of things easier via establishing a VPN tunnel to extend the LAN to a WAN.

But as far as I followed a lot of discussions about WAN in the last 10-12 years, this is not scaling well. Bandwidths actually got higher and cheaper, but you can't lower the ping times and long distant connections tend to be less stable overall, so most of the time the discussions end in either remote desktop, which besides access to local hardware has no impact on the software, or to synch between several local installation.

There has to happen a lot more than larger and cheaper bandwidths, to get to what you have in mind, USEing dbfs via Internet. Your concerns must be connection stability, acceptable roundtrip times for several of VFPs low level mechanisms to work, etc. etc.

Bye, Olaf.

 

[foxmuldr]

Olaf,

It's a new thing I'm talking about. It doesn't have to be just HTTP, but can be HTTPS for security. The point is, it could be done, were this new thing I'm talking about written.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

No, I'm not gainst new ideas.

Others knowing me better here than you know I am solving things, even if I will need to search for parts of the puzzle myself. We had a bad start here. Sorry again.

This is just something I have a picture of already, that even though for sure you can do something along the lines of your idea, it would cost much work and it's not worth the effort. I won't stop anybody to show a proof of concept, more than just an idea.

But remember what you said your goal is: You want the foxpro app to work unchanged, so that USE

http://...some.dbf

is possible, secure, with accpeptable stability and scalability.

Bye, Olaf.

PS: I actually know this is indeed possible with certain prerequisites. But it's not practical.

 

[SBTBILL]

One thing I'll say is use SQL tables and not DBF's. It's been years but when I did it we downloaded and merged.

 

[foxmuldr2]

History has been changed here as well. My later posts under "foxmuldr" have been deleted, and whenever I tried to post under that account I was sent to "yahoo.com". Not kidding.

Don't cross Olaf.

Best regards,
Rick C. Hodgin

 

[JRB-Bldr]

Rick - perhaps your former Tek-Tips identity has been 'bounced' out of the forum due to the nature of your dialog with Olaf on 2 different foxmuldr postings - causing a 'Red Flag' report.
It has been known to happen before to others.

I'd recommend not getting into a attitude 'war' with people who are just trying to help.

If you don't agree with their input, that's fine - you can discuss differing opinions without getting rude.

If not then just say 'Thanks' and end the 'discussion'.

Good Luck,
JRB-Bldr

 

[foxmuldr2]

Thanks, JRB-Bldr. I'll consider it.

Best regards,
Rick C. Hodgin