Добрый день.
УНФ 1.6.15, чуть переделанная. Все хорошо, документы проведены корректно, типовым механизмом. Делаю ТИИ.

Итог: имею документы "РасходнаяНакладная" без движений - вообще все движения удаляются по ним. Причем только на возвраты поставщикам. Перепровожу документы - движения опять норм. Делаю ТИИ - опять удаляются. И так пожизненно. Что пишет ТИИ:

ЖурналДокументов.ДокументыПоЗапасам
  ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
    Обнаружена ссылка на несуществующий документ. Запись удалена.

Проверка логической целостности. РегистрНакопления.ДоходыИРасходы <Объект не найден> (321:80e2b083fee00c3a11e8582617eccd0e):3
  ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
    Неверная ссылка на регистратор. Запись удалена.

Проверка логической целостности. РегистрНакопления.Закупки <Объект не найден> (321:80e5b083fee00c3a11e8bbdc8454fbed):265
  ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
    Неверная ссылка на регистратор. Запись удалена.

Если что, то эти "не найденные" ссылки - это как раз те самые возвраты поставщику. Отсюда вопрос: что не нравится ТИИ и как сделать так, чтобы база не была "до первой ТИИ"?

У тебя в документе расходная накладная есть ссылки на удаленные документы ? Которые потом в измерения регистра пихаются ? Так что ле ?

(1) у меня нигде нет ссылок на удаленные объекты. В этом и проблема. ТИИ считает, что мои расходки не существуют и удаляет их движения. Хотя они существуют =)
В итоге после ТИИ приходится перепроводить мои расходки, чтобы опять появились движения.

(2) тут рядом было похожее описание, при наличии расширения в базе

Расширений нет?

Ничего не понял.
Покажи движения у документа, которые "удаляет" ТиИ

(3) +
После добавления реквизитов через расширения 1С удаляет элементы при ТиИ

(3) (4) да, есть расширения. причем меняющие структуру, в том числе.
(5) документ расхнакладная делает движения по регистрам накопления. ТИИ их удаляет, а расхнакладная остается.

Но при всем этом в расширении у меня нет реквизитов к расх накладной или к тем регистрам )

(8) Ну так возъми копию удали расширение и запусти ТиИ. Тогда точно можно сказать в нем ли дело или нет

(9) ну судя по той теме, дело должно быть в расширении. Но в реальности я не могу его удалять, т.к. уже база содержит данные, добавленные в расширение.

(10) И что? Это же копия. Нам нужно просто убедиться что дело в расширении, а не в чем то другом. Если после удалении расширения данные будут продолжаться удаляться при ТиИ - значит расширение не виновато

(10) ты смысл тестирования и диагностики понимаешь?

А если все таки дело в расширении остается попробовать на последней 14 платформе - если и там будет всё плохо, то или смериться и не делать ТиИ или отказаться от расширения которое портит данные.

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

(11) при удалении расширения удалятся необходимые объекты ещё до ТиИ.

С уважением, КЭП

Обалдеть тут очередное лечение наблюдаем.

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

(15)
РегистрНакопления.ДоходыИРасходы
РегистрНакопления.Закупки

Сдается мне что это все таки типовые регистры и после удаления расширения ничего с ними не будет.

Так что Акелла промахнулся

(15) Больной утверждает, что расширение не имеет влияния на созданные движения, вроде бы не имеет. Тогда удаление Расширения не скажется на процессе ТИИ и удаляются по каким-то иным причинам

(16) Даже и не начинали. Просто попросили проверить одну теорию.

(13) я уже с 13го релиза накушался какашек, когда "ошибка формата потока" не давала зайти через раз, плюс постоянные вылеты =)
(16) 8.3.12.1685
серверная

(20) Ты слова "на копии" понимаешь?

(20) Уже интересно. И до установки этого релиза платформы ТИИ были и все было нормально? Когда перед этим делали ТИИ?

