Я "изобрела" способ, который меня устраивает - готовлю обновление на копии, а потом снимаю замочки со всех объектов (установить для подчиненных объектов) и загружаю конфигурацию (там может быть 3-3 обновления плюс мои изменения).
И всё бы хорошо!
Но в разработках раруса или вгдб - замочки не снимаются и загрузить конфигурацию нельзя.
Где выход?

Изобретай

Ты настоящая женщина

Хоть кто-то читает мануалы? Там же целые главы про поддержку, про "замочки", про поставки конфигураций, про горизонтальную поддержку...

Нет, все "изобретают"...

(4) 1сники читать не умеют.
А уж работники наблюдателями на выборпх темболее.

У Раруса модули поставляются без исходных текстов - поэтому их изменять нельзя - с остальных же замочки снимаются.
P.S. Рарус ещё то "чудо".

(4) Когда-то читала, но под рукой книжки нет.
Еще вопрос! Универсального отчета в УТ 11 нет?
Опять же! при обновлении выдается ошибка, что записи в регистре стали неуникальными и обновления не происходит.
С чего бы? Если этот регистр не меняется вовсе?

(7) Возможно для регистра добавили регистратор или еще что-то где-то и система решила его структурировать. А тут баз и ошибка в записях. Нужно исправлять задвоение.

баз -> бац   )

(8) Сам регистр не изменился.
Разве что его решили теперь проверить, при том, что неуникальным он уже был.

Запустила тестирование-исправление.
Похоже, что ничего криминального не найдено.

(0) Кста, можно обновлять не на копии, а на пустой базе, куда загружена обновляемая конфигурация. Не нужно возится с выгрузкой/загрузкой копии, да и вообще быстрее будет.
С рарусом опыта не имею, но мысль мелькнула - база случайно не участвует в распределенном обмене данными ?

(12) Нет.
Регистр сведений CRM_ЖурналДокументов.
У меня пока так себе база, тренировочная, я в ней регистр этот почистила - тогда обновилось. Но это ж не дело!
Там добавился ресурс. Ну и что, с чего теперь - неуникальные записи?
Как бы их найти - неуникальные и удалить прицельно? А не всё подряд?
На вид - вроде не видно!

(13) Вспоминается это дело, ой вспоминается. У тебя в регистре какое то измерение вдруг стало пустым (обновились ссылки на этот ресурс, все "левое" превратилось в пустое значение - пустых значений вылезло куча, дублить их нельзя)

(0) А как замочки снимаешь?

(15) в настройке поддержки

(16) Извращенцы ...

Я просто снимаю с поддержки, потом загружаю из cf ...

(0) загрузка через "загрузить конфигурацию"?
лично я не стал бы так делать...
PS чем не устраивает просто "сравнить/объединить"?

(7) зачем универсальный отчет, когда консоль есть?

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

PS: ты только не говори никому, что у тебя файловая версия. Где неуникальность ключей индекса не вызывает ошибку исполнения в режиме 1С:Предприятие :)

(0) Бить линейкой по пальцам за такое

Конечно, файловая!
(17) Ну и я так делаю.
(18) Тогда не будет обновляться конфигурация поставщика.
(19) а консоль где искать?
(20) Как теперь найти, в чем дело?

На вопрос "Как теперь найти?" - ответ: "Запросом" :)

Типа так(болванка):

ВЫБРАТЬ Измерение1, Измерение2,...ИзмерениеХ,
1 КАК Счетчик
ИЗ ТвоегоРегистра
СГРУППИРОВАТЬ *
ИМЕЮЩИЕ СУММА(Счетчик) > 1

(22) мыло давай

(22) сначала обновить обновить конфу поставщика, потом сравнивать со своей заготовкой

(24) [email protected]

Без "сравнить/объединить", "загрузить конфигурацию" обрезает данные. То есть, сперва нужно "сравнить/объединить", затем запустить 1С:Предприятие, а только потом "загрузить конфигурацию"

(0) о, боже

(0)Хороший способ в определенный момент убить конфигурацию базы данных. Главное - не делать архивы.

(27) во первых перед загрузкой надо полностью снять с поддержки, а во вторых попробуй такое проделать со своей базой: выгрузи cf, сними с поддержки конфу и загрузи  - запросто может произойти "обрезание данных"

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

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

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

Не богатая фантазия у вас.

В (0) описан нормальный (рабочий) способ обновления конфигурации на поддержке с возможностью внесения изменений.

Одно только замечание автору:

"Не уверен? Не прыгай! Уверен? Всё равно не прыгай" :)

