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