Столкнулся с такой проблемой при подъеме старых версий БД (Firebird 1.5, ODS 10.1) до Firebird 2.5, ODS 11.2
В таких случаях делается сначала backup базы, затем restore.
restore можно делать двумя путями:
- используя gbak.exe
- используя Services API (доступен для программиста)
В чем проблема:
для gbak в firebird 2.5 досупен параметр -FIX_FSS_METADATA, однако за ним идет указание кодировки, например Win1251
для Services API в опции запуска восстановления БД добавлен параметр isc_spb_res_fix_fss_metadata = 14; указания на кодировку не предусматривается.
В результате восстановление БД через gbak происходит нормально, а вот через Services API падает без сообщения об ошибке.
В интернете полно ссылок на то, что "теперь в Services API также доступны опции isc_spb_res_fix_fss_data и isc_spb_res_fix_fss_metadata", например, тот же трекер , однако нет ссылок об их успешном применении.
Собственно вопрос:
сталкивался ли кто-то с подобной ситуацией? что еще и в какую структуру нужно добавить, чтобы восстановление БД через Services API закончилось успешно?

вот последние строчки лога восстановления:
gbak:restoring generator S_LZTEMPL_GEN_ID value: 0
gbak:restoring generator S_ORGANIZ_GEN_ID value: 0
gbak:restoring generator S_PERSONS_GEN_ID value: 0
gbak:restoring generator S_RRDATA_GEN_ID value: 0
gbak:restoring generator S_RRITOG_GEN_ID value: 0
gbak:restoring generator S_TEMP_GEN_ID value: 0
please retry, giving a database name

после генераторов может восстановиться несколько процедур, например:
gbak:restoring generator S_RRDATA_GEN_ID value: 0
gbak:restoring generator S_RRITOG_GEN_ID value: 0
gbak:restoring generator S_TEMP_GEN_ID value: 0
gbak:restoring generator B_GEN_TEMP value: 0
gbak:restoring generator PM_GEN1 value: 0
gbak:restoring generator MG_PRIMARY value: 0
gbak:restoring generator GEN_V_LOG_ID value: 0
gbak:restoring parameter CNT for stored procedure
gbak:restoring stored procedure L_EXP_SC_OBJ
gbak:restoring parameter ID_HIER for stored procedure
gbak:restoring parameter ID_USER for stored procedure
gbak:restoring parameter CNT for stored procedure
gbak:restoring parameter ID_TR for stored procedure
gbak:restoring parameter CNT_TR for stored procedure
please retry, giving a database name

но в этом месте плюс-минус несколько десятков строк падает стабильно
+ генераторы имеют ненулевое значение, это можно посмотреть по аналогичному логу при восстановлении через gbak

14 - это два байта?
простите, я не понял ответа.

Иными словами, найти в исходниках firebird структуру буфера и заполнить у себя по нужному адресу длину строки и саму строку?

С удовольствием бы почитал.
К-сожалению, на офф сайте только API Guide только от InterBase 6.0.

Dimitry SibiryakovСавченко АлександрК-сожалению, на офф сайте только API Guide только от InterBase
6.0.
И принципы заполнения всякоразных буферов параметров (dpb, tpb, spb) с тех пор ничуть не
изменились.


Ну я понял - по аналогии.
А все же, мог ли я заранее узнать, что для этой НОВОЙ опции нужно заполнять именно так буфер, а не иначе? К-примеру, не два байта на строку, а один или четыре?
Или единственный способ - спросить на форуме?

Что же, спасибо за помощь. Будем пробовать.

Еще раз спасибо.
Добавил в буфер параметр кодировки по аналогии с другими параметрами, restore прошел успешно.

Да, мы изначально этот момент учитывали, а сейчас вопрос был именно в убыстрении процесса backup/restore, в том числе, баз со старыми ODS