1С 8.2 Запись с такими ключевыми полями существует! При программной записи. #693386

Добрый вечер! Появилось проблема! Пытаюсь по мере выполнения кода записать регистр сведений. В нем три измерения: Время Пользователь и позывной. И два измерения: менеджер старый и менеджер новый. При попытке записи падает с ошибкой: Обработка.Присвоение_Менеджеру_Позывного.Форма.Форма.Форма}: Ошибка при вызове метода контекста (Записать)     НаборЗаписейРегистра.Записать; по причине: Запись с такими ключевыми полями существует! : ИсторияИзмененияМенеджеров: Александр Васильевич, 27.12.2013 0:00: Вот код: ТекстЗапроса="";     ТекстЗапроса = "select drv_op.cod_op from drv_op where drv_op.cod_drv="+КодВодителя; Помогите разобраться пожалуйста! Заранее спасибо!

три измерения и два измерения - это пять измерений? я нигде не ошибся?

>Запись с такими ключевыми полями существует! это значит, что уже есть запись с такими ключевыми полями

и 2 реквизита :) Все сплю находу :(

Так ключевых поля 3...то есть 3 измерения. А до записи третьего он не доходит. Да и время должно разным быть...

я что-то у тебя цикла не увидел

Я извиняюсь, а зачем Вы читаете набор записей?

Время может быть и одинаковым. Точность - секунда.

бах, и весь регистр в прочитан, отборов то нет, в вдруг там миллионы записей? и зачем его читать? Где отборы по измерениям? при такой записи всегда будет только одна запись в таблице, та что последней писалась. и то только если Записть(Истина), а так да ошибка 100%

А как будет правильно ) Подскажите неразумному :)))

У м У меня почему то время вообще 00:00:00 пишется ((

Может Время это не измерение, а регистр периодический? (что было бы логично) А 0 часов пишется, т.к. периодичность в пределах дня

если нужно добавить запись в регистр (независимый), то можно просто СоздатьМенеджерЗаписи А вообще я не совсем понял код)

А не, судя по  НовЗапись.Время это именно измерение

+ тогда по идее надо состав Дата и время. Хотя если регистр называется ИсторияИзмененияМенеджеров, то историю как раз хранят в периодических регистрах, чтобы смотреть срезы на определенную дату

Регистр непериодический...не стал мудрить с периодическим...

недоперепроектировал?

Я бы объяснил...код изменяет внешний источник данных. Изменения записываются в регистр сведений.

Ага...недодумал...

И еще в ресурс МенеджерОПРСВСтарый почему-то попадает значение "Объект не найден" и код объета.

а по смыслу надо было периодический) Там мутить нечего особо, настроить два свойства и все. Наверняка, дальше тебе будет удобней именно периодический. Как ты будешь получать текущее состояние на дату, брать на максимальную ближайшую дату? Срез последних упрощает это дело)

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

Ну короче ты изобрел периодический регистр с помощью измерения Время, хотя можно было без него)

Попробую на период переделать....а что в процедуру записи в регистр добавить добавить, если он периодический??  И как избавиться от "Объект не найден"

У тебя просто вместо Время будет реквизит по умолчанию Период. Делай с ним то же, что и со временем) И не забудть периодичность настроить, я так понял, тебе в пределах секунды. Насчет не найденного объекта, надо искать, почему его нет. По идее, если б не было, то и не нашел бы по реквизиту, была бы пустая ссылка. Как вариант пока только мысли, что либо ты там его там удалил по ходу дела, уже после создания записи в регистре.

Вот самое странное что это элемент справочника, в справочнике то он есть :) А вообще можно ли сделать это не обработкой а документом, и он будет регистр автоматически заполнять при проведении??

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

Можно. Делаешь подчинение регистратору и прописываешь в обработке проведения формирование движений конструктором. Будет тебе почти все автоматически. Вопрос только откуда ты берешь данные для движения. Я думаю, из предварительно заполненной ТЧ) очень похоже на то)

БД своя. Только вот отчетности по ней нету никакой...все делается через HiDiSQL. включая изменнения в БД. Поэтому все делают ИТшники. Вот и решил на коленке набросать такую вот фигню... :)

да...основная проблема будет где хранить реквизиты ТЧ до изменения. Создавать таблицу значений если только, но как тогда ее передать в обработку проведения :(

чужая в значении внешняя по отношению к 1с

я тут картинку вздумал для подсистемы нарисовать. и что ты думаешь? пришлось применить более удобные инструменты, нежели 1С. не надо ею везде тыкать

ну задачу то я не онимаю, потому сложно сказать. Мне лично не совсем понятно, зачем МенеджерОПРСВСтарый, если суть именно в изменении этого менеджера. Как раз старый хранится в предыдущей записи, а ты как бы каждой новой записью определяешь нового. Тогда, вероятно, все эти телодвижения со старым менеджером не нужны

А при первом изменении будет непонятно кто был старым :((

сделай начальное заполнение по текущим данным