The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Foxpro 2.6 for E-Commerce?

Just a quick thought/question.. is it *really* bad to use Foxpro 2.6 DBFs as the data back end for an e-commerce site?

Where I work, all of our databases are Foxpro 2.6 and I'm supposed to be developing a .NET 2.0 e-commerce store; all indications point to FP2.6 being used as the data store for this application, as well.  I would so much prefer SQL Server 2005 but there are no upgrade plans at all; however before I write up all the logic I want to know if it's some kind of security risk or something like that, given that it will be storing credit card information and such...

Kind of a silly question, I suppose, but again I don't want to write up all the logic if the thing is going to be as flimsy as a house of cards.
Wayne M Send private email
Wednesday, May 24, 2006
EDIT:  I forgot to mention that we're planning to use that PayPal API deal (I havnt gotten the chance toplay with it yet.. my boss is supposed to be looking at it, but he's not up to speed on .NET) to process payments.  Not sure if that actually has anything to do with my original question...
Wayne M
Wednesday, May 24, 2006
"is it *really* bad to use Foxpro 2.6 DBFs as the data back end for an e-commerce site?"

How well does Foxpro DBF's handle concurrency? 

Way (way) back in the day, I hosted a site that used an access database for a data store.  It worked great for a long time but once the traffic reached a certain (and, I suppose, fairly small) level it basically just locked up.
Almost H. Anonymous Send private email
Wednesday, May 24, 2006
Nothing wrong with it. I wouldn't want to do it, but I don't see anything wrong with it. Hell, there's sites out there that use simple text files as a data store. They work just fine.
Wednesday, May 24, 2006
This comes down to using the right tools for the right job with in given budgets.

A lot of fairly complex web sides were strung together in the last 5 years where the data was stored in text files!!! (I see Sgt. just pointed this out also). In other words, having a old dbase format in place of text files is going to be a million times better. And, I can assure you that those sequential text files are not really multi-user, and are not a model of threading either!!!

If you have a large existing infrastructure based on this stuff, then you might have to bite your lip, and work with it.

However, if you are actually spending real money, and DESIGNING a new system, and you are taking this road, then I would be VERY much against doing this. You are selling out the future when you take this road, and if the product experiences any kind of success, or needs better connectively, then your architecture choice will really hurt you. You will be WASTEing precious dollars over time.

A good database design is going to be the heart and soul of your system. Further, using a good database system will increase your flexibility, and increase your connectivity. (you can have a great design using that older dbase format files, but you can’t have great connectivity/networking ability). 

A database system gives you tools to report on data. Newer systems have better dialects of sql to work with data. Better tools to export data. Better tools to move data around, and backup data.  Ability to have more then one database server for different tasks. Better ability to build web services. This list is so very long of what you give up.

I would really push hard to use a better database system. The cost of these systems is now not much of an issue, and the benefits side of the balance sheet is REALLY large….

You need to push hard for a batter database system, it is a choice you will NOT regret in the short, or long run...

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Wednesday, May 24, 2006
A well done FP database can handle a lot of concurrency. If you already have an infrastructure in place, you should weigh accurately pros and cons, but it may worth a try.

On the other side there are a lot of advantages in using sql server.
It's a terribly scalable db engine.
It's progammability, now, is awesome.
It requires very little administration.
It costs little if compared to the other major engines.

In addition, you can be sure that SQLserver will evolve, I'd not bet the same on Foxpro.
Sevenoaks Send private email
Thursday, May 25, 2006
Thanks for the replies.  There's no way to not use Foxpro (company won't upgrade anything, ever.) but I wanted to make sure there were no glaring security risks in using it for e-commerce transactions.
Wayne M.
Thursday, May 25, 2006
>There's no way to not use Foxpro (company won't upgrade anything, ever.)

Oy vey.
Bill Rushmore Send private email
Thursday, May 25, 2006
"Oy vey."

