[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2436
  • Last Modified:

FoxPro vs SQL Server

I’m sure this question has been asked many times, but I am having trouble finding what I need.  I am looking for a comparison of FoxPro and SQL Server.  I would like to find an unbiased document (or documents) that either compares the two products or provides the advantages and limitations of the two.

Our company is currently using FoxPro.  We have a small office and this solution is working.  However, we are about to expand and I am trying to make a case for why we should stay with FoxPro or why we should upgrade to SQL Server (I’m pushing for SQL Server).  I would appreciate any feedback, but really need a source for documented facts, either from Microsoft or a third party.  Thanks in advance for any help.
0
tgerman10
Asked:
tgerman10
  • 4
  • 3
  • 3
  • +1
3 Solutions
 
JesterTooCommented:
FoxPro is a general programming language with database connectivity for various backends.  SQL Server is a RDBMS backend... not a front-end at all.  Its "programming language" is T-SQL and basically supports things related to query-processing.  While it does have a few functions that can perform some general-purpose work it's not nearly as rich a language as just about any front-end language is.  For instance, it is has no built-in capability for defining/using arrays, no forms or UI capability, etc.

You can continue to use FoxPro as your front-end, migrate your data to SQL Server, then modify your data access code in your FoxPro apps to use SQL Server instead of whatever you're using now.  Depending on how entertwined your existing data access logic is with the rest of your business logic and user-interface logic it might be a better idea to just re-develop those apps instead of trying to modify them.  In either scenario, try to separate your data access logic from the business processing logic (creating natural tiers of presentation code, business processing code, and data access code).  Once you separate those pieces you can then begin to put some/all of the data access logic inside SQl Server itself (stored procedures, triggers, functions, views).

I have no bias for or against FoxPro when used as a general-purpose programming language although I don't particularly care for some of its syntax (I have 20 years experience with Clipper whose syntax seems much cleaner to me).  However, I'm firmly in favor of using almost any RDBMS as the data store instead of FoxPro's native file format expecially when the applications are multi-user and/or critical to the business.  Before you decide, you should also investigate other back-end solutions such as MySQL, MaxDB, PostgresSQL, etc.  MySQL is an excellent choice and will become an even better one with the production release of version 5.x (current production release is 4.1.10 but it doesn't support stored procedures or triggers yet... 5.x will introduce those features, although in a limited way initially.  And there are other low-cost/free open-source products as well.

Microsoft's MSDE might be an option but you should investigate it's restrictions before choosing it... (a few missing features, query governor, etc).  BTW, it's a free download as is MySQL and others.

HTH,
Lynn
0
 
CarlWarnerCommented:
What version of FoxPro are you currently using?  The Fox has evolved way beyond what many small offices have been using and have been clinging to for years as they resist the urge to actually change/modernize.  I just saw an example of that in the last few weeks where I was brought in to give them my plan to modernize their very old Fox code which is really quite pathetic.  It's a miracle it's working at all.  But, they did tell me of their many workarounds as they limp through ancient technology.  Another developer has offered to modernize them using DataFlex, certainly not my first choice even if I never saw FoxPro.

Check out the following document, that, although somewhat older, still applies even today in most aspects:

ACC97: Choosing the Appropriate Database White Paper Available in Download Center
http://support.microsoft.com/default.aspx?scid=kb;en-us;168549

Download file choose97.exe:
http://download.microsoft.com/download/access97/whitpapr/1/win98/en-us/choose97.exe
0
 
rherguthCommented:
The biggest win with SQL Server over a file sharing db like Fox is in reliability.  No rebuilding corrupt indexes.  Great backup and recovery features.  You can do great things very quickly with Fox for the GUI, but I would use SQL for the reliability.  If the old application includes the statement SET RELATION TO, it's probably a rewrite, since that's one indicator of ancient design (like FoxBase+ era).

So Lynn, is there  WAIT WINDOW NOWAIT in Clipper?  :)
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
CarlWarnerCommented:
I have apps in FoxPro running now thaat have zero problems with corrupt indexes.  

Sadly, old Clipper developers and many old Fox developers quote their old war stories on issues that don't apply today if you design your application properly and if you are working in a network environment that is reasonable.  There were plenty of network admins in the old days who made it impossible to have a stable environment to run an app in.  Now, I support my own networks and I seem to have no problems in this area.  Amazing.  Of couyrse, network standards and equipment are much better by default today.  So, I won't take credit for being super-network admin.

