Why is FoxPro used for POS systems? [closed]
Asked Answered
W

6

5

I'm looking at upgrading a POS (Point Of Sale) project which is currently built in FoxPro to .net. The planned architecture is quite complex and there is plenty of rationale behind the new technologies chosen. Some of the requirements include the ability to have both desktop and web front end (where web front end has limited functionality), syncing data with an external website and the ability for multiple clients to run off of 1 server. My current model of choice is an MVP pattern with Sql Server (probably Express) as the DB, and a WCF service layer between the presentation and services in order to allow for remote UIs.

My concern is that during my research I have noticed that there seems to be a common theme amongst touch screen POS systems to build them in FoxPro.

Apologies for the slightly subjective question however I am keen to find out if there is any particular reason for this? Does FoxPro have any particular out of the box functionality that lends itself to this type of system? I have not used FoxPro and so before finalising my choice of technologies for this project would like to make sure I am not missing a trick by ruling it out completely.

Whet answered 4/9, 2009 at 15:20 Comment(1)
If you're looking for a lightweight but decent database that's also free, I'd consider SQLite.Timbrel
E
12

Licencing - SQLserver didn't run well on client OSes and was expensive.

Foxpro was cheap and easy.

If all you are doing is retrieving price values from one table and updating sales in another, then SQL is rather overkill.

Extension answered 4/9, 2009 at 15:23 Comment(6)
Thought this may be the case - do you have any experience with how Sql Server Express compares to FoxPro?Whet
Lightyears apart. FP is a simple DB + forms, Sql Server is hardcore DB.Runnel
Agreed, you see FoxPro for POS and other custom retail front end apps for the same reason you see Access for office apps. They are both serverless databases that integrate UI components and can be easily run on a network share.Mayweed
I will wonder, why not sqLite ...Piapiacenza
sqlite is relatively new on the scene, it's probably a decent option nowadays.Strander
@balexandre: While I don't know how old the system in question is, FoxPro has been around since 1984 (according to foxprohistory.org/foxprotimeline.htm ), while sqlite has only been around since 2000 (according to Wikipedia: en.wikipedia.org/wiki/Sqlite ).Supereminent
T
15

Probably because FoxPro is a POS.

(I kid, I kid.)

Tallou answered 4/9, 2009 at 16:59 Comment(0)
E
12

Licencing - SQLserver didn't run well on client OSes and was expensive.

Foxpro was cheap and easy.

If all you are doing is retrieving price values from one table and updating sales in another, then SQL is rather overkill.

Extension answered 4/9, 2009 at 15:23 Comment(6)
Thought this may be the case - do you have any experience with how Sql Server Express compares to FoxPro?Whet
Lightyears apart. FP is a simple DB + forms, Sql Server is hardcore DB.Runnel
Agreed, you see FoxPro for POS and other custom retail front end apps for the same reason you see Access for office apps. They are both serverless databases that integrate UI components and can be easily run on a network share.Mayweed
I will wonder, why not sqLite ...Piapiacenza
sqlite is relatively new on the scene, it's probably a decent option nowadays.Strander
@balexandre: While I don't know how old the system in question is, FoxPro has been around since 1984 (according to foxprohistory.org/foxprotimeline.htm ), while sqlite has only been around since 2000 (according to Wikipedia: en.wikipedia.org/wiki/Sqlite ).Supereminent
F
2

foxpro was an inexpensive and fast database. It was probably chosen because it was a good match for their requirements at the time it was designed.

Farly answered 4/9, 2009 at 15:29 Comment(0)
R
2

Many POS systems have a standalone capability so that the store can continue to trade even if the connection to the in-store server(s) is down.

Typically this means a local database for price lookup etc, and local storage of transaction data until the server connection comes back up again.

The hardware and licensing costs need to be as low as possible.

Hence FoxPro was a good choice a few years ago, but a properly architected .NET application would be an excellent choice today.

Rare answered 4/9, 2009 at 17:8 Comment(0)
K
2

Many PoS systems date back to before SQL databases became popular on desktop machines so very many still use FoxPro or other xBase-style database. As PoS systems are generally single-user and single-tasking, there was very often no compelling reason to upgrade to a fully-fledged SQL database engine.

Keratosis answered 4/9, 2009 at 20:20 Comment(0)
T
2

FoxPro had a few advantages at that time. I can remember that for many many years all the new concurrent DBs laked at least in on place, so we choose FoxPro over and over again for now POS solutions:

  • it was fully integrated database - so an out-of-the box solution
  • it was really cheap compared to the alternatives (as other users have pointed out too)
  • it ran on cheap hardware - for moderate sizes (like most customers required).
  • it had a simple to learn and intuitive integrated environment, so no extra tools were required.
  • it was very very easy to create very nice reports at that time (managers liked it allot, and since they made the decisions mostly... :) ).
  • FoxPro was a learning course in almost all IT schools, so it was very cheap and easy to find FoxPro specialists. Especially in eastern European countries, their number is still huge (many POS software was outsourced there).

There are still an incredible huge number of FoxPro legacy applications (especially in small and medium companies), so this is not just a POS issue.

Tingley answered 26/6, 2010 at 9:5 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.