Сдается мне, что в 7-ке такая конструкция не должна работать.
А вот такая должна работать 100%, где в зависимости от типа поля (который нужно получать в курсоре вместе с его именем) будет выбираться соответствующий статмент:
Для числовых полей
Для дат
Для таймштампов
Для символьных полей (norm_str функция удвоения терминального символа одиночной кавычки)
Old_value&New_value - ни какие не таблицы, а специальные альясы, использовать их во from нельзя. Есть deleted,inserted таблицы, но для статмент-триггеров, а не построчных.
авторУ вас триггер for each row, как мне кажется, в данном случае нет таблиц типа inserted, deleted, а доступ к данным напрямую через old_row.имя столбца.... Если бы оно отсуствовало бы "for each row" или стояло for each statement, тогда да бы old_row была бы таблицей...
+1
P.S.: При редактировании цитаты увидел, что t_nTo у автора окружено не двойными кавычками, а сдвоенными одинарными. Спишу на "странности перевода".
P.P.S.: Вы не любите кошек? Да вы не умеете их готовить!

"Любой уважающий себя математик должен быть ленивым" - так когда-то говорил препод по высшей математики в универе. Я часто перефразирую эту фразу на всякий лад, и в частности иногда и так: любой уважающий себя разработчик должен быть ленивым.
Что плохого в том, чтобы избавить себя от дополнительных телодвижений в будущем путем составления универсального, статичного скрипта триггера?! Что плохого в том, что разработчик на этапе постройки системы пытается предусмотреть ее будущее и СВОИ действия на все случаи жизни?! Что плохого в желании заложить фундамент под непрописанное в ТЗ крыльцо, но которое в соответствии с опытом разработчика запросто может появится спустя полгода в связи с требованиями заказчика, только из-за того, что очень мало заказчиков способны вообще четко изложить что им нужно?!
Ведь все зависит от задачи, ведь так?! Нам изначальная задача неизвестна, соответственно мы не можем однозначно определить меру правильности данного решения, мы можем обсуждать только пути реализации данного решения. Нужен заказчику полный аудит всего? Да пожалуйста, и не нужно держать ни в голове, ни еще где бы то ни было, что нужно сопровождать еще и триггеры и обновлять их скрипт и т.п. Чем меньше информации, тем лучше. Тем более, что данное решение при грамотном исполнении не добавит ограничений в производительности сервера и его функционала.
Что каждый раз курсором перебирать поля, что в статике перебирать их же - одна фигня. Системная табличка осядет в кэше и все. Грандиозные скрипты с использованием десятка табличек способны выполняться за единицы миллисекунд при частом их дерганье, на то АСА и АДАПТИВНЫЙ!!!

PS А вот если бы АСА позволяла вешать триггеры на системные таблицы, была бы вообще красотища. Можно было бы решать много второстепенных задачек, в том числе и по обновлению скриптов триггеров.

ASCRUS...чаще всего оказывается, что заказчику этого оказывается достаточно для работы и он просто разгибал пальцы, сам не понимая, что хочет и не осознавая, что никто этим пользоваться не будет.
+1
Именно от этого все и бывает, что толком никто сказать ничего не может.

ASCRUSА если пользоваться тем же PD с репозиторием, то получается, что необходимости в триггерах на системные таблицы нет ;)
Не всегда PD может помочь. Мне, например, хотелось бы получить триггер на добавление пользователя. Некий софт создает пользователей. Этот софт выступает как исходные данные, моя задача отловить в БД эти процессы. PD здесь поможет?
Можно только отхватить в принципе создание пользователя на свою логику и там параллельно реализовать. Но это ж дополнительные пляски с бубнами. Причем однозначно на стороне клиента.