Страница 1 из 1

переход с IB на FB

Добавлено: 17 сен 2007, 03:59
SeventhSon
сделал b/r.(с первого раза конечно не получилось,пришлось делать экспорт в скрипты и править IB).заработало.и обнаружилось следующее.на рабочей базе открываю текст процедуры,делаю несущественные изменения(например коммент вставляю) и при компиляции выдаёт ошибку.я почитал про BLR немного.как я понял текст процедуры абсолютно никак не связан с её двоичным кодом.т.е. можно залезть в системные таблицы и в тексте написать "фига",бинарный код будет продолжать работать.получается при b/r просто переносится текст и бинарный код,перекомпиляции процедур не происходит?
если это так то как можно принудительно всё перекомпилирвать на новом сервере?ведь в новой версии возможно что бинарный код более оптимален.
может я сильно заблуждаюсь,но это не потому что я такой тупой,просто не нашёл нигде об этом никакой информации :oops:

Добавлено: 17 сен 2007, 08:02
Dimitry Sibiryakov
Раз уж все равно делал экспорт в скрипты, так мог бы прямо эти скрипты и скормить FB. А данные потом перелить IBDataPump-ом.

Re: переход с IB на FB

Добавлено: 17 сен 2007, 08:14
dimitr
SeventhSon писал(а):ведь в новой версии возможно что бинарный код более оптимален
сынок, это фантастика (с)

Добавлено: 17 сен 2007, 09:33
kdv
если это так то как можно принудительно всё перекомпилирвать на новом сервере?
попробуй IBExpert или любой другой инструмент, который позволяет перекомпилировать процедуры.
ведь в новой версии возможно что бинарный код более оптимален.
разве что коды для новых конструкций добавлены. Которые и так появятся при компиляции новой или измененной процедуры.

Добавлено: 18 сен 2007, 04:57
SeventhSon
2 Dimitry Sibiryakov:я подправил проблемные места в IB,и-b/r.чем способ с перезаливкой данных лучше?ведь медленнее-это наверняка?
2 dimitr:ну да.про оптимальность это я нафантазировал наверное:)хотя если код1 компилился допустим для 386 а код2-для
586 то разница ведь будет?ну чисто теоретически хотя бы!новые инструкции появляются не только в языках программирования,у процессоров тоже.с 32 на 64 ведь перешли(ax->eax)?mmx команды добавляли?может завтра на 128 перейдут?хотя с другой стороны если проверено и работает зачем менять

kdv и товарисчи,я извиняюсь за настойчивость, но вы мне не ответили ли я вас не так понял:oops: что же получается?при апгрейде через b/r меняется ods а бинарный код и исходники копируются и ничего не перекомпилируется?только вручную?

Добавлено: 18 сен 2007, 08:02
Dimitry Sibiryakov
SeventhSon писал(а):чем способ с перезаливкой данных лучше?ведь медленнее-это наверняка?
Тем что IB и FB - разные сервера и могут быть несовместимы (на что ты и нарвался). Ты, случайно так, с MS SQL в Oracle не пытался БД перенести через бэкап-рестор?

Вряд ли отлов глюков после неудачного переноса будет быстрее перекачки данных.

Добавлено: 18 сен 2007, 08:08
dimitr
SeventhSon писал(а):если код1 компилился допустим для 386 а код2-для
586 то разница ведь будет?
ты не путай бинарный код процессора с интерпретируемым байт-кодом в IB/FB
SeventhSon писал(а):что же получается?при апгрейде через b/r меняется ods а бинарный код и исходники копируются и ничего не перекомпилируется?
да, конечно. Ибо совместимость по BLR гарантируется.

Добавлено: 18 сен 2007, 10:12
kdv
что же получается?при апгрейде через b/r меняется ods а бинарный код и исходники копируются и ничего не перекомпилируется?
да, потому что перекомпилировать blr не зачем. старые фичи и так поддерживаются. новый ods это расширение, а не модификация.

а вот разница в blr как и в sql у последних версий ib и fb - да, есть, поэтому blr может быть _несовместим_, как туда, так и обратно, о чем тебе и сказали.