Как вариант часто при таком раскладе пытаются спасти базу в выгрузкой в DT и восстановлением ее в файловый режим. Затем запускают ТИИ на файловой и смотрят что еще и там происходит. Бывает, что это из-за глюков на СУБД при аварийной перезагузке сервера или еще что-то страшное, но не связанное именно с проблемами в конфигурации, в расширении и т.д.

(21) знаешь, в чем самая печаль? На тестовой базе, на которой плюс минус тоже самое, движения не удаляются. но там режим совместимости 8.3.11 стоит, в отличие от 8.3.12 на боевой. от так

(23) А кроме выдачи ошибок в попытках сделать ТИИ какие-то глюки в работе есть?

(22) перед этим устанавливал 8.3.13 и делал в ней ТИИ. потом поставил 8.3.12 (потому что та сука глючила) и вот сейчас в ней делаю и удаляются движения. Но вот еще при прошлом ТИИ (на 8.3.13) уже эта проблема случилась, а сейчас лишь документов к проблеме добавилось.

(23) Позволь усомниться.

Если мне память не изменяет то 8.3.15 она в режиме совместимости с 8.3.10 При этом при попытки поднять режим совместимости в коде есть несколько мест где проверяется этот режим и программа отказывается работать. Если ты конечно не вырезал эти проверки и не руками поднял режим.

Далее в режиме 8.3.10 нельзя было добавить свои реквизиты, поэтому ТиИ ничего и не удаляет.

(25) В чем проблема на копии удалить расширении и сделать ТиИ, а не гадать на кофейной гущи?

(24) на 8.3.12 из глюков (добавленных) я заметил лишь перерисовку формы при серверных вызовах. Раньше так делали только контекстные, а сейчас и бесконтекстные стали. Это очень плохо, т.к. теперь обработчик ожидания нельзя кормить маленькими серверными вызовами.
В остальном, 12й норм, стабильнее 11го.
(26) там стоял 8.3.10, мы сделали 8.3.12. в коде вырезали.

(28) таким образом, я правильно понимаю, что при практической работе на сервере в вашей базе ТИИ запускать незачем, т.к. явных причин к его запуску нет?

(29) явная причина была в том, что мы недавно ставили 8.3.13 и делали на ней ТИИ в надежде, что ошибки формата потока пропадут. А так да, явных причин нет. Но если вдруг запустим по явной причине, то не хочется потом пол базы лечить вручную

Мы уже начинаем подумывать о том, чтобы реквизиты и объекты добавлять только в основной конфе. Если такой трешак творится при типовых же исправлениях... это же ненадежная система получается до первого дождя.

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

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

Все остальные моменты, что все добавленные структурные изменения вносятся в собственные объекты основной базы, а программный код разрабатывается по расширению - имхо, это Плюс.

(31) Но в частном конкретном случае, в данной ветке, не выглядит проблема, что в этом виновато Расширение. Ваше изложение пока говорит в пользу того, что это режим совместимости и версия платформы. Да, вы их ставите такими для работы с расширением, но не Расширение виновато в том, что глючит ТИИ

(33) ну вот на БП 3.0 у меня стоит тоже 8.3.12 режим и при этом никаких проблем с ТИИ. Но там не добавлены объекты.

А в УНФ у меня добавлены всего-то один свободный регистр сведений (который к удаляемым движениям и даже к регистратору этих движений не имеет никакого отношения) и один булев реквизит в справочник рабочих мест. И всё. Может, это какой-то долбаный глюк, срабатывающих лишь при определенных условиях...

Выгрузить и загрузить через dt не помогло.

(35) то что ТИИ будет глючить дальше в серверном режиме - я и не сомневался. Я думал, что сделаете проверку в файловом режиме. Просто для тестирования , а не внесения изменений в базу.

