автор1. Первое впечатление, что ASE это все-таки более надежная база, корректно отрабатывающая более глубокую вложенность, хотя бы тех же хранимых процедур. У меня перестали работать многие процедуры, которые вызывали другие хранимые процедуры. Процедура без всякого кода шибки просто ничего не делает. :( Приходится переписывать без вложений, тогда все Ok.
Быть такого не может, у ASA с поддержкой ХП все в порядке. И возможен вызов процедур любого уровня вложенности. Почему перестали работать процедуры - это уже вопрос установок опций совместимости вашей БД с ASE. Советую Вам прочитать главы о совместимости ASA c TSQL и ASE в BOL, там прямо по опциям расписано, что надо включать, чтобы добиться совместимости. По умолчанию в созданной БД полной совместимости с ASE нет. Плюс Вы всегда можете пройти дебаггером неработающие процедуры и выявить, где что не так выполняется. Дебаггер навороченный и Вам здорово пригодится в такой работе.
P.S. Кстати думаю это не критерий надежности. Надежность все таки - это когда сервер и данные БД никогда и не при каких обстоятельствах не падают.
автор2. Второй мелкий недостаток ASA при компиляции техже процедур, т.е. при создании хранимых процедур в ASA через ISQL, а их естественно не один десяток, нельзя в разных процедурах использовать одинаковые имена открываемых курсоров. Пришлось выписать имена всех курсоров и делать их уникальными, чтобы переносить процедуры одним скриптом. :(
Опять же читайте в BOL про DECLARE CURSOR (TSQL). Там описаны все что не поддерживается для ASE-совместимости в ASA. Например, нет глобальных курсоров, область видимости курсоров ограничена областью их блока обьявления (BEGIN...END), и т.д. Так что странно - в разных процедурах можно использовать одинаковые имена курсоров, так как они будут видны только для своих процедур, где были обьявлены.
P.S. Навскидку дурацкое подозрение: у Вас кстати в скрипте между ХП оператор GO стоит ?
автор3. Ну еще не поддержка в ASA % это вообще не считается, у меня всего 3-4 таких использования.
Ну это туда же о совместимости - сделайте вот так:
SET OPTION PUBLIC.PERCENT_AS_COMMENT = OFF;
Теперь оператор
% будет означать модульную операцию.
авторНо одно единственное преимущество из за которого все три пункта выше я готов простить, которое есть в ASA и никогда не будет в ASE. Это то, что можно скопировать базу ASA как файл на другой компьютер, прописать ODBC и запустить. Сколько потребовалось на это времени, я потом напишу, если все исправлю. :)
Это не веский довод переводить БД с ASE на ASA :) Вот если у Вас БД весит меньше 100 гигов, кол-во активных подключений не превышает 100 сессий, очень хочется получить расширенные возможности в SQL и OLAP, не планируются кластеры, продукт тиражный и должен стоять в различных местах, где не планируется использование труда сисадминов, то тогда ASA лучший выбор. А как архитектура сервера сделано, это не довод. Например, с одной стороны конечно приятно, что в ASA скопировал файл и все, вместе с настройками и грантами перенеслось, а с другой стороны все это в том же ASE или MSSQL не долго в SQL-скрипт загнать и автоматизировать перегонку БД на другой сервер. Зато у ASE и MSSQL можно под одним сервером одновременно много БД крутить, причем оптимизатор сможет строить гетерогенные запросы, а в ASA все это будет идти через RemoteServer и эффективность запросов, обращающихся одновременно к родной и присоединенной БД будет на порядки ниже.
