авторCREATE OR ALTER PROCEDURE b (с новыми параметрами) - ошибки зависимостей не будет. Будет просто неправильный blr у процедуры "a".

Кстати да. С одной стороны - как бы удобно. С другой - дикий источник ошибок. Особенно для тех, кто привык к проверке параметров. Правда, тут ноги растут скорее всего раньше, чем с 2.0. Я проверил на 1.5 и с удивлением обнаружил, что он тоже дает это сделать.

Думаю, что это скорее жирный минус, чем плюс. Если раньше контролировал сам сервер, то теперь это должен делать программист. Ну или сторонние утилиты, вроде IBExpert-а.

Угу, они давно уже открыли для себя execute block.

Неужели и процедуры перестали использовать? Одни сплошные блоки?

СУБД обновить решился,

Не решился. Все это тесты и пробы.. Перед тем как ставить "людям" проверять и проверять.. С возможностью вернуться назад, если глюки попрут.

У древнего IBExpert есть одна фича - возможность выполнять alter procedure в скрипт-execute когда есть коннекты, ее использующие, и по идее такой альтер должен выдавать ошибку. С какого то момента, очень давно, автор посчитал эту фичу багом и исправил.

Кстати, насчет изменения параметров процедуры без удаления ссылок на нее из других процедур.

Да, так делать можно в смысле что сервер это пропускает.

Но может так делать нельзя? Может это ведет к глюкам, ошибкам, порче базы да и вообще к чему угодно? Мало ли чего сервер пропускает сделать.. Вон, запрос времени по стандартной фиче из FIBPlus-а через клиент от пятерки к серверу просто рушит этот сервер. Причем все компилируется, а галочка по умолчанию стоит. Тут как на минном поле..

Если так делать можно, то пусть разработчик официально скажет - да, это допустимый путь.

автор лично мне эта ошибка периодически помогает, когда забываю в селективной процедуре поставить suspend - выборку напишу, а suspend забуду.

Очевидно, что ты не пишешь даже минимально не то что сложных - а просто объемных процедур. Если бы писал - привык бы не забывать. Так как там много чего можно забыть.

авторОпытные и осторожные люди такой переход делают не скачком, пусть даже с пробами, а
постепенным переводом пользователей с одного сервера (где крутится старая версия) на
другой (где уже новая).

Как ты себе это представляешь? На одном предприятии. Репликацию между двумя базами делать только ради этого что ли?

авторОн об этом уже сказал в release notes

Ссылочку, номер страницы.

YuRock , не подаю.

(ирония)
Dimitry Sibiryakov, короче надо дать вам 100 000 баксов и вы за пару дней сделаете репликацию базы с 300 таблицами, 800 процедурами, при этом гарантируете ее правильную работу и отсутствие каких-либо глюков - чтобы было точно известно - любой глюк от новой версии сервера, а не от сбацаной наспех репликации.. Тупо, конечно, спроектировано. Надо было парой тройкой таблиц обойтись и вообще хранимые процедуры не создавать. А то и вообще хранить все в одной таблице. В блобах. (/ирония)

dimitr, есть ли какие-то стандартные средства проверки некорректности зависимостей или это надо делать вручную либо с использованием сторонних утилит?

Ну вроде какой-нибудь команды check procedures или ключа у какого-нибудь gfix?

WildSery, какой вы занятный человек - за всех думаете, за всех отвечаете..