Trevor,

My company produces a restaurant point of sale system and we were in
much the same position as you. It was originally written in VB6 using
an Access DB backend.

Having used Access and knowing its limitations, we designed our software
to help over come them. We knew however, that with 9, 10 or 15 station
systems, we figured it would be unwise to continue with a desktop
database of any kind.

We looked around at SQL db's and even tried a couple of prototypes using
mysql and MSDE. MySQL choked on the inserts/updates, but we were using
ODBC and MSDE was a monster to deploy and was a resource hog to boot.

We played with IB open and really liked it after some testing. About 5
months ago, we started switching our existing customers from IB to FB
and new customers automatically got FB.

Its amazing the punishment that an FB server can take with the modest
hardware that we use.

For instance, we recently did a 15 station system for a high end night
club on the west coast. The server was a Win2K Prof. box with 512 MB
RAM and 7200 RPM IDE WD drives, 3 com NIC, etc. This place does about
3200 transactions on Friday and Saturday nights. I was onsite for this
one and there were like 2-3 servering staff backed up on each station
waiting to use them, I mean this place was rocking. Think about it, for
each sale there is an average of maybe 8 line items and thats over
25,000 inserts by itself, plus employees clocking out, voiding sales,
sending print jobs to the kitchen, bar, running credit card
transactions, splitting sales, etc, etc. Restaurant software is one of
the highest transaction intensive POS I've seen and the FB server don't
even skip a beat.

We get the advantage of having one of the few SQL based POS systems on
the market without having to pay seat licenses and so our software stays
very competitive, especially considering the feature set. Nothing feels
better than saying to the MIS director at a large franchise that yes,
indeed we do use a SQL database backend! LOL, its the same one used in
the A1 Abrams Main Battle Tank!!!

One station deployments account for about 5% of our sales (average is 3)
and we deploy it exactly like we deploy larger systems with the
exception that the software is connecting over localhost. When they
need to get another station setup, its easy as pie.

* Extremely Stable
* Zero Admin
* Compliant
* Free
* Excellent support
* Easy to deploy/embed

Our software is currently using IBX to connect and we've had no problems
as yet, but we will be porting over to IBO this year. I hear FIBPlus is
a good set as well, but I like IBO Dataset compatible comps that are
basically like IBX on steroids to me.

SQL isn't so bad. That is where MS Access comes in! I use the query
designer to make queries that I can then tweak in IBExpert.

--

Warm Regards,

Lee

trevorradke wrote:

> We have a point-of-sale app with a little over 1000 installed sites.
> Currently about 80% of those are standalone computers and the other
> 20% are network installs. Most of the networks are simple 2-3
> computer peer-to-peer Win 98, 2000, or XP. We have a handful of
> installs (10 or so) where we are dealing with a dedicated server and
> anywhere from 10-50 workstations.
>
> For the last 7 years our app has been using dbase files with Apollo
> index files. This has been okay but now we are doing a total re-write
> of the software using Delphi 7 and wanted to look into using other
> databases. I need some advice as to why I would want to use FB.
>
> Nobody here is really familiar with SQL (I cut most of those classes
> back in college 13 years back). We just do most of our work with
> dbtable.seek statements and dont really make that much use of queries
> although we will be building more filtering capabilities into the new
> software.
>
> My basic question is would FB actually be better than something like
> Advantage or Paradox or dBase or other "desktop databases" and why or
> why not?
>
> Since most of our clients do not run networks, is FB total overkill?
>
> Will a FB database be faster or slower than what we are used to with
> dBase?
>
> Our clients are basically morons when it comes to computers so is
> this idiot proof to install and set up? We do 1-2 installs a day and
> send out 15-20 evaluations off our web each day so I need this to
> install and configure itself.
>
> Is FB bullet proof or do we need to be concerned with the database
> corrupting from time to time? If so, how complicated is it to repair?
>
> Bottom line...what would you do if you were me and why? Once we
> commit to something I need to stick with it for another 5-7 years and
> I don't want one app for stand alone systems and one for
> networks...it needs to work for both and I need it to be very fast,
> super easy, and exceptionally reliable! What do I do?
>
> Any and all comments are appreciated as we try to move out of the
> dark ages.
>
> Trevor
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
> .
>