Вопрос в следуюущем:
1) DW retrieve и строки получают NotModified!
2) Меняю ключевое поле (указано как KeyColumns в Specify Update Properties) через setitem и строка меняет статус на DataModified!
3) Меняю статус этого ключевого поля на NotModified!
dw.SetItemStatus( row, columnkey, Primary!, NotModified! )
и статус строки меняется как NotModified!

Не ясно изменения статуса в третьем пункте... я же меняю статус поля а не строки, а при этом меняется статус всех остальных полей с DataModified! на NotModified!

То что мне нужно достигается дополнительным
dw.SetItemStatus( row, 0, Primary!, DataModified! )

Не ясен пункт 3. Почему при изменении статуса ПОЛЯ на NotModified! статус всей строки меняется на NotModified!

E-docПотому что это было ЕДИНСТВЕННОЕ измененное поле в строке и при смене статуса его на NotModified! нет смысла строке быть DataModified! Более того, то что вы принудительно меняете статус строке на DataModified! не даст вам желаемого эффекта - выполняемый Update будет пустым, т.е. ни одного поля в секции set field = <value> не будет до тех пор, пока вы не присвоите значения каким-либо столбцам или не смените статус этих СТОЛБЦОВ на DataModified!.

О! все понял... действительно единственное.
А вот насчет того что не будет иметь эффекта изменение статуса строки на
DataModified!, тут вы не правы... эффект есть (без изменения любого знаяения или статуса каждого столбца).

Послу установки на строку DataModify. Update есть и формируется по всем полям перечисленным при вызове StoredProcedure на Update

E-docВот как значит... Вообще-то вы не говорили что для Update используется StoredProcedure. :)) Для простых SQL-Update'ов он не генерируется. Для процедурного Update видимо все совсем иначе. Тогда можно пару вопросов?


Извините, просто я с самого начала работал только со SP, а не напрямую с таблицами, поэтому я просто не знал что может быть такие отличия в генерации Update, но я прочитал Хелп и понял что если работать на прямую, то сам Update генрится если строка DataModified!, а поля в этом для Update генерятся только для тех, которые DataModified! ;-) Правильно? Просто со SP это не так ж-)

E-doc
Если в процедуру передаются значения для всех полей, то как вы разбираете их в процедуре для Update на старые и новые значения - используете двойной набор параметров?


В процедуру можно передавать значения не всех полей, это определяется набором входных параметров в процедуру и указывается соответствие в коне настройки Update SP.
Я немного не понял что значит разбирать на старые/новые.
Процедура принимает входные параметры - это те данные, на которые нужно изменить значения. А в самой процедре пишется стандартный Update.


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

E-doc
Как вы рассматриваете ситуации если значение в каком-то поле не поменялось? Все равно его присваиваете? В этом случае наверно могут быть ложные срабатывания триггеров на after update, если есть проверки на имя столбца.


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

E-doc СотниковЯ немного не понял что значит разбирать на старые/новые. Я не совсем понятно выразился, наверно. Например, для реализации варианта истории изменений, когда фиксируется старое и новое значение на смену значения конкретного поля таблицы при простом Update можно было бы вешать триггер с условием для этого поля таблицы. Как быть в случае с процедурой? Тут надо или сравнивать значение с тем, что уже есть в таблице или иметь два параметра - для нового и старого значения, чтобы иметь возможность их сравнить.

Думаю не только, но и по вашему варианту тоже все работать будет, то есть можно:
1) "сравнивать значение с тем, что уже есть в таблице", только можно это делать не дя каждого поля, а сразу скопом для нужных полей в одной процедуре,
2) "иметь два параметра - для нового и старого значения"
3) повесить триггер на ДО Update, и сравнивать нужные значения полей в нем?
и если сравнение не пройдет генерить статистику на изменение, все равно же триггер на Update выполниться в любом случае, хоть вы обновляете все поля и ли хотя бы одно.

ЗоринАндрей СотниковПроцедура принимает входные параметры - это те данные, на которые нужно изменить значения. А в самой процедре пишется стандартный Update.
То есть тупо молча перезаписываем изменения поверх, даже если другой пользователь поменял данные пока мы пялились на resultset и вбивали новые значения. Зашибись - никаких тебе "Запись была изменена другим пользователем".
И зачем только эти умники из Sybase/Powersoft придумали использовать старые значения в условии Where Проще надо быть
А то напридумывают каких-то optimistic concurrency control scheme...

ПОЛНОСТЬЮ с вами согласен.
НО в нашем случае добаление данных (почти только этим и занимаются), а также изменений (не так много операций) занимается отдельный отдел, остальным нужны выборки... и так сложилось что у нас задача с concurrency не стоит.

Тогда Сразу вопрос к Андрею. Как организовать concurrency используя SP, это на будущее просто ж-)