v7: Обнаружил косяк в 7-ке - дублируются записи справочника в dbf #646148

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

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

"через Спр.НайтиЭлемент - элемент находился и открывался в режиме редактирования" Это у вас какая-то версия секретная. Обычно при Спр.НайтиЭлемент никто не открывается. Тем более для редактирования. Либо показаны не все "перлы" программиста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+ ну а если уж последнее так необходимо, то лечится вставкой в ПриОткрытии: Если Выбран = 0 Тогда    Записать; КонецЕсли;