Всем привет.
Просто любопытно...

По умолчанию Dataset Designer в 2005-ой студии строит в TableAdapter-ах, какие-то жуткие UPDATE запросы. Например, если есть таблица с идентификатором ID и полями Field1 , Field2 , ... FieldN , то UPDATE запрос будет выглядеть как

UPDATE myTable SET
...
WHERE (ID = @Original_ID) AND (Field1 = @Original_Field1) AND (Field2 = @Original_Field2) AND ... AND (FieldN = @Original_FieldN)

Спрашивается, зачем такое условие WHERE, ведь можно оставить

UPDATE myTable SET
...
WHERE (ID = @Original_ID)

???

Явное повышение скорости выполнения запроса + меньшая вероятность возникновения исключений типа DBConcurrencyException

Или есть что-то, о чем я не догадываюсь?

Sa
да и не забывайте, если просто поставить проверку на ID , и не сформировать политику обновления записей, то увеличивается вероятность потери данных.




Вот мой слегка модифицированный Update для адаптера


Во всех таблицах, которые могут изменяться пользователем, я использую ID int с IDENTITY(1,1). Соответственно настроены и связи между таблицами в DataSet (Update Rule = Cascade), поскольку здесь самое "интересное" место это INSERT.

Раньше (с UPDATE по умолчанию) при обновлении адаптера программа периодически падала с DbConcurrencyException как раз на строке updated_count = this.m_Adapter.Update(table.Select("", "", DataViewRowState.ModifiedCurrent)) . После правки команды подобного глюка не было.

Хотелось бы поподробнее узнать про ситуации, когда UPDATE с проверкой единственного ID может привести к порче данных.

Спасибо.

Sa
например, два пользователя правят запись. в Вашем случае, изменения последнего сотрут изменения первого. Если политика обновления "кто последний тот и папа" применима для вашего приложения, то проблем нет :-)

Posted via ActualForum NNTP Server 1.3

Пользователь будет видеть свой набор ID-ов, который не должен пересекаться с ID-ами другого пользователя.

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

Sa
если для вас это не проблема, то нет вопросов.
мне непонятно про "свой набор ID-ов" - это скорее всего специфика вашего приложения.

А про блокировки, не всегда такой вариант приемлем - ужасная ситуация когда пользователь наложил блокировку и уснул... :-)))

ИМХО почти универсальное решение в этом случае: ID + Timestamp.


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