Долго не удавалось поймать косяк.
Имеется простой справочник - 2 реквизиту. + на форме списка справочника реквизит числовой и функция поиска в этом же справочнике по коду - Спр.НайтиЭлемент()+Активизировать().
//
В результате косяка в справочнике полностью дублировались записи в справочнике - даже код одинаковый, при чем что он уникальный.
Кроме того дублировался и ID в таблице справочника.
//
Что оказалось. Пользователь менял значение реквизита в справочнике, но не нажимал Enter, далее производил поиск элемента по коду через Спр.НайтиЭлемент() - элемент находился и открывался в режиме редактирования (чего не должно было быть) - при нажатии Enter записи дублировались.

(0) А реиндексировать БД не пробовал?

(0) "через Спр.НайтиЭлемент() - элемент находился и открывался в режиме редактирования"

Это у вас какая-то версия секретная. Обычно при Спр.НайтиЭлемент() никто не открывается. Тем более для редактирования.

Либо показаны не все "перлы" программиста.

(1)чего только не пробовал. Только чем это поможет если в таблице записи полностью дублируются. А вместо тех что находили - в отчетах пишет Объект не найден.
Явно косяк от разработчиков - не поставили защиту от такого варианта

(2)
   Спр=СоздатьОбъект("Справочник.Карты");
   Если Спр.НайтиПоКоду(НК)=1 Тогда
       п1=Спр.ТекущийЭлемент();
       АктивизироватьОбъект(п1);
       Активизировать("Наименование",0);
   КонецЕсли;

(4) "Пользователь менял значение реквизита в справочнике, но не нажимал Enter"

При потере фокуса полем ввода все изменения записываются в базу. Попробуй поредактируй "чего_там_редактировал_твой_пользователь" и нажми Tab либо просто щелкни мышкой в другом поле. Отмены ввода не произойдет. Даже если ты не нажмешь Ентер. Такая селява...

(5)Это все понятно.
Беда начинается когда пользователь не закончив редактирования элемента выполняет код в (4)

(+6)Речь не про сохранилось\не сохранилось. Проблема что табличка портится безвозвратно

(3) Если записи действительно ФИЗИЧЕСКИ дублируются, то, одинаковое одинакововму рознь либо товарищу надо прекратить баловаться распределенками... Либо...

(8)да физически. распределенки нет.
В табличке после косяка после 2-х записей А и Б оказываются две записи А.
//
Можете сами попробовать так сделать

(4) не совсем понял в каком месте это выполняется

(10)В форме списка справочника - что бы найти элемент оп коду и спозиционироватся на нем

(11) Ну нарушена уникальность кода и что?

(11) при изменении реквизита в форме списка?

или там какое-нибудь ложное закрытие используется, или ещё чего...

(13)да
(14)нет, больше ничего не используется "ложного"
(12)Еще раз. в справочнике было 2 элемента - с разными ID, CODE и прочими реквизитами
А при данном косяке - в табличке остаются 2 записи но с одинаковыми значениями полей. т.е данные найденной записи перезатираются данными записи по которой не закончено редактирование на уровне платформы

(15) странно, что никто до тебя с этим не сталкивался. Релиз платформы?

(16)25 - сетевая, 27 - локальная.

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

Битый релиз. Т.к. в случае редактирования элемента справочник вообще должен быть занят.

(18) напиши ребятам на 1cpp

(19)у меня или вообще?

ID точно разный ?
какая то фантастика

(22)сначала ID разный. После косяка - одинаковые. Соответственно в отчетах появляются записи <Объект не найден>

Значение какого реквизита менял пользователь?
Зачем вообще выполнять такой код?
Ни разу такое не пригодилось
Если подразумевается, что элемент должен быть открыт - так он уже открыт
Если подразумевается копирование - значит нужно копировать

А нефик редактировать "в списке" при наложенных отборах.
давным-давно известный глюк. или глюк в голове прогера, допускающего редактирование "в списке" при наложенных отборах.

