По постановке задачи необходимо производить изменения в Z-таблице при изменении количества в позиции сбытового заказа, при этом, необходимо, чтобы эти изменения (Z) в базе проводились одновременно с изменением количества в заказе "на экране" пользователя. Здесь проблем нет - проблема одна - если я выхожу из заказа без сохранения изменений, то изменения в Z уже есть. Как их откатить в случае выхода без сохранений???? Может есть экзит какой на такой случай?

Прошу помощи.

Необходимо кому, простите?

Читайте курс про концепцию обновлений.
Вам нужно запустить свой ФМ, в котором вы будете изменять записи Z таблицы, в UPDATE TASK.

Интегрируем со складской системой. В складской системе есть понятие упаковки, которое может меняться не меняя количество товаров (переупаковка и т.д.). Скажем, у нас 100 единиц товара в упаковках по 50 и 200 по 20. Один пользователь хочет одну 50 единиц - ему отдается 50. Второй пользователь в то же время хочет 120 единиц. Первому дается одна большая коробка по 50 единиц. Соответственно, система не должна позволить второму пользователю получить 2х50 плюс 1х20, а должна дать 6х20. Чтобы не проводить повторные проверки при сохранении и избежать новых переборов данных - необходимо блокировать ту самую "одну коробку", как только пользователь задал количестве в позиции. Все это работает. Единственный баг - если после изменения позиции выйти из заказа "без сохранения", то уже прошедшие изменения останутся в Z таблице.
SELECT FOR UPDATE не подходит, так как заказ одной единицы товара заблокирует весь остальной запас.


Вот как раз исходя из вышеописанной ситуации IN UPDATE TASK не подходит, иначе я бы все перед сохранением сделал.

Это вы с какой такой складской системой интегрируетесь?
Если речь идет о стандарте - то при чем здесь свои таблички и прочее?
Комплектование единицами обработки/складирования производится на уровне поставки.
Если же система внешняя и не позволяет блокировать конкретное складское место - то нафиг такую систему.

С самописной складской системой.
Я же ищу путь решения а не определяю что лучше а что хуже. Партия сказало надо комсомолец ответил "есть". На уровне поставки блокировать поздно.

Как и где у вас храниться информация о "коробках"?
Возможно намного проще решить не через отдельную таблицу, а через объекты блокирования?
Т.е. при подборе "коробок" каждому пользователю пытаться установить блокировку на объект и в случае ошибки просто пропускать такую упаковку.

А если коробок сто??? Сто объектов блокирования?

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

Думается что никак.
ИМХО единственный вариант обновить значение обратно также как оно было обновлено вами до этого.

что ту можно предложить:
сделать в вашей Z таблице ещё поля:
со старым значением - сохранять его туда перед обновлением
флажок - выставлять его при сохранении заказа через UPDATE TASK
сделать отдельную программу и запланировать её периодическое выполнение которая бы выбирала записи с пустым флажком проверяла по блокировке что заказ в данный момент не редактируется, ну и если такая ситуация обнаружилась возвращать значение из сохранённого.

Почему ИМХО нужно делать в отдельной программе - сеанс пользователя может быть аварийно завершон (например связь порвалась или например гдето дамп случился...), в результате откатить изменение сама программа никак не сможет

Ну да, придется видимо так и делать:-((( Что поделать - задача так стоит:-(((
Спасибо...