экспериментирю с битой базой ( http://www.sql.ru/forum/1123828/validaciya-indeksy-ubity-poter-net )

запускаю gbak (2.1.6) из консоли ( -b -v )
gbakgbak: writing index RDB$FOREIGN30
gbak: writing index RDB$FOREIGN31
gbak: writing data for table OBJ_TREE_ACCESS
gbak: ERROR:value exceeds the range for valid dates
gbak: ERROR:gds_$start_request failed
gbak:Exiting before completion due to errors

то же при -b -v -y by.txt

запускаю gbak (2.1.6) из консоли ( -b -v -se localhost/3050:service_mgr)
gbakgbak: writing index XPKBUDGETDAT
gbak: writing index XIF827BUDGETDAT
gbak: writing data for table BUDGETDAT
gbak:428 records written
gbak: ERROR:value exceeds the range for valid dates
gbak: ERROR: gds_$start_request failed
gbak:Exiting before completion due to errors


Неужели графы сохранения разные?..

запускаю gbak (2.1.6) из консоли ( -b -v -se localhost/3050:service_mgr >b1.txt 2>b2.txt )
STDERR aka b2.txtgbak:293 records written
gbak: writing index RDB$PRIMARY17
gbak: writing index XPKOBJ_TREE_ACCESS
gbak: ERROR:value exceeds the range for valid dates
gbak: ERROR: gds_$start_request failed
gbak:Exiting before completion due to errors


Наконец, делаю ( -b -v -se localhost/3050:service_mgr -y d:\...\bse.txt )
Сохраняет опять как в ранних вариантах, вплоть по
bse.txt writing data for table OBJ_TREE_ACCESS

То есть налицо потеря GBAK'ом рандомного куска текста - причем наиболее критичного, месте возникновения ошибок - при работе с консолью и через сервисы.

Ниччо не понимаю, вроде же погода назад именно это исправляли ?

Ну и вишенка на тортике - IBExpert, бакап, TCP, лог детальный, на экран
IBEgbak: writing data for table FUNDSSRC
gbak:35 records written
IBE: Backup completed. Current time: 13:22:19. Elapsed time: 00:00:33


При этом текст ошибки показывается отдельным окошом, но -:-( - в лог не попадает, да и лог снова получается урезанный.

И вдобавок на диске остается недописанный открытый сервером (fb 2.1.6 win32 SS) FBK-файл, который нельзя удалить.
Сервер его удаляет только после выхода из IBE - видимо IBE держит незакрытый сервис менеджер.
Что интересно, если после этого не закрывая IBE в нём эту же базу сбакапить в другой файл - то этот другой файл нормально удаляется, но первый остается висеть. И сам IBE выбрасывает
IBEError Message:
----------------------------------------
Invalid pointer operation

[00403681] System.TObject.FreeInstance + $1D
[0042587B] Classes.TBasicAction.Execute (Line 8076, "Classes.pas" + 3) + $7

Предположительный сценарий возникновения ошибки:

1. Firebird 1.5 win32 & ODS 10.1 (дата создания 2006)
2. Поле TIMESTAMP, в которое попало некорректное (скорее всего заоблачно высокое, типа Сегодня плюс 10М дней) значение.
3. Клиент был написан либо на Delphi 7 + BDE, либо на Delphi 2006 + DBX-3, установить когда это значение было внесено в БД - не получится.

Если эту таблицу отдельно можно чем-нибудь сдампить, каким-нибудь хирургом - то не вопрос, в этой таблице 10 записей из 6 коротких полей, и в них ничего секретного нету.

Либо может быть удастся однажды создать такую БД, написав генератор, но это не сейчас.

hvlad,

попробую при случае, он в дальнем чулане на резервном сервере остался "до кучи"

kdv,

тот же самый результат.

Вопрос: как должна была сборка мусора повлиять на ошибку "имеющиеся данные не соответствуют формату или ограничениям" ?

pastor,

да я это уже сделал, клиенту отослал. Вопрос уже скорее про некорректное поведение gbak и IBE при такой ошибке.

а вот за информацию про диалекты - спасибо, буду пробовать и с разными диалектами.

pastor,

2.1.6 - не современная? однако...

kdv,

"мусор" при его зачистке - просто зачищается. Помечается свободным местом.
Я могу представить себе чтение стобцов BLOB id из мусора - но и только. Остальные мусорные столбцы считывать и проверять только для того, чтобы выкинуть на свалку

вот тебе тупой пример: тупо поле Integer
половина записей - в мусоре.
навешиваем check constraint col1 < 0
или навешиваем FK constraint
перед этим удаляем все несоответствующие новому условию записи (потому и половина таблицы в мусоре)

и что теперь, как только выстрелить sweeping interval все старые, мусорные записи будут проверяться по новому ограничению? И когда выяснится, что не соответствует - сборка мусора будет отменена, потому что старые, ранее существовавшие данные, не проходят проверку новым ограничением?

Ну бред же.

dimitr,

Cпасибо.
Попробуем прикинуть значение "вилкой" :-)

Я так понимаю, что никаких функций, которые возвращают столбец как сырые двоичные данные без проверок и интерпретаций, в FB нету?

IBE-2007 на FB 1.5 сделал успешный back-up (как в режиме dialect 1 так и 3), и отказался в обоих диалектах делать select *

hvlad,

iSql 1.5SQL> select date_pass_change, date_pass_change_per from obj_tree_access
CON> ;

DATE_PASS_CHANGE DATE_PASS_CHANGE_PER
========================= ====================

29385-10-28 00:00:00.0000 9999999
29384-12-31 00:00:00.0000 99999
2005-10-14 14:24:53.0000 30
2014-03-20 00:00:00.0000 30
2005-10-31 12:21:34.0000 30
2005-10-14 14:25:29.0000 30
2005-12-16 00:00:00.0000 30
2005-12-10 00:00:00.0000 30
2281-10-01 00:00:00.0000 99999
2281-10-01 00:00:00.0000 99999


Ещё что-то для воспроизведения некорректного поведения GBAK 2.1.6 при такой ошибке нужно ?

kdvp.s. экспериментировать, указывая или нет -g, хоть с битой, хоть с целой базой, не вижу никакого смысла.

таки оказалось нужно, чтобы понять, где именно были некорректные данные.

заодно и обнаружилось некорректное поведение gbak - пропадание части информации об ошибке

pastorAriochpastor,

2.1.6 - не современная? однако...

ну таки да.

мы почти всегда через версию идем.

4.0 -> 5.6 -> 0.99 -> 1.5 -> 2.5

Ну а мы надеемся на 3.1, а пока не запрещаем клиентам переходить на 2.5.3 если им хочется, но и не поощряем.
Так что, как видишь, мы просто пропустили другую фазу, чем вы.

Да, кстати, вы идёте через ДВЕ версии: через 2.0.х и через 2.1.х

pastor,

а у нас полгода назад пришел заказчик с ноутбуком.
база было ODS 9
посмотреть из соседней комнаты приходили DD

клиенты - они всякие бывают