Visual FoxPro 9.0 is the latest version of the Fox and it was released in December of 2004.  It is a far cry from past releases, but certainly night and day difference compared to any Clipper version or any FoxPro (non-Visual) release.

Microsoft Visual FoxPro Developer Center
http://msdn.microsoft.com/vfoxpro/
0
 
tgerman10Author Commented:
Everyone,
Thanks for your responses.  Unfortunately I do not have time to review them right now.  I will respond soon.
0
 
JesterTooCommented:
I'm struggling to keep this response on a profesional level, but here goes...

>>> Sadly, old Clipper developers and many old Fox developers quote their old war stories on issues that don't apply today... <<<
I find this statement to be very disrespectful.

I never related any old war stories and along with Clipper I also develop in about 2 dozen other languages.  I also didn't claim FoxPro was a bad choice.  However, if their current datastore is based on "file server" technology (which was not clarified) then I recommended a (any) RDBMS be used.  I stand by this recommendation especially if/when the database will be accessed by possibly hundreds of concurrent users (again, the user audience size was never established).  Client-server technology has always been superior to file-server technology for multi-user access due to concurrency management and shared index issues.

>> So Lynn, is there  WAIT WINDOW NOWAIT in Clipper?  :) <<

No, there isn't... but, again, I didn't recommend Clipper.  Clipper has had it's day and that's gone.  I'd never suggest to anyone that they develop a new app in a 16-bit language.  However, in many parts of the world, Clipper and Clipper-syntax products like Xbase++ and xHarbour (both 32-bit Windows languages) are enjoying wide usage.  Personally, while I'm intrigued by these products, there is very little reason for anyone in my profession (here is the U.S.) to invest much time with them... there's nearly no market for those skills except in a very very limited niche capacity.  I moved on to primarily the Java and .Net languages... that doesn't mean that I immediately discarded what I knew about any of the older languages (although that is happening quite naturally due to very infrequent use :-) )
0
 
rherguthCommented:
Hi Lynn,

The comment about the FP syntax was simply geek humor related to this comment you made:

>> I have no bias for or against FoxPro when used as a general-purpose programming language although I don't
>> particularly care for some of its syntax (I have 20 years experience with Clipper whose syntax seems much
>> cleaner to me).

The part I thought you might find humorous was the syntax itself.  A WAIT WINDOW simply throws up a dialog until the user presses a key, but somebody at Fox Software (with a sense of humor) implemented the NOWAIT modifier so that the dialog would close on it's own.  It's just a sample of several humorous syntactical idiosyncrasies of the language.  I certainly wasn't trying to imply that Clipper was somehow a lesser language because it didn't come out of the box with such humor included.  My apologies for any misunderstanding.

As for the file sharing versus client/server RDBMS, well Carl has his experience and I have mine.  If a file-sharing client crashes during file access on a remote machine,  no one can know the status of the database.  If it works, great, if it doesn't then maybe it can be fixed.  Fox doesn't have a transaction log, nor does it have online backup.  There are add-on products out there that attempt to mitigate these issues, but Fox doesn't guarantee writes.  Network administration can be top notch, but a client crash can still damage a DBC or freetable.  Once I started using SQL Server with Fox, those problems went away completely.
0
 
JesterTooCommented:
Hi rherguth...

No offense was taken from your remarks and I appreciate the humor (which I recognized).  While Clipper has no such equivalent command built-in, I did create one which worked similarly... by creating a timeout feature that if no response was given to the dialog it would default to a value, close, and allow the app to continue.  It wasn't used very often, however.  Most of the time you don't want that type of behavior in an app that is expected to be operated by someone in attendance... batch apps are a different story but they typically don't need the dialog in the first place.

>> it didn't come out of the box with such humor included <<

I guess you never saw the error message "mayhem in the case handler" then... Not a syntax statement, and not usually very funny if you were the developer when you saw the message, but the boys at Nantucket must have chuckled about it. :-)

