> 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é
