Currently we are running a VFP app (collection of forms) on a client machine which accesses the database using a mapped drive connection to a server. Because of this connectivity the app runs slow. Is there a way to speed the process on the client side. Does VFP have a way to use ODBC connections? Is there an easy way to convert the application into a web app? Thanks.
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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VFP Questions
- Thread starter itc1
- Start date
Mike Gagnon
Programmer
Are these VFP tables? If so accessing directly the data (as you are doing), is the faster way, rather than using an ODBC driver. We are currently using your set-up with not much loss in speed. Are you using 10/100 NIC cards?
Not as easy as it sounds. But you can start by looking at this link
Mike Gagnon
If you want to get the best response to a question, please check out FAQ184-2483 first.
ODBC will probably be slower because of the ODBC overhead. The best thing is to understand how the data is being pulled and make sure any queries are Rushmore optimizable. See and the VFP help file for more information.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Mike Lewis
Programmer
Itc1,
As the others have said, forget about ODBC. Regardless of the overhead imposed by the driver, ODBC won't help in this case because Visual FoxPro is not a true client/server database. That means that the record selection is actually performed on the client machine, so there is no benefit of moving to ODBC.
You would, however, get a lot of benefit by moving to a true client/server back-end, such as SQL Server or Oracle. That would get rid of the overhead caused by the network, but it would mean a great deal of redesign and re-programming of your application, not to mention financial costs, so it is not something to be done lightly.
I think your best bet would be to focus on the design of your database, and particularly to check that all fields that take part in WHERE clauses, LOCATEs, filters, joins, etc. are properly indexed.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
As the others have said, forget about ODBC. Regardless of the overhead imposed by the driver, ODBC won't help in this case because Visual FoxPro is not a true client/server database. That means that the record selection is actually performed on the client machine, so there is no benefit of moving to ODBC.
You would, however, get a lot of benefit by moving to a true client/server back-end, such as SQL Server or Oracle. That would get rid of the overhead caused by the network, but it would mean a great deal of redesign and re-programming of your application, not to mention financial costs, so it is not something to be done lightly.
I think your best bet would be to focus on the design of your database, and particularly to check that all fields that take part in WHERE clauses, LOCATEs, filters, joins, etc. are properly indexed.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
Speed is rarely a good reason to move from VFP to C/S. With properly optimized queries, VFP is as fast or faster than many C/S backends.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Mike Lewis
Programmer
Craig,
With properly optimized queries, VFP is as fast or faster than many C/S backends.
We've had this discussion before.
I think the consensus was that VFP will beat any other database engine in terms of raw processing speed. But a client/server architecture will give overall better performance, because it is capable of running the query entirely on the server and only returning the relatively small set of records that meet the selection criteria. So less network traffic and faster throughput.
Of course, all this assumes that everything is properly optimised and that the application is designed to take advantage of the benefits on offer.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
With properly optimized queries, VFP is as fast or faster than many C/S backends.
We've had this discussion before.
I think the consensus was that VFP will beat any other database engine in terms of raw processing speed. But a client/server architecture will give overall better performance, because it is capable of running the query entirely on the server and only returning the relatively small set of records that meet the selection criteria. So less network traffic and faster throughput.
Of course, all this assumes that everything is properly optimised and that the application is designed to take advantage of the benefits on offer.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
Mike,
I didn't say anything about network traffic in my reply. But, you are correct. A C/S solution will reduce network traffic over directly accessing VFP data on a server.
That said, there are ways to architect a VFP solution that will reduce network traffic of the "traditional" VFP model. However, it requires more design and development efforts.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
I didn't say anything about network traffic in my reply. But, you are correct. A C/S solution will reduce network traffic over directly accessing VFP data on a server.
That said, there are ways to architect a VFP solution that will reduce network traffic of the "traditional" VFP model. However, it requires more design and development efforts.
Craig Berntson
MCSD, Visual FoxPro MVP, Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"
Responding to Danceman's posting -
I didn't think putting the exe (& runtime files) on the server would help because doesn't the exe still run on the client computer and thus pull all the data across the network?
itc1 - you've gone very quiet!
Stewart
I didn't think putting the exe (& runtime files) on the server would help because doesn't the exe still run on the client computer and thus pull all the data across the network?
itc1 - you've gone very quiet!
Stewart
Mike Lewis
Programmer
Danceman,
I agree with Stewart. The location of the runtime files won't affect the way the data is accessed. In fact, you'd probably get better performance if the EXE and runtimes are on the local hard disk, as this will make it faster to load the code, but that's a separate issue.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
I agree with Stewart. The location of the runtime files won't affect the way the data is accessed. In fact, you'd probably get better performance if the EXE and runtimes are on the local hard disk, as this will make it faster to load the code, but that's a separate issue.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
- Thread starter
- #12
- Status
Similar threads
