Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Traffic Question

Status
Not open for further replies.

KarenJB

IS-IT--Management
Dec 17, 2007
44
US
Hello again,

We want to put a VFP application on a server that allows users to enter their travel mileage for reimbursement processing. One of the management in our department wrote this....
"You can ask the State but my bet that since it is not a browser based application they are going to say no. The traffic will be much greater in a Foxpro developed app than with a browser based."

We are talking about possibly 20-30 employees entering one or two records per day or 20-30 records at the end of the month if they choose to do it all at once. Does his statement have any validity? I'm not sure what the traffic issue would be, I'm thinking nothing. Thanks in advance.

Karen

 
He's talking about network traffic. There's no way to know if a web app will or will not generate less traffic than a VFP app. Why not use a VFP front end and SQL Server backend? Then tell them it uses SQL Server.

Craig Berntson
MCSD, Visual FoxPro MVP,
 
Thanks for the response Craig, but it seems like a lot of bother to handle 15-20,000 entries per year that can be purged after each year.
 
For what it's worth...

Before I published my first multi-user VFP application (c. 1998), I wanted to see what the performance was going to look like. We wired up 10 machines on a typical ethernet LAN. I created simulation procedures that stuffed the keyboard buffer on each machine. So the scenario was that we had 10 (not exactly state of the art) machines pumping transactions through as fast as the keyboard buffer would allow--all with a direct connection to the Foxpro database which resided on one of the machines. Note: This was NOT a client-server setup.

The results were more than acceptable. In fact, for our user base, there has been very little incentive to go to a client-server setup since.

Personally, I can see where network traffic might go up, but there's no way that the load you are proposing is going to either overburden the network or the application. You will see a significant degredation in performance over a wireless connection, but even that seems acceptable for an occasional connection.

Like I said, "for what it's worth..."

Best wishes,
Ron

 
I'm not sure what the traffic issue would be, I'm thinking nothing.
You're right. Very negligible.

In fact, all the bytes going across the network to draw a web interface in a browser would probably be more than the few (couple hundred maybe?) for posting a mileage transaction.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
The issue with Fox LAN traffic is not data entry, but queries because they aren't resolved on the server, but on each workstation. This means that at a minimum, index data is pulled across the wire. Worse case is there isn't an applicable index so the entire table is pulled across.

Karen: You can use SQL Server Express. It's free.

Craig Berntson
MCSD, Visual FoxPro MVP,
 
Karen,

I pretty much agree with the others.

The sort of volumes you're talking about are pretty trivial. I can't see either FoxPro or your network having any difficulties.

Craig made a good point about queries not being resolved on the server. Even so, with the application you described, it's hard to image it being a big issue. Normally, I wouldn't suggest going to a client-server back end in this sort of situation. But an advantage of SQL Server Express is that it would be much easier to migrate to a full SQL Server if your volumes every grow substantially.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
The traffic will be much greater in a Foxpro developed app than with a browser based" is baseless. Compared to what? What if it is doing 1K worth of data and displaying the result in 1Mb worth HTML output? What is the back end? If backend is VFP, it is true that it generates much more traffic than a client/server back end but again with your figures (20-30 employees, few entries per day ...) it is not worth to think about LAN traffic. If still is an issue then creating a web based application or DLL invoked on server is possible with VFP. Application Virtualization is just another option that would make the statement baseless.



Cetin Basoz
MS Foxpro MVP, MCP
 
Thanks everybody for the input. The users are all local with a fiber connection so things run just fine. The guy that said this is just anti-Foxpro and knows nothing about web-based applications to begin with. I just wanted some reassurance and you have provided that. I have written several other server based applications using VFP as the backend and have never experienced a problem. Most have a lot higher volume of transactions too.
 
Running local with a fiber based network you are probably running 1gb to the desktop. Thats more than enough bandwidth fro the largest VFP app I've ever seen. We have 1gb to our desktops here and I've never managed to get my utilization over 5%

Alan
 
The issue here might be that web based app work off of disconnected tables and DBFs are generally connected all the time. Thus Fox is a little more chatty over the wires. But the emphasis should be on little.

You can use an SQL back end with ado with local temp files and then it will be the same. By the way would thing that Access would have the same problem.

The advantage is that the data is much less prone to errors due to multiple saves.
 
I would argue that the answer to this depends on two criteria.

Firstly the geography your installations and secondly the methodology of accessing the data.

If you are all located within the same office and use a local area network, then the amount of traffic is frankly irrelevant.

If you have people geographically disparate who are expecting to access this system via mapped drives or shares - you can't expect it to work very well.

If you have people geographically disparate who are expecting to access this system a client-server or web based system - there shouldn't be any problem at all.

To throw another spanner in the works, if you have people who are geographically disparate, but use a terminal server or similar approach to access the system (via mapped drives on a local area network) you probably won't have a problem.

Good luck.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top