Как получить старое значение поля в onValidate?

← →
CrazyElk © (2004-07-19 12:27) [0]

Необходимо запретить присваивание значения полю если оно совпадает с текущим его значением. Написал procedure TDMPaymentOrder.qPaymentOrderPARTNER_TYPE_IDValidate( Sender: TField); begin if Sender.Value = DMPaymentOrder.qPaymentOrder.FieldByName("PARTNER_TYPE_ID").Value then abort; end;
Мнилось что в Sender будет уже новое значение а если с другого конца зайти (DMPaymentOrder.qPaymentOrder.FieldByName("PARTNER_TYPE_ID").Value) то (поскольку change событие еще не происходило) там еще старое. Попытка "наивного чукотского мальчика" с треском обломилась оба этих значения всегда равны новой величине.

Если кто знает подскажите КАК идеологи Delphi и или компонента предпологали получать старое значение поля в этой ситуации (по возможности без плясок с бубнами запоминанием старого значения в глобальных переменных, переписывания классов и т.д.)

WBr CrazyElk

P.S. qPaymentOrder - TADOQuery

P.S.II Совет анализировать значение до присваивания увы неприменим - повторное присваивание того же значения происходит из за того что это поле изменяет TDBLookupComboBox а ему по барабану какое было значение до того как набрали букву на клавитуре или ткнули в раскрывшийся лист.

← →
bushmen © (2004-07-19 12:50) [1]

> КАК идеологи Delphi и или компонента предпологали получать старое значение поля в этой ситуации

Для этих целей в MSSQL предусмотрен триггер на вставку. В таблице deleted будут доступны старые значения полей записи, а в inserted - новые. Если значения совпадают, то отменяете вставку

← →
Johnmen © (2004-07-19 12:51) [2]

DMPaymentOrder.qPaymentOrder.FieldByName("PARTNER_TYPE_ID").OldValue

← →
CrazyElk © (2004-07-19 14:44) [3]

2 Bushmen - Ну так мне надо знать а) на клиенте б) это происходит ДО того как TADOQuery отправляет чего либо серверу.

2 Johnmen - AFAIK - OldValue (и NewValue) предназначен для отслеживания разницы между БАЗОЙ ДАННЫХ и текущим значением Буфера записи на клиенте при многопользовательской работе с БД и отложенных (кэшируемых) обновлениях. Работает (согласно хелп) только если включено кэширование данных или использованн CastomDataset. В моем случае нужно старое значение Буфера записи (оно гдето там есть ибо по abort все благополучно возвращается на место) и новое значение опять таки Буфера записи (до БД еще дело не дошло). А из практики нет там ничего в OldValue (ибо нет у меня кэширования и DataSet самый обычный) по крайней мере чего бы ни было присвоенно полю OldValue у меня 0 всегда в onValidate.

2 ALL Еще идеи опыт решения этой/аналогичной проблеммы есть???

WBr CrazyElk

← →
bushmen © (2004-07-19 14:55) [4]

> мне надо знать а) на клиенте б) это происходит ДО того как TADOQuery отправляет чего либо серверу.

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

← →
CrazyElk © (2004-07-19 16:24) [5]

2 bushmen - [i]По-хорошему, все ... [/i] - завидую я людям которые не зная ТЗ (в частности загрузку сервера, архитектуру и требования к ПО, спецификацию бизнес процеса решаемого ПО, качество линий связи и т.д. и т.п.) знают как надо делать ПО ХОРОШЕМУ. К тому же разве я где то говорил что добавлю запись (перечитал все не нашел). Кажется поле редактирую. Я пытаюсь предотвратить лишний и вредный (с точки зрения бизнес процесса) обмен с БД для повторного присваивания уже установленного значения полю поскольку это требует множество проверок согласованности значений на клиенте исходя из текущего состояния клиентской программы (а вовсе не согласованность данных в одной БД) что достаточно дорогостоящая операция в моем случае, а мне предлогают использовать для этого хранимую процедуру. Чтобы исключить обращени к БД надо обатится к БД умереть и не встать :-) ну разнообразия ради что ли прочитай вопрос прежде чем отвечать pls. А то у тебя "все в сад" всю логику на сервер, на сервер, на сервер (не зная ни что за логика, что за сервер).

WBR CrazyElk

P.S. напоминает "святую" уверенность начинающего архитектора БД что все "хорошие" спроектированные БД обязательно удовлетворяют третьей нормальной форме.

> не зная ни что за логика, что за сервер

Такое впечатление, что у тебя АСУ ТП прямо. И что это за сервер, на котом нельзя проверку выполнить?

2 bushmen - если хочется флеймить будь добр если хватит силы воли в другой теме пожалуста. Для тех кто в танке повторяю -> МНЕ требуется ПРЕДОТВРАТИТЬ ОБРАЩЕНИЕ К СЕРВЕРУ (и я не дискутирую проблему почему мне это надо, какова архитектура моей программы что она делает, "асуп" или "не асуп", какой мощности сервер, сколько к нему обращений и нельзя ли купить полутше и т.д. и т.п.) на основе данных КЛИЕНТА (данные находятся в компонентах доступа к БД поставляемых и используемых в Delphi - это надеюсь достаточное обоснование для попадания в ветку). Если тебе не верится что существуют случаи когда переход к следующему значению НА КЛИЕНТЕ должен зависить от предыдущего установленного НА этом КЛИЕНТЕ значения (а не текущего в БД которое в момент перехода может быть каким угодно в виду многопользовательской работы) воля твоя убеждать не буду.

[i]И что это за сервер, на котом нельзя проверку выполнить?[/i] -где ты нашел утверждение НЕЛЬЗЯ (второй раз передергиваеш или просто не понимаеш высказывание). НЕЛЬЗЯ и НЕЖЕЛАТЕЛЬНО или ВРЕДНО или НЕ ОПТИМАЛЬНО в русском языке имеют разное значение.

Но уж раз захотел примеров их у нас есть - Ни один сервер не оценит тебе условие оперирующее понятиями доступными только на клиенте например (фантазируя конечно) PID клиентского процесса, его текущее состояние (которое может зависить от данных не связанных с БД - пример размер окна -> влезет текст или нет), текущий приоритет, количество процессов. Если ты ему эти данные конечно не пришлеш в хранимую процедуру. Ну а если пришлеш то они у тебя есть, а мой вопрос если ты его читал касается того как данные получить. А именно СТАРОЕ значение установленное НА КЛИЕНТЕ чтобы сравнить его с НОВЫМ установливаемым НА КЛИЕНТЕ из компонент доступа к БД да еще и в определенный момент времени OnValidate. При этом строго доказанно (использованием abort) что эти данные на клиенте есть.

WBR CrazyElk

P.S. 2 ALL как обложить это несчастное изменение флажками и отслеживать на клиенте старое значение этого поля скажем в глобальной переменной и использовать ее в onValidate и т.д. и т.п. этот workAround знаем и умеем. Таких решений - да их у нас есть достаточно. Интересует путь предпологаемый создателями компонент или квалифицированное заключение о невозможности описанной проверки.

Are any body here?
А казалось такая простая и естественная задача?
Мастера подскажите на худой конец кого еще можно спросить по теме.

WBR CrazyElk

Как получить старое значение поля в onValidate? Найти похожие ветки