Cat2v skopinCat2,
и что делать?
Для начала изучать доки.
+100500 :)
Cat2Создаем событие

Обработчик события

Я сильно извиняюсь...
Но какой принципиальный смысл вызывать myTableAdapter.Update(myTable) на каждый чих изменения или удаления строки из таблицы?
Эта штука имеет смысл быть вызвана, когда весь блок обаботки данных DataTable уже закончен и эти изменения нужно зафиксировать в БД.

Cat2sphinx_mvЭта штука имеет смысл быть вызвана, когда весь блок обаботки данных DataTable уже закончен и эти изменения нужно зафиксировать в БД.
Все равно все изменения будут обрабатываться единичными update-delete-insert для каждой строки и выигрыша в производительности не получится.
Не совсем так! :)
Точнее, ОЧЕНЬ не так...
В Вашем случае каждое изменение будет вызывать применение изменений в БД. Даже ошибочное. Даже многократное изменение одной и той же записи... И, возможно, даже отказ от всех выполненых изменений...
Соотвественно, количество атомарных операций по сохранению данных в базе может увеличиться в несколько раз - это однозначно отрицательно сказыватся на производительности.
Ну, а если учесть возможность в моем варианте обернуть группу одиночных insert-update-delete в единой транзакции - это только плюс к производительности.
Cat2В однопользовательской системе проблем не будет. Но в многопользовательской актуальная информация должна как можно быстрее попадать в базу, что бы и все другие ее могли получить.
Актуальная информация становится доступной в момент, когда она сохраняется в базе.
Другого варианта "актуализации" не существует - при любой схеме обработки. Хоть Вашей, что моей.
В Вашем случае, когда в БД фиксируются чуть ли не элементарные изменения полей в записи, "актуальной" может стать очень "неактуальная" информация. В результате другой пользоваль/процесс вполне могут подхватить "чужую" запись с неактуальной информацией - и мы получаем конфликт обновлений...
В-общем, в-целом и в-частности, для многопользовательской работы как раз схема с независимым сохранением отдельных записей таблицы не очень годится.
Cat2Возьмем к примеру, Кадры.

Кадровик изменяет фамилии вышедших замуж и сменивших фамилию. Пока он не нажмет кнопку "сохранить изменения", эти изменения в Вашем случае не будут видны никому и они будут полуать инфу со старой фамилией. Это не очень критично для Кадров, но есть и более критичные базы.Правильно!
Специально для фиксации изменений в БД существует очень большая кнопка "Save" или для отмены сохранения данных не менее большая кнопка "Cancel". И только нажатие на эти кнопки делает информацию правильной/достоверной или отменяет выполненные пользователем изменения!
И, кстати, кто сказал, что "элементарные" изменения могут быть ограничены только необходимостью сохранения только одной-единственной записи в одной-единственной таблице? "Мастер-деталь" уже не рулит? ;-)

Cat2sphinx_mvПравильно!
Специально для фиксации изменений в БД существует очень большая кнопка "Save" или для отмены сохранения данных не менее большая кнопка "Cancel". И только нажатие на эти кнопки делает информацию правильной/достоверной или отменяет выполненные пользователем изменения!
Это справедливо для данных, которые должны попасть в базу в единой транзакции.С учетом того, что любое изменение данных должно выполняться в рамках транзакции, то, соответственно, это касается ЛЮБЫХ изменений данных.
И мы ВСЕГДА должны помнить главное правило при многопользовательской работе с данными: транзакции должны быть как можно короче. Не так ли?

Cat2sphinx_mvпропущено...
С учетом того, что любое изменение данных должно выполняться в рамках транзакции, то, соответственно, это касается ЛЮБЫХ изменений данных.
И мы ВСЕГДА должны помнить главное правило при многопользовательской работе с данными: транзакции должны быть как можно короче. Не так ли?
Совершенно верно. Однако если единичная транзакция затрагивает только одну строку в базе, то ее обновление должно производится в режиме реального времени, а не дожидатся нажатия кнопки Save.
Тут, наверное, необходимо исходить из нескольких посылов... IMHO...

Алгоритм сохранения должен быть единообразным как для единичной записи, так и для множества связаных записей - это проще и при проектировании/разработке, и для пользователей - им не надо помнить как в каждой из многих частей системы работает процесс сохранения данных...

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

Решение о необходимости сохранения или отмены изменений данных в БД все-таки должно приниматься человеком-оператором...
Cat2Возьмем, например, всем известный Склад. Получатель выбирает позиции и эти данные должны быть сразу отмечены в базе, что бы никто другой не не смог набрать количество, большее, чем Остаток-Заказы.
Это - спорный или, по крайней мере, очень неоднозначный вопрос...

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

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

Выдать со склада "по документам" (а "по факту" это невозможно сделать) больше, чем есть в наличии - вот это да, как бы "низззя"... Но и делаться это уже может на основе, как минимум, предварительно подготовленных (на основе данных все тех же заказов) "болванок", которые вообще могут быть сформированы полностью автоматически "по-ордерно" в строгом соответствии с требованиями "коротких транзакций"...
Cat2Когда Получатель все выберет, то в единой транзакции уменьшаются остатки и аннулируется Заказ Получателя.