Такого режима нет и не будет - в ASA по другому сделана архитектура компиляции и работы хранимых процедур (процедуры компилируются на момент запуска сервера при первом к ним обращении), поэтому можно считать, что на момент компиляции ХП выполняется только проверка на SELECT-ы, возвращающие наборы данных из этой процедуры и если они ссылаются на существующие таблицы (то есть ей удалось построить план выполнения) и в ХП нет явного описания полей через RETURNS, то ASA сама составляет список result-полей для процедуры.

С одной стороны это ведет к тому, что нет никакого контроля ошибок в ХП и они будут выявлены только на момент непосредственного выполнения, но с другой стороны это с лихвой покрывается такими приятными вещами, как отсутствие требований периодических перекомпиляций ХП и сбора статистики, шустрой работой динамического SQL, возможностями видимости таблиц after триггеров Inserted и Deleted в вызываемых ХП и т.д. и т.п. В общем лично я в конце концов пришел к выводу, что после всего, что возможно при такой архитектуре работы ХП я с удовольствием закрываю глаза на отсутствие проверок при компиляции. Хотя в принципе им можно на форум выложить просьбу расширения функциональности, чтобы на компиляцию ХП при ссылках на отсутсвующие в БД обьектах выдавались предупреждения (думаю этого вполне достаточно). Вот только руки никак не дойдут :)

MasterZiv ASCRUS
это с лихвой покрывается такими приятными вещами, как отсутствие требований периодических перекомпиляций ХП и сбора статистики, шустрой работой динамического SQL, возможностями видимости таблиц after триггеров Inserted и Deleted в вызываемых ХП и т.д. и т.п.


Я как-то не могу разделить такого мнения. Потому что я считаю, что возможность выявления ошибок на этапе компиляции - это очень важное свойство для всех языков программирования, и для СУБД в том числе. При этом я как-то не понимаю, почему поздняя компиляция (не оптимизация, а именно компиляция и разшенешие имен объектов БД) должна быть необходимым условием для таких свойств, как
отсутствие требований периодических перекомпиляций ХП

отсутствие требований периодического сбора статистики

шустрой работой динамического SQL (вообще как-то ни при чем).

возможностями видимости (просто каких-то) таблиц ...

Я не знаю как в ASE, а вот в MSSQL именно из за ранней компиляции ХП с проверкой на обьекты и сохранением получившихся планов именно по всем этим пунктам возникает множество досадных проблем, которые вынуждают разработчиков стараться отказываться от использования динамического SQL в ХП, извращаться с передачей данных в триггерах из Inserted и Deleted в вызываемые из под триггеров процедуры и вешать агентов на периодическую перекомпиляцию ХП, чтобы обновить их статистику и планы для избежания проседаний и тормозов при их выполнении в случаях, когда информация в БД значительно изменилась, а процедуры продолжают выполняться по старым и уже не эффективным планам.

Позволю себе не согласится исходя из личного опыта общения с MSSQL.