VFP vs. SQL Server

[iolair]

I searched the FAQ's and the Posts to see if there is a comparison of VFP vs. SQL Server, and I didn't see one. Are the two products totally different, or do they serve different purposes? Yes, I'm totally new to VFP and SQL as I've been a FoxPro 2.6 programmer for years now and think it's time to upgrade. Please forgive the stupidity, I'll take a web link if you've got one. Thanks.

Iolair MacWalter
Director of IT

 

[TamarGranor]

There are definitely overlaps between VFP and SQL Server. SQL Server is essentially a data storage mechanism combined with a retrieval engine. When you store your data in SQL Server, you use a different product (which can be VFP) to write your application, calling on SQL Server to store and retrieve the data.

VFP is an all-in-one product for database applications. You can store the data in VFP tables or in a server back-end, and you can develop the user interface and the processing code with VFP.

Lots of people are using VFP apps to talk to SQL Server (or Oracle or MySQL or ...) data. Lots are using native VFP data.

Consider storing data in SQL Server or another server back-end when:

1) you're likely to pass VFP's 2GB per file limit;
2) you need active security;
3) you need real-time back-up;
4) you need an extra measure of reliability.

Tamar

 

[iolair]

Thank you. From your four requirements above, we are fine with using VFP by itself.

Iolair MacWalter
Director of IT

 

[Mike Lewis]

Iolair,

In addition to what Tamar wrote, I would add that VFP is the natural upgrade path for you, as you already know FoxPro 2.6.

You can start developing with VFP now, and still consider moving your application to a SQL Server back end some time in the future, should the need arise.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Iolair,
Another thing to consider about the VFP vs. SQL is that VFP has a ZERO overhead cost, regardless of the number of useres you have for your application. To implement SQL Server, you need to purchase a copy of SQL Server for EVERY PROCESSOR on the server you are running on. In addition, each client connecting to the application requires a User License as well. This can be very costly for a small installation. One of the tremendous benefits of VFP is the very robust data engine, that works largely just like the old 2.6 data table you are already familiar with, with some great new functionality.
So, you can develop away with a single developer's license of VFP, and sell your applications or use them internally to your hearts content, without further cost to you, or your users (except what YOU charge them). So, very groovy from a cost perspective. And to be honest, most small to even mid-sized companies don't have the need for the overhead cost of SQL, especially if the developers have been good and diligent in how they create applications as well.



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[iolair]

Wow! Thanks for the great information. I had not even considered the licensing factor. What we have now is running well, so performance is not a problem. Thanks again for everyone's help.

Iolair MacWalter
Director of IT

 

[alvechurchdata]

If you want to try SQL Server there's the free "Express Edition" at

http://www.microsoft.com/sql/editions/express/default.mspx

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[craigber]

Scott,

That's not quite true. You can buy a per processor license or a per seat license. You don't need both.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Scott24x7]

Craig,
Actually, you do need a processor license for the server box that it is running on. You then need licenses for each connection... Sorry, but that is the case. It has gotten worse since the implementation of Server Virtualization... and if you are running multiple virtual servers, you have to have a lincense for each instance running now as well... which is a real drag...
MSDE is ok for stand-alone applications, but honestly, why would you use it for a stand alone? You can "Attach" users via peer-to-peer connections, but the maximum is 10, which is a non-Server Windows limitation (and not without good reason). In any case, there are limited administration tools from the regular SQL Server, which are sometimes crucial in fixing database problems... so I don't recommend it.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[craigber]

Actually, you have a SQL Server processor license and what is called "client access licenses" (CALs) that allow the user to connect to the Windows server. Technically it has nothing to do with SQL Server. Even if you have VFP data on the server and no SQL Server, you still need the CALs.

The good thing, is you only need one CAL per user per Windows Server. So, if you have 10 users and one Windows 2000 server, you need 10 CALs. If you add another Windows 2000 server, you don't need additional CALs. If you add a Windows 2003 server, you need another 10 CALs.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[iolair]

I got the "Express Edition" of SQL. Thanks for the great tips. Looks good.

Iolair MacWalter
Director of IT

 

[alvechurchdata]

I got the "Express Edition" of SQL. Thanks for the great tips. Looks good.

TheManiac's right though. It doesn't take you much further than Fox performancewise but it's a good (or at least cheap) learning tool.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[craigber]

Performance has never been a reason to move from DBFs to SQL Server.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"