> I would first rule out the possibility that the change was not
> committed. Both DDL and gbak are transactional, so not having committed
> the table change would result in that change not being part of the gbak
> backup.

Thank you, Mark.
So, this is not usual and somehow I should be concerned, or at least
irritated.
I am pretty sure that the table change has been committed, but of
course I did not check it, specifically. I only checked that there
was no old transaction in the statistics.

I was adding the columns using IBExpert, then also created and ran
several Stored Procs.

All the while, the database was in production and the users were
inserting/updating/deleting records; I tested all actions and scripts
on a dummy database with current data before, so I thought that for an
exception shutting down database from production was not necessary.

I backed up the database several times in a series of several days,
did tests with the locally restored backups and only much later
noticed that the new columns were missing in the local backup - all
the new records were in, though.

Server and clients are 2.5.3.26778.
Gap between OT and NT was less than 100 when I checked (for 50+
concurrent users) and OT and OAT constantly moving.

Is there something else I can check short of trying to reproduce this?

Note: I am off to holiday in 2 days, so probably can only react on
your advice in a couple of weeks.

best thanks in advance!

André