Обновления надо ставить вовремя - тогда не понадобится перепрыгивать через версии.

(33) Это НЕнормальный способ

(0) Перед загрузкой новой конфигурации снять с поддержки основную конфигурацию

(34) Ну, как бы Вам сказать помягче... не стоит так сильно ограничивать свой кругозор :)

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

+(37) и прыжки тоже не всегда хорошо, обращай внимание на удаляемые объекты. если есть - не прыгай.

(0) рукалицо...

(34) поясни. 8 лет так делаю и вдруг это стало ненормальным способом

(0) А еще можно при обновлении просто снять галки с измененных тобой объектов и пофигу,что их поставщик изменил (видел и таких обновлялщиков, причем у франчей)...

(4) так не работает так как надо

(41) А еще можно по процедурно обновлять. Но это очень сильная магия

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

Обновлять конфигурации находящиеся на поддержке, как это делает автор топика, мягко говоря не удобно. Кроме того, есть вероятность потери данных.

И да, 90% сложности обновления лежит в качестве работы вносителей изменений

(44) А если 1с не предоставляет другого выхода. ТОгда что?

+(37) чето я тупанул. типовой заливаешь вообще все галки снимай, это надо, чтоб версия скакнула. потом с копии заливаешь полностью. т.е. первый раз все галки снять, второй все поставить.

(0) Я тоже когда-то так делал, но уже давно делаю по-нормальному.

(48) Т.е.. Что есть нормальное?

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

Вышло обновления, мне нужно это обновление с моими изменениями натянуть на 20 баз.

Как "нормально" обновить?

(50) накатив типовое обновление на 20 баз

(51) Иногда при обновлении нетиповой - это самый лучший вариант (т.е. подготовить конфигурацию дома и потом "одеть" конфу на рабочую базу). При запуске в режиме предприятия нормально запускается та же процедура обновления базы, что и при обновлении с помощью cfu. Что не так ?

(51) Похерив мои изменения? Или в каждой базе выбирать что и как обновлять. А почему не проще один раз подготовить CF  с изменениями и тупо накатывать обновления?

(53) +100 Я тоже не пойму. У меня этот вариант всегда нормально работал.

(4) Мануалы? Что это?!

(53) пробовал обновлять с глобальным приоритетом рабочей конфигурации?

(52) это вариант хорош для семерки, сам так делал
в восьмере же в одной базе существует несколько вариантов конфигураций. Если есть желание оставить конфу на поддержке, то нужно обновлять как рабочую, так и поставщика. Обновление через сравнение/объединение обновит только рабочую, потом нужно будет еще раз запускать фиктивное обновление со всеми снятыми флажками, для обновления конфы поставщика. Обновление через загрузку стремное. Нафига извращаться, когда есть хороший анализатор изменений и обновление баз практически любой сложности может идти в полуавтоматическом режиме?

(56) Пробовал, такая фигня получается.

И зачем через объединеня, я свой CF через поддржку обновляю. Правда иногда приходится  снимать с поддержки и через загрузку делать. И конфа у меня на поддержки везде, где я ничего не менял, замочки стоят

(7) потому что универсальный отчет основан на построителе отчета, который уже лет примерно как 5 устарел

(56) Ну, вот пример. У меня под PostGress ом крутится переписанная УПП. Обновлять напрямую невозможно - "Нехватка памяти". Причем - на клиенте. Обновить ее можно только на 64-х разрядном клиенте. А он у меня есть только дома ;-)

Дома есть пустая база с нужной мне конфигурацией (она осталась на поддержке).

1. Обновляю ее с помощью cfu. Часто приходится потратить много времени, т.к. переписана сильно ;-)
2. Выгружаю cf-ник (его я буду обновлять / ручками править дальше).
3. Снимаю базу с поддержки вообще. Выгружаю cf-ник, который я буду "натягивать" на рабочую.
4. Прихожу на работу, делаю копию, загружаю cf-ник (через загрузку, а не сравнение-объединение), запускаю в режиме предприятия, жду пока обновиться - все пучком !

p.s. У меня таких "переписанных УПП-шек - 8 штук". Везде изменения разные. И фиг обновишь типовым способом. Однако - траблов не было. Пробовал разные другие способы обновляться - облом.

+(59) В таком режиме живу больше года. У меня еще есть базы, которые нормально обновляются (УПП на полной поддержке, БП, ЗУП) - там обновляю только через cfu.

(27) Какие данные обрезает?
(28) Как убить? (копия - разумеется, есть)

(41) Это один из этапов. А потом - добавляю "по буквам" - где что изменилось.

