Есть триггер, который срабатывает при добавлении записи. Есть какой-нибудь способ манипуляции с добавляемой записью? Например, хочется изменить данные записи или и вовсе сделать отмену её добавления. В Oracle SLQ есть, например, такая конструкция:
Есть ли что-нибудь такое тут и будет ли это работать, если используется в качестве БД - Access?

UPDATE: в MS SQL, например, есть триггер INSTEAD OF INSERT и ключевое слово inserted для обращения к вставляемой записи. Можно ли его как-то использовать в программе?

>Например, хочется изменить данные записи
Вы можете в триггере написать инструкцию UPDATE SET

>вовсе сделать отмену её добавления
Вы можете в триггере написать инструкцию DELETE FROM

Пожалуйста, приводите конкретный пример с конкретой ситуацией из бизнеса и данными. А также желательно предоставлять поясняющие скриншоты.

_________________
2B OR NOT 2B = TRUE

Я понимаю. Но речь идёт о текущей записи. Как не допустить её добавления? DELETE -удаляет уже добавленные записи, UPDATE - обновляет уже добавленные записи. А нужно не допустить добавления текущей записи, при этом воспользовавшись её данными. Данными мы воспользоваться можем, для этого есть угловые скобки <>. А вот как не допустить добавления текущей записи - не понятно.

Пример:
Есть таблица со счетами. Добавляем новую строку. Что должен сделать триггер? Он должен воспользовавшись данными этой текущей строки и добавить новые строки (а не оригинальную строку), содержащие их (данные). Для этого вполне подойдёт INSERT INTO. Но кроме того, он должен не допустить добавление этой самой текущей оригинальной записи.

>Пример: Есть таблица со счетами. Добавляем новую строку.
Продолжайте, пожалуйста, с вашим примером...
В чем конкретная причина, по которой не должна добавляться запись в таблицу "Счета"?

Если не будут заполнены обязательные поля, если Условие на значение любого поля не соблюдается... - запись и так не добавится.

_________________
2B OR NOT 2B = TRUE

Ну просто она будет "пилиться" (дробиться) на несколько записей, которые и должны попасть в таблицу, а оригинал не нужен.

И это хорошо. Нужно чтобы валидация отрабатывала как положено, а уже после неё срабатывал триггер, который "расщепил" бы запись на несколько, удалив оригинал. При этом "расщеплённые" записи тоже будут вполне валидными, так как всё необходимое будет браться из оригинала, который успешно прошёл валидацию.

UPDATE: ладно уж, что темнить. Опишу полнее задачу. Дело в том, что в таблице счета, есть поле сотрудник, где возможен множественный выбор, а также сумма и зп сотрудника. Дык вот, при множественном выборе хочется чтобы появилась не одна строка с несколькими сотрудниками и общей для них суммой и ЗП, а для каждого отдельно, то есть раздробилась (строка) на столько частей, сколько сотрудников выбрали.
Грубо говоря, всё это костыль для того чтобы связать интерфейс Вашей программы, у которого есть возможность множественного выбора, с необходимой нам структурой БД и записей в ней.
Можно конечно по отдельности строчки создавать, вбивая вручную нужную сумму, выбирая по одному сотруднику. А хочется автоматизировать. Выбрал сразу несколько сотрудников, вбил общую сумму, а он (триггер) раздробил их на количество, соответствующее сотрудникам, и каждому посчитал свою сумму и ЗП.

А не проще вести отдельную (можно в т.ч. и подчиненную) таблицу, куда будут вноситься записи с з/п сотрудников по триггеру, срабатывающему при добавлении в таблицу Счета записи, после Сотрудник которой содержит несколько имен?

_________________
90% ответов на ваши вопросы находятся в руководстве, разделах "Вопросы" и "Видео" на нашем сайте.

Рекомендую вам посмотреть:
1. Конфигурацию "Учет зарплаты и кадров" в разделе "Конфигурции".
2. В Галерее, в самом низу короткое видео №4 "Продажи в рассрочку", где показывается генерация и вставка записей в подчиненную таблицу при изменении записи в главной.

В форме для редактирования можно отображать подтаблицы. И даже подтаблицы второго уровня.

_________________
2B OR NOT 2B = TRUE

То, что Вы предложили - вполне логично и красиво. Кроме того, я в курсе обо всех этих вариантах с подчинённой таблицей.
Но это решение не подходит.

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

В итоге, возвращаемся к моему изначальному вопросу: есть ли способ в теле триггера, отменить вставку текущей записи, срабатывающий при её добавлении?

Такой вариант я припас для себя на последок. Тут есть один момент, а при удалении триггером, сработают ли другие триггеры на удаление? То есть удалили триггером изначальную запись, но у нас есть другие триггеры, и нужно чтобы они сработали и пересчитали то что нужно. Насколько я понимаю, когда мы удаляем, изменяем, добавляем триггером, - триггеры на удаление, изменение, добавление - не срабатывают.

ПС: И к сожалению это не принципиальное упорство, а попытка найти, пока как я вижу, одно единственно верное решение. А на id-шник - вообще по барабану.

В моей базе такого нет, но триггеры можно разграничить по условиям. Тогда в каждом случае будет срабатывать свой триггер. Они вполне могут содержать одинаковые запросы.

Ну, может быть, у Вас получится сделать, как написал Иван.

_________________
Все сообщения относятся к программе "Мои диски" версии 2.х, актуальной на момент написания.

Вы немного не поняли... Дело не в условиях, а в том, что когда что-то делаем триггером, другие триггеры на это не реагируют.

Ну а то что предложил Иван... К сожалению, привёл достаточно причин, почему это не подходит.

И Вы немного не поняли... Пропишите в тело этого триггера то, что должны делать не срабатывающие.

По-моему, он как раз предложил, как из тела триггера отменить ввод в таблицу.

_________________
Все сообщения относятся к программе "Мои диски" версии 2.х, актуальной на момент написания.

Как я и говорил, способ со вставкой и удалением приберегу на последок. А перенос всего кода, всех триггеров порождает большую сложность и плохую поддерживаемость. Хотя и этот способ я держал в голове, как запасной и самый последний.


Никак не могу найти, где он это предложил. Насколько я понял, он предложил способ с подчинённой таблицей и только.

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

Странно, но почему-то упорно исчезает сообщение со ссылкой на тему. Видимо, это действует 9 пункт правил, который запрещает приводить ссылки на свой же форум
Тема называется "Подчиненная таблица не активна.", обсуждение этой проблемы на 3й странице.

_________________
Все сообщения относятся к программе "Мои диски" версии 2.х, актуальной на момент написания.

удаляются сообщения с любыми ссылками. Если так нужно дать ссылку на тему, укажите часть url после домена

_________________
90% ответов на ваши вопросы находятся в руководстве, разделах "Вопросы" и "Видео" на нашем сайте.