"Ovchinnikov Vasily" ...
> Horsun Vlad пишет:
> > "Ovchinnikov Vasily" ...
> >
> >> gbak: writing data for table PB_SALE
> >> gbak: ERROR: message length error (encountered 288, expected 284)
> >> gbak: ERROR: gds_$receive failed
> >> gbak: Exiting before completion due to errors
> >
> > Меняли формат записи. Скорее всего дропнули поле или укоротили его
> > длину, т.к. судя по текущему формату длина записи 284 байта, а в данных
> > 288. Можно попробовать вернуть как было. Тем же способом как меняли.
>
> К сожалению, не представляется выяснить, кто и чего менял. Не все
> изменения, увы, регистрируем в рабочей документации. А так никто не
> сознается. Быстрее данные, наверно, перезалью в новую базу.
Они всё равно не прочитаются целиком. Разве что вычислить RDB$DB_KEY
проблемной записи и читать таблицу без неё
> Хотелось бы механику возникновения этой ошибки понять. При наличии
> нескольких одновременно подключенных коллег теоретически могли менять
> метаданные НА ХОДУ. Обычно, следим за этим (все в одном помещении сидим)
> и просим всех ,кроме инициатора изменений, отключиться от базы. Но тут
> получается, что после изменения метаданных (ну, пусть поле урезали,
> например) кто-то ухитрился вставить в PB_SALE новую запись по старому
> формату. Так?
Вряд ли. Скорее это может произойти при самостоятельном ковырянии в
системных таблицах. Например, прописали меньшую длину строковому полю.
Или "сменили" тип поля с numeric(15) на numeric(5). А в реальных данных
сидят значения длинее нового определения.
--
Хорсун Влад
