На самом деле не все так однозначно хорошо. В некоторых местах Sybase сам не рекомендует использовать sp_hidetext.

Я не помню точных мест, но где-то периодически такое встречалось. Можете воспринимать это как недостоверные слухи или сказки. Что-то там было типа для процессов upgrade-а на верхние версии, применения EBF , что-то в этом виде. Короче для всех случаев, когда нужно будет перекомпилировать процедуру, а это сейчас происходит чаще и на сколько я понимаю иногда в автоматическом режиме.

Вот например, возмем такую процедуру :


Если залить это дело на сервер, такая процедура превратится (в современном ASE) в


Это появилось кажется с 12.0.
Это ASE делает для того, чтобы если ему понадобится ПЕРЕКОМПИЛИРОВАТЬ процедуру, то в запросе не выводилось бы новых полей, которые могут добавится в таблицу во время с момента создания процедуры до момента перекомпиляции. (В документации сказано, что до пересоздания процедуры новые поля не должны появляться).

Т.е. с этого времени, когда эта фича появилась, ASE может по своему усмотрению перекомпилировать (т.е. пересоздавать) из ихсходников процедуры. Но если они похайжены -- вот тут вопрос, может ли ASE это сделать.

moris
Вот если еще еще в доке покажете место, где сказано, что ASE сам по своему усмотрению автоматически пересоздает SP, то будет еще лучше..


Знал бы конкретное место - уже бы показал.

moris
(sp_recompile - не катит, так как юзер явно запускает такую команду а не сам ASE)


sp_recompile НЕ пересоздает и перекомпилирует процедуру, а лишь делает невалидным план ее выполнения. Это разные вещи, другой, более простой этап. А при компиляции дерево выполнения (пере)создается в sysprocedures.

moris
Это действительно так, только это называется резолюция при формировании дерева запроса в процессе компиляции SP.


Это было так не всегда, и это было введено именно для тех целей, что я описал.

moris
А касательно ограничений на которые можно попасть так могу только сказать на что сам напоролся. При кросплатформенном дампе должны все SP перекомпилироваться.


Ну вот например.


moris
Но hiden SP не перекомпилируются (понятно почему) и никакого сообщения об этом не выдается (сыроват еще кросплатпорменный дамп), а потом самое интересное наступает когда пытаешься запусить такую неперекомпилированную на новой платформе SP....


Вот и я о чем. Я бы не рекомендовал хайдить в современном ASE процедуры.
Можно обойтись и просто невыдачей прав пользователям на системные таблицы.

morissp_recompile - Causes each stored procedure and trigger that uses the named table to be recompiled the next time it runs.

Это слова из документации, для "лохов" грубо говоря. Верны они в первом приближении. Да и путаница в терминах все время в документации, например, sp_recompile к компиляции никакого отношения не имеет.

По сути с исполняемыми объектами ASE делает следующее:
Компиляция. Производится при создании соотв. объекта ИЛИ В ДРУГИХ СЛУЧАЯХ (об этом и речь, когда еще это может случаться).
Строится структура выполняемого объекта во внутреннем представлении.
Разрешаются имена объектов в их идентификаторы.Результат сохраняется в sysprocedures :

sysprocedures
Qualifier
(all databases)
sysprocedures contains entries for each view, default, rule, trigger, procedure, declarative default, and check constraint. The plan or sequence tree for each object is stored in binary form. If the sequence tree does not fit into one entry, it is broken into more than one row. The sequence column identifies the sub-rows.


Построение плана запроса. Производится при первом выполнении объекта, делает это оптимизатор. Строятся планы запросов в терминах оптимизатора, с конкретно используемыми индексами и способами доступа, с порядками выполнения и т.п. (то, что выводится по set showplan on).
Результат сохраняется в процедурном кэше , который естественно в памяти.
Также может сохраняться в виде Abstract query plan в sysplans.


Подгонка плана запроса. Производится при каждом выполнении объекта, делает это обработчик запросов. (не очень сейчас важно, что это)

То, что делает sp_recompile, или выполнение процедуры с опцией WITH RECOMPILE - это относится ко второму пункту, а именно - соответствующий элемент в процедурном кэше помечается как невалидный, что приводит к тому, что в следующий раз, когда объект будет выполняться, для него выполнятся все шаги, начиная со второго (а не только третий).

А то, о чем речь идет в топике - это пункт первый, и это никак не связано с sp_recompile.

Да по мне так пофигу, хоть как что называй, можно хоть "creational process 1"
& "creational process 2". Главное что sp_recompile к теме разговора не имеет отношения.