iBase.ru Forum

Чтобы перейти от firebird 1.0.0338 к 1.0.3.972 достаточно ли просто переустановить сервер, или же надо в 1.0.0338 делать бэкап а в 1.0.3.972 рестор?

потрясающий вопрос. Во-первых, 338 билд был нерекомендован к использованию почти сразу после его выхода, из-за проблем с обновлением метаданных. Во вторых, переход между минорными версиями обычно не требует b/r. Однако, я бы просто на всякий случай сделал бэкап на старой версии и рестор на "новой" 1.03 просто чтобы убедиться, что с метаданными и данными все в порядке. Потому что судя по письму, бэкап и рестор Вы вообще не делаете, так?

А как проверить целостность метаданных и данных после бэкап/рестора?

Что касается бэкап/рестора старой базы то он делался ежедневно автоматом

Что касается выбора версии сервера, это было сделано задолго до меня в 2001 г. а тогда другой просто не было.
Сейчас переход даже к версии 1.5.3 проблематичен.
В базе некоторые объекты имеют имена совпадающие с зарезервированными словами.
Хотелось бы добиться стабильности работы сервера с минимумом головной боли.

После установки сервера 1.0.3.972 запросы стали отрабатываться почему-то медленнее.

А как проверить целостность метаданных и данных после бэкап/рестора?

b/r прошел, ошибок нет? ну и славно.

После установки сервера 1.0.3.972 запросы стали отрабатываться почему-то медленнее.

а Вы как его ставили-то? небось конфиг сервера убили?

Если честно, то да
А есть ли какие-то рекомендованные значения для переменных ibconfig?
tmp_directory я вписал

А есть ли какие-то рекомендованные значения для переменных ibconfig?

явно - нет.
http://www.ibase.ru/devinfo/ibconfig.htm

подозреваю, что параметр DATABASE_CACHE_PAGES был в старом конфиге больше, чем 2048 страниц. Вопрос - сколько. Тут нужно считать размер страницы БД и размер кэша, чтобы понять, сколько памяти сожрет изменение этого параметра (сколько есть в системе, и сколько можно дать).

На будущее - никогда не ставьте новые версии в тот же каталог. Или, перед установкой делайте резервную копию текущего каталога ФБ.

Столкнулся с проблемой:
В версии сервера 1.0.0.338 следующий запрос работал
select alltrim(field1), field2, sum(field3)
from table1
where field1="babay"
group by field1, field2
где alltrim - пользовательская функция
в версии 1.0.3.972 выдает ошибку invalid column referencе на колонку alltrim(field1)
В то же время запрос
select alltrim(field1), field2, field3
from table1
where field1="babay"
в версии 1.0.3.972 работает нормально

и не будет.

select alltrim(field1), field2, sum(field3)
group by field1, field2

группировка по каким столбцам-то? с какого бодуна по field1?

Понял ошибку
Однако конструкция:
select alltrim(field1), field2, sum(field3)
group by field1, field2
в 1.0.0.338 работала без проблем

в коде InterBase было много таких случаев, когда "кривой" SQL вроде бы проходит, но на самом деле возвращает "бессмысленный" результат. В Firebird 1.02, 1.5, 2.0 и 2.5 последовательно проводится ужесточение по синтаксису SQL, с тем чтобы парсер не пропускал подобные некорректные конструкции, и максимально соответствовал стандарту.