Well, there are written books about that subject. I haven't even read any
of them, so don't take my word for being the final answer.

Basically, when working with Access (or at least Paradox, I've never used
Access) it is common to use tables. They're fast and flexible and you see
everything in a grid. With Firebird, you "never" want all this information,
you always specify what you want before you get it. 100 or 1000 records are
normally only appropriate for reporting, for interactive use you normally
specify which fields you are interested in and then select one or a handful
of records.

That is, Access basically use

SELECT * FROM TABLE

upon which you locate what you are interested in, whereas Firebird use

SELECT PK, Name, e-mail FROM TABLE
Where Name = 'Antonio Parrotta'

to obtain only records that are of interest. If you add appropriate indexes
to the tables you use, this is normally enough to get decent performance
regardless of table size. If you have an index on name and there is only a
few Antonio Parrottas in the database the above query ought to be subsecond
whether the table contained 10 or 100000000 records (well, I haven't
actually tried a database that big).

And then, c/s is designed for having several users, whereas desktop
databases are primarily for one user only. So you need to learn about
transactions (take a look at some of the community sites - e.g.
www.ib-phoenix.com, www.ib-objects.com or www.cvalde.com, I don't remember
where to find such information but they ought to have something) and start
using generators rather than auto-increment fields.

It will be a learning curve - both for you as a programmer and for your
users when they no longer will be able to select from "spreadsheets", but
in the end you will probably prefer c/s over desktop programming and your
users become more effective.

Good luck,
Set
At 11:20 30.10.2002 +0100, you wrote:

>Svein,
>sorry for the question, but I never programming in terms of c/s databases,
>so can you tell me how it works and what is the main difference?
>thanks for your time!
>Antonio
> Svein Erling Tysvaer <svein.erling.tysvaer@...>
> wrote:Antonio,
>I think it is just a matter of forgetting desktop databases and start
>thinking in terms of c/s databases. Forget tables and start thinking sets
>of records. 5000 records is nothing in the world of c/s. E.g. I work at the
>Cancer Registry of Norway and we have registered every single cancer in
>Norway since 1953 (well, almost) - in total over 1 million - all this in
>one single database. The same database contains some information like the
>address of all hospitals in Norway and whatever else is natural to have in
>that database. Still, at 1Gb with a simple structure I don't even think it
>qualifies to be called a big database in Firebird terms. Sure, we have to
>be a bit careful about which queries we send off to the server (i.e. check
>the plan before execution), but in general we do not have any performance
>problems. Firebird can handle huge volumes if you treat it nice ;o)