It illustrates the strengths and weaknesses of each MS tool. It was published in Nov. '96, so all references are to Access97, VB5, VFP5, & SQLS6.5. But it's a good beginning point.
If anyone has a more recent document, please post the link.
JimmyK,
VFP is much faster than ... SQL server
Really? I think this would depend on the specs of your server. If you're running a server with 8 900 Mhz Zeon processors with 2 GB RAM and 7200 RPM RAID-compliant hard-drives, your comment wouldn't hold much water. Jon Hawkins
jonscott8@yahoo.com
The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed
I use both Access and VFP. Access is much faster to develop in, but more limited in capability. Especially wrt to forms. You can knock out an interface very fast in Access. The same interface in VFP would probably take 2x as long. Access is not very portable. I have had very serious issues with running the Access MDB on different machines. I have rarely had that problem with VFP. VFP applications: run, print and query much much faster than Access.
Both are usefull tools. Which I use depends completely on what end goal is.
-Pete
Alright, mates, I've heard quite a bit on both sides of the argument about which is faster in core database processes: SQLS or VFP. I have my assumptions, but I don't know of anyone that's actually done it.
I'm willing to give it a quick, informal test. I've got a single processor machine on which I can run both products. This scenario will be weighted slightly against SQLS (which would scale up much better), but its a convenient starting point.
What should be the test? A query and a set of updates and inserts? Should we use ODBC in both cases?
I must note that its not a true apples-apples comparison, since SQLS does transaction logging, security validation, and other such stuff that the VFP solution may not necessarily do. But at least we'll get some sort of evidence one way or the other.
Robert Bradley
In addition to Robert's notes, I can say that SQL Servers developed to work with very large number of little queries to it, when VFP database originally developen to handle very large data sets and work with them making huge amount of complex updates by a single loop (that is more quick, of course, compare to SQL Server).
In other words, VFP application with SQL Server uses usually large set of queries that returns or sends little amount of data. VFP application with native database have much more benefits from such ways of working with data as sorting and search by indexes, displaying huge amount of data in grids, relations between tables etc.
Jon,
Ofcourse with the config you suggest, SQL will be faster.
But VFP need much cheaper PC to run and provide the same speed.
SQL,Oracle do a lot of things at Server-side. And at client-side you must use ODBC. That is why it is slow
I didnt and will not mean that VFP is the best one.
Security, Client-Server model, Distributed database, ... is something must be considered when you choose VFP.
Omega36, It blows Oracle out the door
Big system (in banks,..) must use Oracle 'cause it is safer for their data.
I'd like to listen to all your comments and suggestions
JimmyK, I guess with remote COM objects VFP backend have the same value as ORACLE. Think, you now can access data through remote COM objects.
Security - data that transferred between client and serve objects are encrypted. No access to the server machine by other way than through DCOM. Remote COM objects now have an easy way to query data from VFP backend, convert it into XML string, encode it and send to client. Client decodes it and converts back XML into VFP cursor. By all means this is MUCH faster than with ORACLE accessed through ODBC. However, many things that are built-in into ORACLE will require additional rogramming on the server side.
Distributed programming - no reason to do it on the server, we can do thin in the remote COM objects.
Client-server model - you have even 3-tire application, that is even better than 3-tire!
The things you need to do in VFP programmatically that are built-in into SQL Server and ORACLE serevr are following:
Replication
Backup
Maintenance operations
Data integrity
Edit logging (ORACLE only)
Transaction logging (reliability of the server and stability to power failure - not a problem now with UPS).
.... who knows more????
All above tasks are not so hard to implement with VFP databses.
Finally, with WEB access you will have the same. ASP pages can access VFP database using VFP COM objects directly instantiated in ASP page.
Since the topic of this thread seems to be how the data engines compare in distributed architecture, I would recommend reading the following two VFP articles:
The articles address issues including how to work-around VFP's 2 GB maximum file size and how to optimize multi-processors in VFP using OutOfProc servers, even though VFP is single threaded. The latter also details on how SQLS and VFP faired as the backend for
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.