Your experiences seem to parallel my own... I supported some purchased products for several years at my previous employer that had between 500 and 1000 concurrent users.  The app (happened to be Clipper-based but could just as easily have been any xBase product) contained almost 600 prg files and the "database" consisted of about 450 directories each containing around 90 tables each. The environment started out as Netware 4.11 but we eventually migrated it to Windows.  While the data was still relatively small (and correspondingly the number of users) we had nothing but trouble with index corruption.  Finally, two of us spent almost 2 years migrating the app from the Summer 87 dialect to the 5.2e dialect so we could eliminate 99.9% of the several tens of thousands macro operations and enable the product to use Advantage Database Server.  That mostly eliminated the index corruptions (except when some user tried to update the data thru Excel).  As a very large user (at one time we were running their product on 13 servers), we were one of Extended System's early adopters and worked closely with them over the next several years to enhance their product.

As you said, the network's stability was rock solid.  The true problem is there was no central code to manage concurrency between the users retrieval and update of the shared data.

Regards,
Lynn
0
 
rherguthCommented:
Advantage Database Server.  I was trying to remember the name of it.  Yes, I really could relate to the how and why behind it's creation and was always wanting an excuse to use it.  Unfortunately, they were a tad late to the market for our use of it.  We (myself and another Fox programmer) had built a large scale distributed system using Fox and a dozen add-in products.  This was before the internet became cost effective, so we used FidoNet to transfer compressed data batches and built a field by field data synchronization engine to do replication.  I have no idea how many users used it, but it was installed in over 25 states.  The product was around 500,000 lines of Fox code and ran under 16 bit FPW and 32 bit VFP using a single code base.

BTW. I always had a bit of Clipper envy because of the compiled nature of it.  That's what drew me to Delphi.  I disliked nearly every minute of classic VB programming I've done.  There were very few times that I didn't need to make Win32 API calls and VB makes it so difficult to make those calls.  I love C#, but never really took to Java for some reason.  I think because I was using it to make applets, and applets were just a bad fit for Java.  ActiveX worked 10 times faster, and didn't have the long load times.

-- Bob
0
 
JesterTooCommented:
There were a couple of other "client server" engines in addition to ADS but none were quite as successful.  Clipper was initially developed by Nantucket, Inc. as a response to the lack of a compiler for dBase.  There were lots of developers back in the early '80's writing/selling dBase apps that wanted to protect their source code from prying eyes... Ashton-Tate's "compiler" was too little too late.  Actually, all the versions of Clipper (I think there were 8 with 5.3 being the last one) didn't really compile the code... it was reduced to p-code and embedded within a copy of the runtime so that it was standalone (unless you linked the code as a PLL.., then the runtime was separate).  This was pretty effective at protecting the source code until someone created a "de-compiler" which recovered the entire original source code (for versions prior to 5.0... starting with 5.0 variables that were declared as "local" or "static" were recoverable only with generated names... not their original names since they were no longer stored as part of the executable).

Your Fox app was about the same size as ours (I think ours was around 450,000 before we converted it, then it dropped down to around 300,000 by using "header files" and moving a lot of redundant code into a library) which consisted of a suite of 29 executables that worked much like a network... any program could invoke any other through the magic of Blinker (the linker we used).

I used to have the same opinion of VB6, but I began using it more 3 or 4 years ago (partly out of necessity... support of existing apps, and partly because I wanted to get a good sense of how different VB.Net was for migration purposes).  Needlses to say I like the .Net flavor much much better.  I've only dabbled a bit with C# but what little I did was very satisfying.  If I was going to develop a new system with .Net I'd probably choose C# over the other .Net languages.  I really like Java's syntax (which is likely why I like C# so well) but I can't handle a new Jxxx technology coming out every month or so... it makes me feel like I'm trying to drink from a firehose!  The main problem I have with Java is the slow UI when developed with Swing.  The non-gui code seems to run pretty fast now with the JVM 5 but to get good gui performance you pretty much have to use SWT instead and that isn't really a native part of the Java platform in my opinion.

-- Lynn
0
 
tgerman10Author Commented:
Thanks to everyone who has participated in this question.  You have given me something to think about.  CarlWarner’s links were the closest thing to what I was looking for, so I will accept that comment as the primary answer.  That whitepaper is a little dated, but since we are using VFP 6.0, it is close enough.  I’m going to increase the points and split them between everyone who participated.  Thanks again.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now