(24)1. Не наименование и не код, в моем случае - это реквизит Скидка
2. Что бы найти элемент справочника по коду
//
Еще раз.
Справочник Дисконтные карты. Код - уникальный, наименование, реквизит Скидка.
Редактируется в диалоге. Пользователь меняет величину скидки - Enter не нажимает. Переходит в поле на форме НК - вводит номер карты которую нужно найти. Наживает кнопку - выполняется код в (4).
//
(25)Где ты тут отбор увидел

(26) ты что-то в показаниях путаешься. То форма списка, то в диалоге

(26): в караганде.
я просто ЗНАЮ причину, по которой может возникнуть описанная ситуация.

(27)В списке конечно редактируется.
(28)Еще раз для ЗНАЮЩИХ - отборов нет и никогда не было

(25)+: прим.: подчинение - тоже вид отбора, есичо.
(29): тогда еднственная вторая возможная причина - нештатное (т.е. не "глюк 1С") ковыряние в таблицах или аварийные завершения работы со справочником во время его редактирования. такая вот бедулька, товарищ "НЕ ЗНАЮЩИЙ".

(30)
1.подчинения тоже нет
2.никаких нештатных ковыряний и аварийных завершений не было.
//
Проверь те что ли сами - делов на 5 минут

(0)
Каким образом проверял совпадение ID ?
Кстати в dbf возможна ситуация , когда запись помечена "удалить" (не путать с 1С пометкой) в таких записях не важно что хранится

(32)ну я первый день что ли с 1С общаюсь
внутрь таблички заглянул через wDBFview

(33)
Надо проверить активность записи
Не знаю что DBFview показывает

(34)все он показывает. все активно. я же в предприятии вижу 2 дублирующие записи

(31): ну тогда, бро, все дело в твоем характере. надо признать - довольно уникальном, если 1с-ина вот таким веселым образом реагирует в твоем конкретном случае, а во всех остальных случаях - только по описанным выше причинам (которых, как ты утверждаешь, у тебя "нет").
ну или ты врёшь. или не знаешь в полной мере того, о чем так претенциозно и почти возмущенно утверждаешь.
в любом случае - жжизнь у тебя нелегкая, судя по всему. удачи тебе.

Как так получается что задваиваются коды в справочнике

(37)ага, тогда так никто и не ответил

(38): ответили в #10.
по сути причина - редактирование в форме списка со сменой активного элемента. но оказался "не в коня корм" - т.е. ты сам привел код со сменой активного элемента в форме списка, но почему-то поленился просто подумать.

(39)там ответили про что конкретно такое бывает при смене отбора.
Я пытался воспроизвести проблему еще тогда. Не получалось.

В общем, суть проблемы в том, что сохранение текущей записи выполняется уже после смены отбора или активной строки - то есть одна запись (точнее, то, что было в буфере) записывается поверх новой активной.
Кстати, подобный глюк я видел в нескольких системах, написанных на Дельфях - там проблема крылась в том, что событие сохранения при смене отбора пишется в очередь событий, а события из кода исполняются сразу.
P.S. никогда не использую редактирование в списке, так как пользователь по-дурости (уронив что-то на клавиатуру) может испортить справочник и без всяких глюков со стороны программы.

(41)
Вообще то табличная часть - тот же список
Точно также можно уронить что то на клавиатуру
И по идее должен быть этот "глюк"

(42) Испорченный один документ или много документов - всё-таки - разница есть.
P.S. ещё запись изменений спасает, когда "зверя" носом в то, что он поменял.

возможно это тот случай, по которому Юля на Т1С умыла всех..?

(44) Насколько я помню, Юля всех умыла именно с редактированием в форме списка с наложенными отборами. А ТС утверждает, что отборов нет.

(0) имхо, открыть DBF через FoxPro ... и команда Pack тебе поможет ... если конечно потом исключить из кода шизоидную возможность ввода нового элемента при установленном отборе

+(46) ну а если уж последнее так необходимо, то лечится вставкой в ПриОткрытии():

Если Выбран() = 0 Тогда    Записать(); КонецЕсли;