You can say that again :).  It's been working for the past 10 years or so (i.e. "If it's not broke, why fix it?") and to make things worse, everything is so integrated with the use of invididual DBF files that everything would need to be rewritten if we moved it.
Wayne M.
Thursday, May 25, 2006
Like Sgt.Sausage, I wouldn't want to do it again either.  Been there done that myself.  I did back before Win311 got very big.  I wrote a telemarketing app. for a call center that called on Dr. Offices and Hospitals to get sample product in their cupboards.  My solution used a collection of DBF that were access originally through Clipper and later converted to CodeBase.  CodeBase is just an API.

We didn't have any technical, per say, problems with this.  Our call centers (5 total) had roughly 20-100 concurrent users hitting databases.  My pain points where these things:

1.  I had to do my on record locking in C code. Code management was a real pain in the ass.

2.  Not all NOS handled file locking the same.  Back then, we usually put in Netware boxes which had differenet symantics than Microsoft servers, NT3.51 in the day.  Also Lan Manager on AT&T Unix.  Nothing worked the same.  Probably not an issue now a days.

3.  Indexing.  Oh boy!  Indexes had to be rebuilt in code to flush out deleted records and get performance back up as record sets grew.

4.  No query language.  Complex joins are done in code or with CodeBase you could use some API calls to do this.  Maybe Foxpro has this fixed now?  ODBC allows SQL now??  Probably not a pain point any more.

5.  Data binding.  It simply did not exist back then; maybe foxpro fixed this. 

6.  No stored procedures or DB logic could be configured.  I would never write a DB centric app. without this today.  It just saves so much coding/typing :)

Did it work?  It sure did and it was lightening fast.  The DOS character screens were faster than any Win32 GUI screen I could put together.  Was it a pain to maintain, oh yes.  My day job of writing Accounting software in Win32 GUI is 10x more productive and the speed comparison is mostly a non-issue these days.

Might you look at PostgreSQL?  It has the same interfaces Foxpro has.  You can access it via ODBC, do native calling through pglib (C API/interface), JDBC for Java, and tons of benefits of a RDBMS such as fail-over, less changes if your app. has a long term future to migrate to more users and more interfaces (win32, web, java, handheld, etc...)

Just some open thoughts coupled with my experience with this -- hope it's of some value.
Thursday, May 25, 2006
I would look at *anything* over FP2.6, but the company won't budge on it; in their eyes it's worked for the past 10 years and so there's no viable reason to upgrade away from it (same thing with the roughly 60% of our desktops running Windows 98), especially not when existing apps would have to be re-written (and we do not have the source code for them; all I know is they were done in Delphi 3) because when they were developed real RDBMS technology evidently wasn't around; all I ever hear is how "when it was implemented it really was a great solution given the technology at the time." and for some reason it never occured to anyone that technology changes and improves.  I guess the saying is true... you can't teach an old dog new tricks.
Wayne M.
Thursday, May 25, 2006
The main thing with 2.6 is that it is so ancient and doesn't have much support for external components (not even COM). Also you may have problems with the runtime on a modern machine, because they are too fast!

If your company is committed to FoxPro, you might want to look at experimenting with the latest version of FoxPro (8 or 9, I forget exactly which).

It is so much better than 2.6 you just won't believe it, and you will have a much better chance at linking in with newer technologies, but still have the blindingly fast data access that FoxPro provides.
Sunday, May 28, 2006
I was just googling around the web to find a few pointers on a Foxpro issue when I stumbled on this thread. Just to provide a few points of information:

Visual Fox Pro is now at version 9. The differences in the IDE are night and day, although you can STILL run 2.6 source code under VFP9 if you are a glutton for punishment.

Since VFP3, FoxPro has had a true native database structure (not just a collection of files) and also the ability to 'upsize' to SQL Server and Oracle (never tried the Oracle thing myself). And it has an SQL 'passthrough' function.

VFP is used in a large number of web applications, and now has built-in XML capabilities.

If your dept. head is willing to spend a few hundred bucks you should be able to pick up a copy of VFP9 on the web for around $400. Or previous versions on eBay for less, although the IDE gets progressively more primitive the farther back you go (although it has had full OOP since version 3).

If you want to look at what the developer community is up to with VFP, go to and have a look around.
Adrian Berry Send private email
Friday, June 09, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz