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

Стандартная dbunload некоторым из этих требований удовлетворяет не полностью и имеет большие накладные расходы на запуск (о чем думает первые 20 секунд после запуска, не знаю...).

Кто какие альтернативные средства может предложить для решения задачи?

White Owldbunload, может все перечисленное.
Хорошо. Имеется ASA 8.0.3.

Задача: отскриптовать все таблицы (без данных), разместив скрипт на каждую таблицу в отдельный файл.
Умеет ли это dbunload? Конечно, но только запускать его придется столько раз, сколько таблиц нужно отскриптовать. на каждый запуск - полминуты сбора данных по базе. число таблиц: 400. Время выполнения: неудовлетворительное.

Если есть способ получить тот же результат с помощью dbunload быстрее - буду признателен за рассказ.

White OwlНу что там рассказывать? Все ж элементарно до немогу. Сохрани на диск как батч-файл, поправь строку коннекта и запусти.
И от этого dbunload будет работать быстрее? Если бы я собирался его на каждую таблицу вручную стартовать, тогда вопрос скорости выполнения был бы неактуален...

White OwlЭту операцию надо делать раз в минуту? Зачем там скорость?
400 таблиц по 30 секунд - это вообще-то больше 3 часов.
Полный рефреш - надо попробовать, если ускорится раз в 5 то будет уже приемлемо...

Идем дальше. dbunload имеет ключ для выгрузки скрипта отдельной таблицы. Как с помощью dbunload выгрузить в отдельные файлы скрипты на прочие объекты БД?
Конечно, процедуры, функции, представления можно выгрузить просто через dbisql , соответствующей выборкой из SYSxxxxx -таблиц, но например с EVENT'ами такой фокус уже не пройдет: sysevent.source содержит только тело event'а, без заголовочной части.

White OwlНичего не понимаю. Тебе надо описания всех таблиц в одном файле или каждую таблицу в отдельном файле? В первом посте ты просил "возможность помещать скрипт на каждый объект БД в отдельный файл". Теперь хочешь все вместе?
Нет, в отдельных. Я сказал, что и не собирался стартовать dbunload для каждого объекта вручную (т.е. изначально собирался делать это программно или как ты и предложил - батником).
White OwlНо я все равно не понимаю что такого страшного даже в трехчасовой работе. Задача же одноразовая. Поставь ее крутится на ночь и все. Да даже за сегодня вместо того чтобы задавать вопросы тут ты уже три раза ее мог успеть сделать :)
По одноразовой задаче вопросов бы и не возникло. Но задача не одноразовая. Цели задачи:
а) фиксация состояния объектов базы данных в VCS;
б) реализация пообъектного сравнения схем двух баз данных, либо одной базы в два различных момента времени.

White OwlИ с событиями тоже пройдет. SYSEVENT.Condition хранит условия запуска события а целая таблица SYSSCHEDULE.* посвящена расписанию запуска.
Так можно дойти и до того, чтобы скриптовать таблицы через SYSTABLE/SYSCOLUMN/SYSINDEX/SYSIXCOL/SYSFOREIGNKEY/SYSATTRIBUTE/.... Можно написать велосипед самому, но геморно. Поэтому и интересовался готовыми решениями... В том же SYSSCHEDULE вариантов приличное количество.

White Owl Сначала скрипты на создание объектов лежат в CVS, потом на их основе создается база.
То, что база должна создаваться на основе скриптов, а не наоборот - согласен. И на основе тех потабличных скриптов, которые я хочу получить, база не создается - тоже согласен, тем более что это и не позволит сделать порядок создания констрэйнтов. И в CVS будут храниться исходные скрипты на генерацию БД и скрипты на модернизацию схемы БД, сформированные в процессе работы.

Задача же пообъектных скриптов с моей точки зрения очень простая - организация мониторинга изменений объектов БД от версии к версии, сравнение объектов в разных версиях - точно так же, как вы можете посмотреть историю и сравнить к примеру разные версии cpp/h-файлов прикладного проекта. Общий скрипт в этом мало поможет: ну покажет он вам, что база изменилась, а дальше что? Сравнение текста охрененного размера скрипта?
Сохранение же (не вместо чего-либо другого, а дополнительно) пообъектных скриптов позволит легко видеть, что именно и как именно изменилось за интервал времени от А до Б.