Я бы разломил это на отдельные этапы. Требование к файлу может быть там, но считайте это: пока каждая строка генерирует файл, действительно ли это разрыватель транзакций, если для создания файла требуется, возможно, пять или десять минут? И неужели это хуже, чем удары, которые вы увидите из запуска пакета SSIS из триггера?
Итак:
Шаг 1: триггер просто вставляет строку в другую таблицу с информацией, необходимой для создаваемого файла.
Шаг 2: измените свой SSIS-пакет, чтобы получить дополнительный ранний шаг, который опросает эту таблицу для любых новых записей, создает файлы по мере необходимости, а затем отмечает завершенные записи (или полностью удаляет их, но лично мне нравятся контрольные журналы).
Шаг 3: добавьте запланированное задание на сервер, который запускает этот пакет SSIS каждые 5 минут.
Если вы не хотите изменять свой SSIS-пакет, вместо этого вы можете создать хранимую процедуру, которая будет опробовать таблицу и выполнить пакет, и запланировать это в задании. Главное - уйти от идеи уволить пакет прямо с триггера.
Вышеуказанный метод также минимизирует влияние потенциальных проблем, таких как недоступность файла по какой-либо причине.
Честно говоря: я не думаю, что это хорошая идея для начала. Триггер должен быть очень скудным и средним - писать запись в таблицу или что-то в этом роде. Не более. Триггер никогда не должен вызывать длительную обработку - как пакет SSIS ... вы должны отделить это от выполнения триггера. –
что мне нужно сделать, это написать файл на каждую вставленную строку. Я пошел с xp_cmdshell, но люди советуют мне не использовать его. Поэтому я написал пакет SSID и установил его на MSSQL. Все, что мне нужно сделать, это выполнить его, когда строка вставлена в определенную таблицу, и я не знаю другого решения, а затем триггера. – no9
Вам нужно записать записи в файл по мере их появления или будет ли приемлема некоторая задержка между вставкой и протоколированием в файл? – Mithrandir