З.Ы. Что предлагал выше Алексей - на тестовой копии отключить убрать расширение. Понятно, что это лишь для проверки, после которой копию выкинуть и вернутся к исходной базе. Так вот в копии БЕЗ расширения протестировать и убедиться, что ТИИ ничего не найдет. Ну нет ошибок на самом деле. А затем спокойно работать с исходной базой.

"Неверная ссылка на регистратор. Запись удалена."  - навеяло: проверьте корректность конфигурации. Тестирование и исправление, но не данных, - а конфигурации.

(35) Выгрузи и загрузи конфигурацию. Хуже не будет, но может быть поможет.

(38) выгрузил конфу, загрузил конфу, сделал тии - не помогло, движения удалились
(9) удалил все расширения, сделал тии - помогло, движения не удалились.

... но без расширений эта база точно никогда не будет, так что надобно понимать, как дальше с этим жить...

(39) Ты сам знаешь ответ.
1. Отказаться от расширение в пользу переноса регистра в конфигурацию
2. Не делать ТиИ и ждать что когда нибудь, может через год или 2 1С починит расширение

Выбор за тобой

(39) а если на время ТИИ отключать расширения, а затем подключать обратно, данные похерятся?

(40) ситуация гораздо хуже на текущий момент. Релиз 8.3.12 обязателен уже из-за БП и ЗУП. На 8.3.11 такой проблемы не было. Удалил сейчас из расширения данные, которые влияют на структуру бд - не помогло - все равно движения удалились.

Регистр-то поместить в саму бд я могу, мы люди не гордые. Но вот тексты модулей править в основной конфе - это уже перебор. Я вот про этот аспект говорю. Либо перед ТИИ всегда чпокать все расширения? Ну это конечно можно, если они данных за собой не несут, но так уже, в порядке бреда..

(41) отключать не помогает, надо удалять. а если удалять, то да, данные потеряются. но если все данные вести в конфе (с префиксами для удобства) то проблемы вроде как и нет. Лишь бубнотанец, но не безнадёга.

Коллеги сидят, программируют, а я тут опыты ставлю. ТИИ по кд ))

(42) А не делать ТИИ религия запрещает? Шабат, как недавно в новостях писали, запретил лететь самолету?

(42) все просто: 1) не делать ТИИ (зачем так часто?) 2) данные перенести в основную конфу, модули и формы оставить в расширении

Недавно решил перенести все изменения в расширение, а тут читаю теперь уже не первую тему и что-то желание совсем отпало. Переносил изменения от обновления в обновление и попереношу дальше, не тресну.

(47) ты главное каждый день ТИИ запускай, а то и по два раза на день, ага?!

(47) переименуй объекты в пользу префиксов и будет красиво. судя по всему, это и будет трендом ближайшие года три. Пока 1с не начнут вместо функциональных релизов выпускать багфиксы.

(48) (45) не каждый день, но раз в 2 месяца вполне норм. после крупных обновлений.

В общем так. Нашел все влияющие на данные объекты расширения, удалил их. ТИИ сразу обрадовалась и не стала их удалять. Так что ТИИ гарантированно не дружит с данными из расширений, как минимум на платформе 8.3.12.1685.

По итогу решение следующее (одно из):
1) Объекты метаданных, влияющие на структуру БД, добавлять в саму конфу, используя префиксацию для удобства обновлений. Остальное - через расширение. Минусы - обновления будут более, чем в два клика. Плюсы - можно использовать ТИИ.
2) Оставлять конфу на полной коробке, а все метаданные и код писать в расширении. Соответственно, плюсом будет нетронутая коробка (гарантия, что коллега тайком не засадит пару реквизитов, как у меня сейчас...), а минусом невозможность проведения ТИИ.

(51) "гарантия, что коллега тайком не засадит пару реквизитов, как у меня сейчас" - РИБ, гарантия идентичности конфигураций :)

(50) После крупных обновлений чем, типовой?

Вы реально считаете, что типовые конфиги настолько поганые, что после их обновлений нужны ТИИ ?