Antonio,

> I'm agree with you: all tables in a unique firebird file is the best choice.

> My problem is that I've numerous programs that utilize one firebird file
> each.

That problem is easy to solve. Place all of the tables in one
database and use an alias for that database in every application.

> There are tables that are drawn for a specific program, but there are
> some tables that are "common" to all programs (example:
> "municipalities").  An user can utilize one program, two programs, four
> programs, and so on, on the same computer and each program hav its
> database.fdb: if I must vary a value of one "common tables", I must send
> an update for every program and to each user; but if the "common tables"
> are in a unique, separate database, I can update one file only.

This is not a database design. You are treating "database" and
"spreadsheet" as though they were the same animal. Very definitely,
they are not the same.

Think "relational", because Firebird is a relational database system.
Tables (a.k.a. relations) can be *related* to one another by way of
foreign keys. Data from tables containing compatible fields (columns)
can be connected during run-time queries by JOINs or UNIONs.

> There are also "static" tables containing storical movements, and is not
> necessary periodically to back-up them.

At the same time, it does no harm for them to be included in the
backup of your current data. It makes sense for them to be in the
same database as the active tables if you need to refer to them from
your applications.

> These are the reasons that push me to look for a solution, I hope to
> have been clear.

The thing that seems clear to me is your confusing "tables" with
"databases". The whole point of using a relational database is to
have all of the interrelated data available to each individual client
connection.

> For release 2.5 and not 3.o, I have been studyng Firebird for some
> months, and I've not experience: I now plan the job to develop, later I
> will verify the new releases.

The question of whether you use 2.5 or 3.0 is not relevant to your
problem. Spend some more time understanding how a relational database
works - and forget your preconceptions from previous work you have
done using spreadsheets or fiel-based data storage systems.

Helen


---
This email has been checked for viruses by AVG.
https://www.avg.com