(59) Так нормальный в целом способ?
И как быть с теми конфигурациями где замочки не снимаются?

Я не понял, а в чем плох способ из (0)?

Мне плох, потому что в конфигурациях, доработанных рарусом - галочки не снимаются.
А еще! "В конфигурации существуют объекты, измененные... продолжить?" - а какие объекты-то? Есть способ получить их список, или ищи-свищи?

"В конфигурации существуют объекты, измененные... продолжить? нсколько я помню это сообщение появляется при обновлении, на этапе сравнения объединения. Там есть фильтр "Показывать объекты". Поизменяйте его.

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

"показывать дважды измененные" есть такое вариант?

Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ
    |    CRM_ЖурналДокументов.ГлавнаяЗапись,
    |    CRM_ЖурналДокументов.Клиент,
    |    CRM_ЖурналДокументов.Объект
    |  1 КАК Счетчик  
    |ИЗ
    |    РегистрСведений.CRM_ЖурналДокументов КАК CRM_ЖурналДокументов
    |СГРУППИРОВАТЬ *
    |ИМЕЮЩИЕ СУММА(Счетчик) > 1 ";

Разумеется, не работает.
1 как счетчик - это что?
А как правильно?
(68) Не видела, сейчас посмотрю!

(61) данные могут обрезаться затронутые изменениями, режим "сравнить/объединить" частично это компенсирует

Ну хоть один пример!

Что там с моим счетчиком? (69) Подскажите, а?

ау?

(73) Вроде так

ВЫБРАТЬ
   CRM_ЖурналДокументов.ГлавнаяЗапись,
   CRM_ЖурналДокументов.Клиент,
   CRM_ЖурналДокументов.Объект,
   Сумма(1) КАК Счетчик  
ИЗ
РегистрСведений.CRM_ЖурналДокументов КАК CRM_ЖурналДокументов
СГРУППИРОВАТЬ
   CRM_ЖурналДокументов.ГлавнаяЗапись,
   CRM_ЖурналДокументов.Клиент,
   CRM_ЖурналДокументов.Объект
ИМЕЮЩИЕ Сумма(1) > 1


(63) "Так нормальный в целом способ?" - ну, я его применяю, когда некуда больше деваться. Хотя каких-то минусов я не нашел, и по логике там ничего плохого вроде нет.

Допустим, я обновляю с помощью cfu УПП с 1.3.38.2. После обновления я получаю 1.3.38.4. Запускаю в режиме предприятия - запускается процедура обновления, которая обрабатывает переход на новую версию, в том числе и перенос данных, если он есть.

Теперь, предположим, я дома создал пустую базу с 1.3.38.2.  После обновления с помощью cfu я опять получаю 1.3.38.4. В режиме предприятия НЕ запускаю. Выгружаю cf на флешечку и иду с ним на работу. Загружаю в рабочую, запускаю в режиме предприятия - запускается та же процедура обновления, которая обрабатывает переход на новую версию. Иными словами, все, что нужно для перехода с 1.3.38.2 на 1.3.38.4 содержится в той cf, которую я принес из дома. ВРОДЕ ! ;-) ;-) ;-)

А почему "вроде" ? А потому, что "где 1С - а где логика" ?!!
Я понимаю, что в любой момент может случиться хотропопый выверт. Поэтому я всегда имею копии, с которых я всегда смогу "утянуть" нужные данные. За год такой жизни с 8 разными УПП-базами проблем не было. Но была бы на основной работе 64-разрядная машинка, не стал бы связываться.

А "задвоения" в справочниках, планах я получал и при обновлении с помощью cfu. Ниче такого - ищешь, чистишь ;-)

Также применяю этот способ у одного из клиентов:
1) у меня его копия - на поддержке
2) у него - снятая с поддержки
Обновляю у себя потом загружаю еще cf-ник.
На делать это стал только после того как никакими способами не удалось победить ошибку при обновлении "...соединение разорвано сервером" ибо у клиента "нищебродский" сервер с 1,5 Гб свободного RAM и 32-битным сервером 1с :(

Не, ну понятно, что если дверь забаррикадирована или подперта снаружи, то можно и через окно :)

Ммм... внесу свои пять копеек.

"Нормально" или "Ненормально" - претит мне это слово. Нет такого термина! Точка.

А вот против "штатное" или "нештатное" обновление - ничего против не имею. Хотя мне лично больше нравится фраза "рекомендованное" :)

Рекомендации по обновлению в каждом обновлении указываются. Придерживаться их или нет - вот в чём вопрос :)

(13) Перечисление изменили, которое в измерении регистра и все.

Ура. Нашла свою ошибку.