kms писал(а) 25. Октября 2007 :: 13:41:Другой клиент удаляет строку (физически строка, конечно, просто помечается как удаленная).
Третий создает новую запись (и по несчастливому стечению обстоятельств она попадает на то же самое место)
ТП просыпается и, к примеру, удаляет (гусары, молчать), данную физическую строку.
При этом она честно проверяет, что новая строка равна старой, но сравнение адресов записей всегда возвращает равенство.
Да, это может быть.
kms писал(а) 25. Октября 2007 :: 13:41:Т.е. имхо включение адреса физической записи для формирования уникального ключа - небезопасная операция.
Можно попробовать оценить, насколько это опасно. Может быть, все не так страшно...
Поиск по CompareRows дает следующие места, где используется сравнение:
ActivateRow - используется при помощи вызова из клиентского кода или из провайдера для изменения текущей строки. Если ТП может найти среди видимых строк требуемую, активирует ее, если нет - то производит выбор строк из провайдера, начиная с запрашиваемой для активации. Итак две ситуации: строка есть среди видимых - простая подсветка, строки нет - подгрузка. Как может быть получена строка для активации? Клиентский код определяет требуемый элемент справочника или документ, провайдер на основе этого элемента делает поиск по ИД и получает физ.номер записи. При замене удаленной записи проблемный эффект можно возникнуть только, если среди видимых есть старая запись. Тогда она подсветится, хотя реально запрашивается совсем другая - новая.
Drag'n'Drop
Сравнение используется, насколько я понял, для оптимизации отрисовки текущей цели. Тут не может произойти что-то опасное, потому что строки ТП при этом не удаляются и не создаются. Сравниваются между собой строки, полученные из одной выборки.
Так что с моей кочки зрения, сильных отрицательных эффектов быть не должно. Собственно, он только один - подсветка устаревшей строки при активации строки по запросу от клиента или от провайдера. Этот отрицательный эффект полностью нивелируется ТП с автообовлением.
Возможен еще один эффект - при обновлении строк. ТП запрашивает N строк, начиная с некоторой данной (первой видимой). Если провайдер использует физ.номер, то он возьмет N строк начиная от новой строки. Если провайдер не использует физ.номер, а использует ИД, то он не найдет строку вообще и ему придется что-то сделать по умолчанию - например перейти в начало таблицы. В любом случае то, что произойдет - нельзя считать нормальным поведением с точки зрения пользователя
Так что физномера - не такая страшная вещь, как кажется.
Не, ну конечно использование физномеров - не такое гладкое решение, как использование ИД. Но с другой стороны номера должны работать гораздо быстрее... Хотя тут надо бы еще подумать...