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

Описав вполне реальную ситуацию, я всего лишь ответил на твой вопрос:
>Хучубей не пойму
>зачем тебе постоянно инфу в базу сбрасывать

К чему ты привел дополнительно еще два метода непонятно, чем они лучше?

И еще:
>это граничит с синдромом навязчивых состояний
А вот это по делу. Спасибо. Приму к сведению. Пройду обследование :)

2Latuk
Сразу хочу оговорится, что не претендую на звание "лучше всех знающего всего обо всем" и мне ооочень далеко до уровня профессионалов (относительно себя считаю ув. Latuka профессионалом). И в этой дискуссии я всего лишь хочу для себя найти истину.
Так вот хотелось бы понять, что плохого в сокрощении промежутка времени между изменением записи на клиенте и на сервере. Ведь при таком подходе:
>Тем, что не мучают зазря сервер и сетку.
следует, что лучше в начале дня/недели/месяца/года дать юзеру набор записей и, чтобы "зазря не мучать сервер и сетку", скинуть на сервер все изменения клиента в конце дня/недели/месяца/года. Хотелось бы услышать ваше мнение по этому поводу (по возможности без предположений о наличии у меня еще каких бы то ни было синдромов :)

2Тяп-ляп:
>По-моему, ничего отсюда не вытекает
Ну как минимум отсуда вытекает, то что если юзер изменит n из n+1 полей и решит пойти покурить и т.д., то на весь период его отсутствия остальные юзеры будут видеть устаревшие данные, чего в принципе недолжно произойти при сохранении изменений каждого поля. Опять же случай, когда эту запись изменит другой пользователь и вернется первый пользователь, то разве не возникнет конфликт записи при сохранении первым пользователем?

LatukУмные мужи придумали
и воплотили в стандартном наборе приемов
к случаю оному путь для решенья проблеммы
Имя пути Репликация - славное имя
в книгах мудрых воспето.
Шедевр
Latukчего в принципе недолжно произойти при сохранении изменений каждого поля
А как же последнее измененное поле?
что же остальные пользователи будут видеть его старое значение?
А кто сказал что полседнее полее предпалогалось изменять? Все изменения уже сделаны. Только вот не каждому юзеру ясно, что и с последнего поля тоже нужно выйти для сохранения записи.
LatukБудем отслеживать нажатие клавиш и сливать при каждой новой букве?
Вопрос приму как риторический в ответ на мое "скинуть на сервер все изменения клиента в конце .../года"
Latukкстати даже после того как данные окажутся в базе другие юзера их не увидят пока не перечитают
Бум делать Requery по таймеру или каждый раз как другой юзер нажмет кнопку?
А это уже из другой оперы. Разве твои "стандартные методы" решают эту проблему?
LatukТак же необходимо учитывать , что вероятность конфликта зависит еще и кол-ва транзакций
а число оных многократно увеличивается при таком подходе
(если конечно нет подсознательной цели встать по работе с сервером в один ряд с 1С)
SQL.RU - Важное правило в MS SQL - транзакция должна быть короткой.
Отсюда мой вывод: лучше много коротких транзакций, чем мало больших.
LatukPS Эпитет "синдром навязчивых состояний" относился к интерфейсу
сливающему данные после обновления каждого поля
Ибо его поведение очень похоже на поведение человека,
в десятый раз с полпути возвращающегося проверить выключен ли утюг.
Незачем тратить силы на избегание того , чего может и не случится вовсе.

Ну чтож, мой словарь пополнился новым "эпитетом"