1с имеются записи с одинаковыми измерениями как исправить
При обновлении УПП конфигуратор выдал:
Объект изменен: РегистрСведений.ЗаписиОСтажеДляСЗВ4
ЗаписиОСтажеДляСЗВ4. Имеются записи с одинаковыми измерениями
и принимать изменения отказывается. ТиИ не помогло!?
Написал обработку, запросом сделал сортировку всех записей по измерениям, в надежде, что записи-дубли окажутся соседними. Перебрал все записи, сравнивая каждую последующую запись с предыдущей. дублей не выявлено!?
Как найти дубли-записи с одинаковыми измерениями?
(10) Тяжело с тобой.
Давай на пальцах: сейчас дублей нет. Если обновлять базу - они появляются. Какой из этого можно сделать вывод?
смотри старые измерения и новые. может тип реквизита изменился и вместо разных старых значений неопределено стало в нескольких строках
смотри сстав измерений регистра до и после обновления: либо какие-то измерения удалены, либо стали ресурсами\реквизитами
(11) Конфигурацию базы не меняю, хочу загрузить конфигурацию поставщика того же релиза, что базы. Напрямую, через Поддержка/Настройка поддержки не получается - конфигуратор вылитает по кнопке "Открыть".
(14) Ты меня зачем вот это вот в чем-то пытаешься убедить? Открой свою базу и громко и четко скажи в дисковод, что она не права, и ничего такого ты не имел в виду, раз все так.
(14) Что именно ты хочешь обновить? основную конфигурацию или поставщика? Показания у тебя меняются чтото.
(18) "Бац, бац. и мимо"(с) ТС хотел обновить только конфигурацию поставщика, а получил невольно и изменение основной и конфгурации БД. Которые ему совсем не нужны.
Фраза из (8) "Вроде все совпало по объектам" - настораживает. ТС не в полной мере владеет инструментами или не обладает объективной информацией?
(19) Да, только конфигурацию поставщика, чтобы потом нормально обновляться. По составу измерения РС ЗаписиОСтажеДляСЗВ4 ред. 1.2 теже, а по типу - посмотреть не могу, при попытке открыть конфигурацию поставщика, конфигуратор вылетает.
Каким еще способом можно обновить конфигурацию поставщика?
(21) Т.е. тебя этот факт не настораживает? Не возникает желания узнать - есть ли бэкапы, как часто делаются и где лежат? Ну, подумаешь, что-то в базе вызывает ошибку платформы, от которой она падает в одном месте и хрен его знает, где она начнет падать завтра.
(23) Конфигурация поставщика обновляется при обновлении через поставку. Дальше думай сам, пора ведь когда-нибудь начать уже.
(19) Не совсем понял, в чем сложность с конфигурацией на поддержке. Берешь внешнюю обработку по ссылке или из "ИР мобильные" и запускаешь в базе, основная конфигурация которой содержит новую конфигурацию поставщика, а конфигурация БД - старую. Где я ошибся?
(24) Не приходилось. т.е. снять с поддержки, и поставить вновь со свежей конфигурацией поставщика? Опасаюсь, таже хрень будет - не встанет!?
(25) Он не хотел обновлять основную конфигурацию.
(21) вроде как УПП рекомендуют обновлять поэтапно-не пропуская релизов.
(26) А чем ты рискуешь в таком случае? Устаревшей конфой поставщика, которая до этого нафиг никому не нужна была?
Соглашайся на постановку поддержки и откажись от изменений основной конфигурации -всё норм будет, не боись :)
(29) Не предлагает!? Делаю через Поддержка/Обновить конфигурцию/Выбор файла обновления выбираю ранее сохраненную конфигурацию поставщика, показывает информацию о старой и новой конфигурации поставщика, я соглашаюсь, а в ответ "Файл не содержит доступных обновлений"!? А поэтапно с 1.2 до последнего 1.3 обновлять не реально, сразу никак?
А если сначала снять с поддержки, то сразу говорит "Файл не содержит доступных обновлений"!?
Что нитак делаю?
Выходит сразу заменить на новую конфигурацию поставщика можно сделать либо загрузив ее (как я и сделал, см. (8)), либо сравнить/объединить, предварительно сняв с поддержки.
В обоих случаях конфигуратор делает проверки объектов. А поскольку основная кофигурация не менялась, то получается, что записи-дубли РС уже существуют!?
(36) Это поможет когда записи уже неуникальные. Обычно это проверяет конфигуратор перед применением новой структуры таблиц. Т.е. в данном случае записи только собираются стать неуникальными.
(34)При втором варианте результат может быть неожиданным из-за несовпадения внутренних идентификаторов метаданных.
Посмотреть, возможно измерения из справочников с предопределенными элементами, и происходит изменение этих предопределенных элементов.
Попробовать запросом выбрать записи из регистра по предопределенным элементам.
Как вариант:
1. Выгрузить данные из регистра в ТЧ и сохранить в файле
4. Загрузить данные из файла в ТЧ и заполнить регистр сведений
(38) 2-й вариант прошел успешно! Правда на копии, полученной выгрузкой-загрузкой. Возможно, дубли-записи были, а выгрузкой-загрузкой пролечились? После празников проверю еще раз, если что будут использовать варианты (36) и (39). Всем спс.
Блин, рано я радовался. Не все объекты встали на поддержку (помеченые желтыми кубиками), есть серые - "Объект поставщика снят с поддержки. Имеются дочерние нередактируемые объекты поставщика, препятствующие удалению"!? В этот раз делал стандартно: снял конфигурацию с поддержки (она была от 1.2 редакции), через Сравнить/Объединить загрузил свежую конфигурацию поставщика от 1.3 редакции, соответствующую основной. С предложением поставить на поддержку согласился. Все галочки снял в окне сравнения, чтобы основная конфигурация не изменилась. Нажал "Выполнить", появилось окно "Настройка правил поддержки". В левой части Новые объекты с правилом "Изменения разрешены" отметил "Объект редактируется с сохранением поддержки", остальные не трогал (мне всегда такой настройки хватало, не возниколо необходимости что-то еще включать!?). Сохранение изменений вроде прошли успешно, не было долгих проверок как раньше (через Загрузку конфигурации из файла). И тут такой сюрприз!?
Смотрю, например, ДоговорыКонтрагентов. Ну, добавлено пара своих реквизитов, ФормаЭлемента изменена. все остальные элементы объекта остались на поддержке, а в целом объект снят с поддержки. Почему?
(42) Ожидал худшего (такое наследство досталоь, 5 лет ее как клюшку обновляли), но удаления и создание новых объектов не произошло. Почему не все объекты встали на поддержку? С таким впервые столкнулся.
только один я заметил что автор перепрыгнул через обновления за пару лет.
Уже не в первый раз обращается ко мне клиент с просьбой убрать все доработки из базы. Мол, давно не пользуемся, вообще непонятно, кто делал и зачем. Уже все забыли. А обновлять надо, и надоело тратить на обновление так много времени и денег.
Постараюсь тут описать, как я решил эту проблему.
1) Для начала сохраним конфигурацию поставщика в файл. Конфигурация - Поддержка - Настройка поддержки - Сохранить в файл.
2) Затем полностью снимем конфигурацию с поддержки. Конфигурация - Поддержка - Настройка поддержки - Снять с поддержки.
3) Загрузим полностью сохраненную ранее типовую конфигурацию. Конфигурация - Загрузить конфигурацию из файла.
4) Следующим шагом нужно вычислить проблемные регистры.
Попробуем обновить конфигурацию базы и увидим ошибку. Принять изменения нельзя (кнопка не активна) и написано почему. В моем случае это "ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями." Не закрывая конфигуратор, сразу же заходим в режим предприятия и запускаем мою обработку. Выбираем этот регистр и нажимаем выгрузить. Используя механизм сериализации, данные будут выгружены в xml файл во временный каталог пользователя и регистр будет очищен.
5) Переходим в конфигуратор и пробуем обновить конфигурацию базы данных вновь. У меня еще одна ошибка "НомераЛистовКассовойКниги. Имеются записи с одинаковыми измерениями". Повторяем действия из пункта 4. И делаем до тех пор пока конфигурация не обновится.
После выгрузки создастся каталог с файлами для нужных регистров.
В моем случаем ошибок больше не было. Ругалось только на эти два регистра. После сможете уже принять изменения.
6) Затем нужно восстановить данные очищенных регистров. Открываем режим предприятия, запускаем обработку и нажимаем загрузить.
Интерфейс и смысл обработки очень прост. Данные из проблемных регистров выгружаются в файл (даже картинки) и очищаются. Затем просто восстанавливаются.
По очереди или сразу можете указать имена регистров для выгрузки и очистки. Кнопка "Загрузить" станет активной когда будет создан необходимый каталог с файлами и тем самым станет возможным сделать загрузку.
Если память не изменяет, то сериализатор появился в платформе начиная с версии 8.3.7. Может, и раньше. Следовательно, обработка должна работать на этой и выше версиях платформ.
Специальные предложения
(6) да-да, был такой случай:
- бухгалтер говорит не хочу лишнего платить - верните все к типовой, т.к. никакие эти доработки не используем
- согласно твоей методе сносим измерение вместе СО ВСЕМИ ДАННЫМИ (я так понял обработка делает именно так)
- на следующий день она же орёт, зачем Вы ЭТО удалили))) - ВЕРНИТЕ ВСЁ КАК БЫЛО
конечно же ей подсунули тестовую - т.к. знали что 99% этим закончится
(26)Моя обработка возьмет все данные, скопирует их в файл, затем восстановит. Уже надоело про это писать.
(27) я не хотел Вас обидеть, обработка нужная и полезная.
Просто не очень понял как она их восстановит - если я ставлю регистр сведений на замок и там пропадает мое измерение.
Вот эту ситуацию хотел описать - например есть РС.ТиповойРегистр
Типовое измерение / Мое измерение / Типовой ресурс
Контрагент1 / Машина1 / 1
Контрагент1 / Машина2 / 2
Контрагент1 / Машина3 / 3
После загрузки конфигурации поставщика - пропадает измерение
Далее загружаем данные из файла
Типовое измерение / Типовой ресурс
Контрагент1 / 3
Вот так ведь будет выглядеть РС с данными после этих манипуляций - поправьте пож-та если я ошибаюсь.
Спасибо
(28)не в коем случае я не обиделся. Просто много раз об этом уже писал. Вашу ситуацию, кстати, вообще не рассматривал. По логике будет да как вы сказали. Не проверял. Если ошибку при десириализации не выдаст и восстановит, то свое измерение просто пропустится. Будет время, попробую, отпишусь. Спасибо за наводку.
(28)должен восстановить с одинаковым набором измерений. Просто без вашего измерения. Попробую проверить.
(2) Ну обработка с дублями ничего не делает. Она очищает регистр полностью. А потом просто возвращает к исходному состоянию. С теми ошибочными данными, что были раньше. Смысл этой работы именно вернуться к типовой.
(4) я думал, что при перезаписи регистры становятся без дублей - старые записи перезаписываются новыми согласно измерениям - я так думал, видимо не так.
(9)Нет. Они сначала выгружаются, полностью, в том виде в котором есть. Потом полностью очищаются. Потом нужно принять изменения и загрузить данные регистров вновь. С теме же ошибочными данными, что и ранее. Выгружаются в файл.
Подобные обновления сомнительно вообще делать, т. к. они идут с некоторой потерей данных. Конечно, если клиента это устраивает, то можно и так.
(5) о тех данных, из-за удаления которых стала появляться ошибка "Имеются записи с одинаковыми измерениями"
(13)вы, видимо, не до конца поняли что делает обработка. По итогу работы все данные на месте. Со своими прежними проблемами. Решение этих проблем в этой разработке не рассматривается.
В инструментах разработчика есть функционал, который умеет анализировать и исправлять такие проблемы. Подготовка к изменению структуры БД.
(7) сделайте публикацию, вставьте сюда ссылку на статью - сделайте обзор. я к примеру не в курсе , о чем вы.
(8)Полазав в нете, нашел только это
(с позволения модераторов кину сюда ссылку). Любопытно подсмотреть как у них реализован поиск проблемных регистров. А то думать над этим пока нет времени. Это бы сильно упростило (сделала бы более универсальной) лично мою текущую разработку.
(12)О, Боже. Посмотрел как реализован поиск проблемных регистров. Что-то слишком сложный вариант. Надо искать что-то попроще))
(8) Мне казалось что ИР довольно известны. Все описания есть на сайте, по данному вопросу см. http://devtool1c.ucoz.ru/index/proverka_bazy_dannykh_pered_usecheniem_tipov/0-24 .
По шагам - сначала подготавливаем базу, но не обновляем (т.е. конфигурация сохранена, а кнопка "обновить конфигурацию базы данных" светится). Затем закрываем конфигуратор, запускаем ИР, жмем авто-коррекция. Ир подключится к конфигуратору, увидит различия по регистрам, и предложит варианты действий, останется принять решение.
(16)Не пользовался никогда ИР. Спасибо. Ссылку уже нашел. Уже подсмотрел как реализовано. Можно, конечно, заморочиться и сделать также, но не в рамках этой работы за 1 стармани))
(17) А зачем "делать также"? Это уже реализовано, пользуйтесь. Я повсеместно применял этот механизм, и (к замечанию о сложности) могу сказать - что он гораздо удобнее и проще предложенного. Огромный плюс в том что все регистры видны сразу, а не по-одному. Кроме того, в некоторых случаях сложной реструктуризации описанный в статье подход не применим вовсе. Ждать несколько часов, чтобы увидеть ошибку - "такое себе"..
(18)Моя обработка просто копирует данные и восстанавливает. И все. На премия дарвина я и не претендую. ИР не пользовался никогда. Честно, даже не слышал про это. На УФ тоже есть?
(19) Нет, в УФ только расширение, которое работает в толстом УФ клиенте. Попробуйте, это набор очень удобных механизмов. Я использую ИР уже ~5 лет, и за все это время ни разу не пришлось тратить время на "волшебные велосипеды" - обработок типа "провести эти 10500 документов с отбором по этому контрагенту" и т.п. Там все есть, причем сделано хорошо. Программистом для программистов. Есть описания, есть форум.
Здравствуйте! БУ 3.0.89.38
"Невозможно подключить дополнительную обработку из файла.
Возможно, она не подходит для этой версии программы.
Техническая информация:
Метод объекта не обнаружен (СведенияОВнешнейОбработке)"
?
Спасибо очень помогли! Не загружался CFник, пришлось удалить 2 регистра сведений и через вашу обработку перенес их.
Обработка в коде «ПриСозданииНаСервере» создает каталог кодом:
Каталог = КаталогВременныхФайлов() + "RegisterData";
а в процедуре «СериализоватьРегистр» дополняет его именем файла:
ИмяФайла = Каталог + "\" + ИмяРегистра +"_"++"_"+".xml";
В таком варианте, если запустить обработку сразу на нескольких копиях обновляемой базы, либо запустить повторно перезапись в одной базе - создастся временный файл xml с одинаковым адресом и именем файла, что может привести к затиранию данного файла повторной выгрузкой, либо выгрузкой этого же регистра из другой копии базы. Это является уязвимостью обработки и может привести к потере данных. К тому же, это усложняет возможность редактировать файл выгрузки вручную, поскольку неизвестно место его сохранения.
Аналогично, если выгрузка регистра производится на одном сервере, а загрузка происходит на другом - обработка не работает, потому что на другом сервере не может найти указанный файл, выгруженный на первом сервере.
Гораздо правильнее было бы создать диалог выбора файла для сохраняемого файла xml, чтобы пользователь мог сам управлять промежуточным файлом выгрузки и определяться с его выгрузкой и загрузкой по кнопкам «выгрузить» и «загрузить».
Уже не в первый раз обращается ко мне клиент с просьбой убрать все доработки из базы. Мол, давно не пользуемся, вообще непонятно, кто делал и зачем. Уже все забыли. А обновлять надо, и надоело тратить на обновление так много времени и денег.
Постараюсь тут описать, как я решил эту проблему.
1) Для начала сохраним конфигурацию поставщика в файл. Конфигурация - Поддержка - Настройка поддержки - Сохранить в файл.
2) Затем полностью снимем конфигурацию с поддержки. Конфигурация - Поддержка - Настройка поддержки - Снять с поддержки.
3) Загрузим полностью сохраненную ранее типовую конфигурацию. Конфигурация - Загрузить конфигурацию из файла.
4) Следующим шагом нужно вычислить проблемные регистры.
Попробуем обновить конфигурацию базы и увидим ошибку. Принять изменения нельзя (кнопка не активна) и написано почему. В моем случае это "ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями." Не закрывая конфигуратор, сразу же заходим в режим предприятия и запускаем мою обработку. Выбираем этот регистр и нажимаем выгрузить. Используя механизм сериализации, данные будут выгружены в xml файл во временный каталог пользователя и регистр будет очищен.
5) Переходим в конфигуратор и пробуем обновить конфигурацию базы данных вновь. У меня еще одна ошибка "НомераЛистовКассовойКниги. Имеются записи с одинаковыми измерениями". Повторяем действия из пункта 4. И делаем до тех пор пока конфигурация не обновится.
После выгрузки создастся каталог с файлами для нужных регистров.
В моем случаем ошибок больше не было. Ругалось только на эти два регистра. После сможете уже принять изменения.
6) Затем нужно восстановить данные очищенных регистров. Открываем режим предприятия, запускаем обработку и нажимаем загрузить.
Интерфейс и смысл обработки очень прост. Данные из проблемных регистров выгружаются в файл (даже картинки) и очищаются. Затем просто восстанавливаются.
По очереди или сразу можете указать имена регистров для выгрузки и очистки. Кнопка "Загрузить" станет активной когда будет создан необходимый каталог с файлами и тем самым станет возможным сделать загрузку.
Если память не изменяет, то сериализатор появился в платформе начиная с версии 8.3.7. Может, и раньше. Следовательно, обработка должна работать на этой и выше версиях платформ.
Специальные предложения
(6) да-да, был такой случай:
- бухгалтер говорит не хочу лишнего платить - верните все к типовой, т.к. никакие эти доработки не используем
- согласно твоей методе сносим измерение вместе СО ВСЕМИ ДАННЫМИ (я так понял обработка делает именно так)
- на следующий день она же орёт, зачем Вы ЭТО удалили))) - ВЕРНИТЕ ВСЁ КАК БЫЛО
конечно же ей подсунули тестовую - т.к. знали что 99% этим закончится
(26)Моя обработка возьмет все данные, скопирует их в файл, затем восстановит. Уже надоело про это писать.
(27) я не хотел Вас обидеть, обработка нужная и полезная.
Просто не очень понял как она их восстановит - если я ставлю регистр сведений на замок и там пропадает мое измерение.
Вот эту ситуацию хотел описать - например есть РС.ТиповойРегистр
Типовое измерение / Мое измерение / Типовой ресурс
Контрагент1 / Машина1 / 1
Контрагент1 / Машина2 / 2
Контрагент1 / Машина3 / 3
После загрузки конфигурации поставщика - пропадает измерение
Далее загружаем данные из файла
Типовое измерение / Типовой ресурс
Контрагент1 / 3
Вот так ведь будет выглядеть РС с данными после этих манипуляций - поправьте пож-та если я ошибаюсь.
Спасибо
(28)не в коем случае я не обиделся. Просто много раз об этом уже писал. Вашу ситуацию, кстати, вообще не рассматривал. По логике будет да как вы сказали. Не проверял. Если ошибку при десириализации не выдаст и восстановит, то свое измерение просто пропустится. Будет время, попробую, отпишусь. Спасибо за наводку.
(28)должен восстановить с одинаковым набором измерений. Просто без вашего измерения. Попробую проверить.
(2) Ну обработка с дублями ничего не делает. Она очищает регистр полностью. А потом просто возвращает к исходному состоянию. С теми ошибочными данными, что были раньше. Смысл этой работы именно вернуться к типовой.
(4) я думал, что при перезаписи регистры становятся без дублей - старые записи перезаписываются новыми согласно измерениям - я так думал, видимо не так.
(9)Нет. Они сначала выгружаются, полностью, в том виде в котором есть. Потом полностью очищаются. Потом нужно принять изменения и загрузить данные регистров вновь. С теме же ошибочными данными, что и ранее. Выгружаются в файл.
Подобные обновления сомнительно вообще делать, т. к. они идут с некоторой потерей данных. Конечно, если клиента это устраивает, то можно и так.
(5) о тех данных, из-за удаления которых стала появляться ошибка "Имеются записи с одинаковыми измерениями"
(13)вы, видимо, не до конца поняли что делает обработка. По итогу работы все данные на месте. Со своими прежними проблемами. Решение этих проблем в этой разработке не рассматривается.
В инструментах разработчика есть функционал, который умеет анализировать и исправлять такие проблемы. Подготовка к изменению структуры БД.
(7) сделайте публикацию, вставьте сюда ссылку на статью - сделайте обзор. я к примеру не в курсе , о чем вы.
(8)Полазав в нете, нашел только это
(с позволения модераторов кину сюда ссылку). Любопытно подсмотреть как у них реализован поиск проблемных регистров. А то думать над этим пока нет времени. Это бы сильно упростило (сделала бы более универсальной) лично мою текущую разработку.
(12)О, Боже. Посмотрел как реализован поиск проблемных регистров. Что-то слишком сложный вариант. Надо искать что-то попроще))
(8) Мне казалось что ИР довольно известны. Все описания есть на сайте, по данному вопросу см. http://devtool1c.ucoz.ru/index/proverka_bazy_dannykh_pered_usecheniem_tipov/0-24 .
По шагам - сначала подготавливаем базу, но не обновляем (т.е. конфигурация сохранена, а кнопка "обновить конфигурацию базы данных" светится). Затем закрываем конфигуратор, запускаем ИР, жмем авто-коррекция. Ир подключится к конфигуратору, увидит различия по регистрам, и предложит варианты действий, останется принять решение.
(16)Не пользовался никогда ИР. Спасибо. Ссылку уже нашел. Уже подсмотрел как реализовано. Можно, конечно, заморочиться и сделать также, но не в рамках этой работы за 1 стармани))
(17) А зачем "делать также"? Это уже реализовано, пользуйтесь. Я повсеместно применял этот механизм, и (к замечанию о сложности) могу сказать - что он гораздо удобнее и проще предложенного. Огромный плюс в том что все регистры видны сразу, а не по-одному. Кроме того, в некоторых случаях сложной реструктуризации описанный в статье подход не применим вовсе. Ждать несколько часов, чтобы увидеть ошибку - "такое себе"..
(18)Моя обработка просто копирует данные и восстанавливает. И все. На премия дарвина я и не претендую. ИР не пользовался никогда. Честно, даже не слышал про это. На УФ тоже есть?
(19) Нет, в УФ только расширение, которое работает в толстом УФ клиенте. Попробуйте, это набор очень удобных механизмов. Я использую ИР уже ~5 лет, и за все это время ни разу не пришлось тратить время на "волшебные велосипеды" - обработок типа "провести эти 10500 документов с отбором по этому контрагенту" и т.п. Там все есть, причем сделано хорошо. Программистом для программистов. Есть описания, есть форум.
Здравствуйте! БУ 3.0.89.38
"Невозможно подключить дополнительную обработку из файла.
Возможно, она не подходит для этой версии программы.
Техническая информация:
Метод объекта не обнаружен (СведенияОВнешнейОбработке)"
?
Спасибо очень помогли! Не загружался CFник, пришлось удалить 2 регистра сведений и через вашу обработку перенес их.
Обработка в коде «ПриСозданииНаСервере» создает каталог кодом:
Каталог = КаталогВременныхФайлов() + "RegisterData";
а в процедуре «СериализоватьРегистр» дополняет его именем файла:
ИмяФайла = Каталог + "\" + ИмяРегистра +"_"++"_"+".xml";
В таком варианте, если запустить обработку сразу на нескольких копиях обновляемой базы, либо запустить повторно перезапись в одной базе - создастся временный файл xml с одинаковым адресом и именем файла, что может привести к затиранию данного файла повторной выгрузкой, либо выгрузкой этого же регистра из другой копии базы. Это является уязвимостью обработки и может привести к потере данных. К тому же, это усложняет возможность редактировать файл выгрузки вручную, поскольку неизвестно место его сохранения.
Аналогично, если выгрузка регистра производится на одном сервере, а загрузка происходит на другом - обработка не работает, потому что на другом сервере не может найти указанный файл, выгруженный на первом сервере.
Гораздо правильнее было бы создать диалог выбора файла для сохраняемого файла xml, чтобы пользователь мог сам управлять промежуточным файлом выгрузки и определяться с его выгрузкой и загрузкой по кнопкам «выгрузить» и «загрузить».
Уже не в первый раз обращается ко мне клиент с просьбой убрать все доработки из базы. Мол, давно не пользуемся, вообще непонятно, кто делал и зачем. Уже все забыли. А обновлять надо, и надоело тратить на обновление так много времени и денег.
Постараюсь тут описать, как я решил эту проблему.
1) Для начала сохраним конфигурацию поставщика в файл. Конфигурация - Поддержка - Настройка поддержки - Сохранить в файл.
2) Затем полностью снимем конфигурацию с поддержки. Конфигурация - Поддержка - Настройка поддержки - Снять с поддержки.
3) Загрузим полностью сохраненную ранее типовую конфигурацию. Конфигурация - Загрузить конфигурацию из файла.
4) Следующим шагом нужно вычислить проблемные регистры.
Попробуем обновить конфигурацию базы и увидим ошибку. Принять изменения нельзя (кнопка не активна) и написано почему. В моем случае это "ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями." Не закрывая конфигуратор, сразу же заходим в режим предприятия и запускаем мою обработку. Выбираем этот регистр и нажимаем выгрузить. Используя механизм сериализации, данные будут выгружены в xml файл во временный каталог пользователя и регистр будет очищен.
5) Переходим в конфигуратор и пробуем обновить конфигурацию базы данных вновь. У меня еще одна ошибка "НомераЛистовКассовойКниги. Имеются записи с одинаковыми измерениями". Повторяем действия из пункта 4. И делаем до тех пор пока конфигурация не обновится.
После выгрузки создастся каталог с файлами для нужных регистров.
В моем случаем ошибок больше не было. Ругалось только на эти два регистра. После сможете уже принять изменения.
6) Затем нужно восстановить данные очищенных регистров. Открываем режим предприятия, запускаем обработку и нажимаем загрузить.
Интерфейс и смысл обработки очень прост. Данные из проблемных регистров выгружаются в файл (даже картинки) и очищаются. Затем просто восстанавливаются.
По очереди или сразу можете указать имена регистров для выгрузки и очистки. Кнопка "Загрузить" станет активной когда будет создан необходимый каталог с файлами и тем самым станет возможным сделать загрузку.
Если память не изменяет, то сериализатор появился в платформе начиная с версии 8.3.7. Может, и раньше. Следовательно, обработка должна работать на этой и выше версиях платформ.
Специальные предложения
(6) да-да, был такой случай:
- бухгалтер говорит не хочу лишнего платить - верните все к типовой, т.к. никакие эти доработки не используем
- согласно твоей методе сносим измерение вместе СО ВСЕМИ ДАННЫМИ (я так понял обработка делает именно так)
- на следующий день она же орёт, зачем Вы ЭТО удалили))) - ВЕРНИТЕ ВСЁ КАК БЫЛО
конечно же ей подсунули тестовую - т.к. знали что 99% этим закончится
(26)Моя обработка возьмет все данные, скопирует их в файл, затем восстановит. Уже надоело про это писать.
(27) я не хотел Вас обидеть, обработка нужная и полезная.
Просто не очень понял как она их восстановит - если я ставлю регистр сведений на замок и там пропадает мое измерение.
Вот эту ситуацию хотел описать - например есть РС.ТиповойРегистр
Типовое измерение / Мое измерение / Типовой ресурс
Контрагент1 / Машина1 / 1
Контрагент1 / Машина2 / 2
Контрагент1 / Машина3 / 3
После загрузки конфигурации поставщика - пропадает измерение
Далее загружаем данные из файла
Типовое измерение / Типовой ресурс
Контрагент1 / 3
Вот так ведь будет выглядеть РС с данными после этих манипуляций - поправьте пож-та если я ошибаюсь.
Спасибо
(28)не в коем случае я не обиделся. Просто много раз об этом уже писал. Вашу ситуацию, кстати, вообще не рассматривал. По логике будет да как вы сказали. Не проверял. Если ошибку при десириализации не выдаст и восстановит, то свое измерение просто пропустится. Будет время, попробую, отпишусь. Спасибо за наводку.
(28)должен восстановить с одинаковым набором измерений. Просто без вашего измерения. Попробую проверить.
(2) Ну обработка с дублями ничего не делает. Она очищает регистр полностью. А потом просто возвращает к исходному состоянию. С теми ошибочными данными, что были раньше. Смысл этой работы именно вернуться к типовой.
(4) я думал, что при перезаписи регистры становятся без дублей - старые записи перезаписываются новыми согласно измерениям - я так думал, видимо не так.
(9)Нет. Они сначала выгружаются, полностью, в том виде в котором есть. Потом полностью очищаются. Потом нужно принять изменения и загрузить данные регистров вновь. С теме же ошибочными данными, что и ранее. Выгружаются в файл.
Подобные обновления сомнительно вообще делать, т. к. они идут с некоторой потерей данных. Конечно, если клиента это устраивает, то можно и так.
(5) о тех данных, из-за удаления которых стала появляться ошибка "Имеются записи с одинаковыми измерениями"
(13)вы, видимо, не до конца поняли что делает обработка. По итогу работы все данные на месте. Со своими прежними проблемами. Решение этих проблем в этой разработке не рассматривается.
В инструментах разработчика есть функционал, который умеет анализировать и исправлять такие проблемы. Подготовка к изменению структуры БД.
(7) сделайте публикацию, вставьте сюда ссылку на статью - сделайте обзор. я к примеру не в курсе , о чем вы.
(8)Полазав в нете, нашел только это
(с позволения модераторов кину сюда ссылку). Любопытно подсмотреть как у них реализован поиск проблемных регистров. А то думать над этим пока нет времени. Это бы сильно упростило (сделала бы более универсальной) лично мою текущую разработку.
(12)О, Боже. Посмотрел как реализован поиск проблемных регистров. Что-то слишком сложный вариант. Надо искать что-то попроще))
(8) Мне казалось что ИР довольно известны. Все описания есть на сайте, по данному вопросу см. http://devtool1c.ucoz.ru/index/proverka_bazy_dannykh_pered_usecheniem_tipov/0-24 .
По шагам - сначала подготавливаем базу, но не обновляем (т.е. конфигурация сохранена, а кнопка "обновить конфигурацию базы данных" светится). Затем закрываем конфигуратор, запускаем ИР, жмем авто-коррекция. Ир подключится к конфигуратору, увидит различия по регистрам, и предложит варианты действий, останется принять решение.
(16)Не пользовался никогда ИР. Спасибо. Ссылку уже нашел. Уже подсмотрел как реализовано. Можно, конечно, заморочиться и сделать также, но не в рамках этой работы за 1 стармани))
(17) А зачем "делать также"? Это уже реализовано, пользуйтесь. Я повсеместно применял этот механизм, и (к замечанию о сложности) могу сказать - что он гораздо удобнее и проще предложенного. Огромный плюс в том что все регистры видны сразу, а не по-одному. Кроме того, в некоторых случаях сложной реструктуризации описанный в статье подход не применим вовсе. Ждать несколько часов, чтобы увидеть ошибку - "такое себе"..
(18)Моя обработка просто копирует данные и восстанавливает. И все. На премия дарвина я и не претендую. ИР не пользовался никогда. Честно, даже не слышал про это. На УФ тоже есть?
(19) Нет, в УФ только расширение, которое работает в толстом УФ клиенте. Попробуйте, это набор очень удобных механизмов. Я использую ИР уже ~5 лет, и за все это время ни разу не пришлось тратить время на "волшебные велосипеды" - обработок типа "провести эти 10500 документов с отбором по этому контрагенту" и т.п. Там все есть, причем сделано хорошо. Программистом для программистов. Есть описания, есть форум.
Здравствуйте! БУ 3.0.89.38
"Невозможно подключить дополнительную обработку из файла.
Возможно, она не подходит для этой версии программы.
Техническая информация:
Метод объекта не обнаружен (СведенияОВнешнейОбработке)"
?
Спасибо очень помогли! Не загружался CFник, пришлось удалить 2 регистра сведений и через вашу обработку перенес их.
Обработка в коде «ПриСозданииНаСервере» создает каталог кодом:
Каталог = КаталогВременныхФайлов() + "RegisterData";
а в процедуре «СериализоватьРегистр» дополняет его именем файла:
ИмяФайла = Каталог + "\" + ИмяРегистра +"_"++"_"+".xml";
В таком варианте, если запустить обработку сразу на нескольких копиях обновляемой базы, либо запустить повторно перезапись в одной базе - создастся временный файл xml с одинаковым адресом и именем файла, что может привести к затиранию данного файла повторной выгрузкой, либо выгрузкой этого же регистра из другой копии базы. Это является уязвимостью обработки и может привести к потере данных. К тому же, это усложняет возможность редактировать файл выгрузки вручную, поскольку неизвестно место его сохранения.
Аналогично, если выгрузка регистра производится на одном сервере, а загрузка происходит на другом - обработка не работает, потому что на другом сервере не может найти указанный файл, выгруженный на первом сервере.
Гораздо правильнее было бы создать диалог выбора файла для сохраняемого файла xml, чтобы пользователь мог сам управлять промежуточным файлом выгрузки и определяться с его выгрузкой и загрузкой по кнопкам «выгрузить» и «загрузить».
Уже не в первый раз обращается ко мне клиент с просьбой убрать все доработки из базы. Мол, давно не пользуемся, вообще непонятно, кто делал и зачем. Уже все забыли. А обновлять надо, и надоело тратить на обновление так много времени и денег.
Постараюсь тут описать, как я решил эту проблему.
1) Для начала сохраним конфигурацию поставщика в файл. Конфигурация - Поддержка - Настройка поддержки - Сохранить в файл.
2) Затем полностью снимем конфигурацию с поддержки. Конфигурация - Поддержка - Настройка поддержки - Снять с поддержки.
3) Загрузим полностью сохраненную ранее типовую конфигурацию. Конфигурация - Загрузить конфигурацию из файла.
4) Следующим шагом нужно вычислить проблемные регистры.
Попробуем обновить конфигурацию базы и увидим ошибку. Принять изменения нельзя (кнопка не активна) и написано почему. В моем случае это "ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями." Не закрывая конфигуратор, сразу же заходим в режим предприятия и запускаем мою обработку. Выбираем этот регистр и нажимаем выгрузить. Используя механизм сериализации, данные будут выгружены в xml файл во временный каталог пользователя и регистр будет очищен.
5) Переходим в конфигуратор и пробуем обновить конфигурацию базы данных вновь. У меня еще одна ошибка "НомераЛистовКассовойКниги. Имеются записи с одинаковыми измерениями". Повторяем действия из пункта 4. И делаем до тех пор пока конфигурация не обновится.
После выгрузки создастся каталог с файлами для нужных регистров.
В моем случаем ошибок больше не было. Ругалось только на эти два регистра. После сможете уже принять изменения.
6) Затем нужно восстановить данные очищенных регистров. Открываем режим предприятия, запускаем обработку и нажимаем загрузить.
Интерфейс и смысл обработки очень прост. Данные из проблемных регистров выгружаются в файл (даже картинки) и очищаются. Затем просто восстанавливаются.
По очереди или сразу можете указать имена регистров для выгрузки и очистки. Кнопка "Загрузить" станет активной когда будет создан необходимый каталог с файлами и тем самым станет возможным сделать загрузку.
Если память не изменяет, то сериализатор появился в платформе начиная с версии 8.3.7. Может, и раньше. Следовательно, обработка должна работать на этой и выше версиях платформ.
Специальные предложения
(6) да-да, был такой случай:
- бухгалтер говорит не хочу лишнего платить - верните все к типовой, т.к. никакие эти доработки не используем
- согласно твоей методе сносим измерение вместе СО ВСЕМИ ДАННЫМИ (я так понял обработка делает именно так)
- на следующий день она же орёт, зачем Вы ЭТО удалили))) - ВЕРНИТЕ ВСЁ КАК БЫЛО
конечно же ей подсунули тестовую - т.к. знали что 99% этим закончится
(26)Моя обработка возьмет все данные, скопирует их в файл, затем восстановит. Уже надоело про это писать.
(27) я не хотел Вас обидеть, обработка нужная и полезная.
Просто не очень понял как она их восстановит - если я ставлю регистр сведений на замок и там пропадает мое измерение.
Вот эту ситуацию хотел описать - например есть РС.ТиповойРегистр
Типовое измерение / Мое измерение / Типовой ресурс
Контрагент1 / Машина1 / 1
Контрагент1 / Машина2 / 2
Контрагент1 / Машина3 / 3
После загрузки конфигурации поставщика - пропадает измерение
Далее загружаем данные из файла
Типовое измерение / Типовой ресурс
Контрагент1 / 3
Вот так ведь будет выглядеть РС с данными после этих манипуляций - поправьте пож-та если я ошибаюсь.
Спасибо
(28)не в коем случае я не обиделся. Просто много раз об этом уже писал. Вашу ситуацию, кстати, вообще не рассматривал. По логике будет да как вы сказали. Не проверял. Если ошибку при десириализации не выдаст и восстановит, то свое измерение просто пропустится. Будет время, попробую, отпишусь. Спасибо за наводку.
(28)должен восстановить с одинаковым набором измерений. Просто без вашего измерения. Попробую проверить.
(2) Ну обработка с дублями ничего не делает. Она очищает регистр полностью. А потом просто возвращает к исходному состоянию. С теми ошибочными данными, что были раньше. Смысл этой работы именно вернуться к типовой.
(4) я думал, что при перезаписи регистры становятся без дублей - старые записи перезаписываются новыми согласно измерениям - я так думал, видимо не так.
(9)Нет. Они сначала выгружаются, полностью, в том виде в котором есть. Потом полностью очищаются. Потом нужно принять изменения и загрузить данные регистров вновь. С теме же ошибочными данными, что и ранее. Выгружаются в файл.
Подобные обновления сомнительно вообще делать, т. к. они идут с некоторой потерей данных. Конечно, если клиента это устраивает, то можно и так.
(5) о тех данных, из-за удаления которых стала появляться ошибка "Имеются записи с одинаковыми измерениями"
(13)вы, видимо, не до конца поняли что делает обработка. По итогу работы все данные на месте. Со своими прежними проблемами. Решение этих проблем в этой разработке не рассматривается.
В инструментах разработчика есть функционал, который умеет анализировать и исправлять такие проблемы. Подготовка к изменению структуры БД.
(7) сделайте публикацию, вставьте сюда ссылку на статью - сделайте обзор. я к примеру не в курсе , о чем вы.
(8)Полазав в нете, нашел только это
(с позволения модераторов кину сюда ссылку). Любопытно подсмотреть как у них реализован поиск проблемных регистров. А то думать над этим пока нет времени. Это бы сильно упростило (сделала бы более универсальной) лично мою текущую разработку.
(12)О, Боже. Посмотрел как реализован поиск проблемных регистров. Что-то слишком сложный вариант. Надо искать что-то попроще))
(8) Мне казалось что ИР довольно известны. Все описания есть на сайте, по данному вопросу см. http://devtool1c.ucoz.ru/index/proverka_bazy_dannykh_pered_usecheniem_tipov/0-24 .
По шагам - сначала подготавливаем базу, но не обновляем (т.е. конфигурация сохранена, а кнопка "обновить конфигурацию базы данных" светится). Затем закрываем конфигуратор, запускаем ИР, жмем авто-коррекция. Ир подключится к конфигуратору, увидит различия по регистрам, и предложит варианты действий, останется принять решение.
(16)Не пользовался никогда ИР. Спасибо. Ссылку уже нашел. Уже подсмотрел как реализовано. Можно, конечно, заморочиться и сделать также, но не в рамках этой работы за 1 стармани))
(17) А зачем "делать также"? Это уже реализовано, пользуйтесь. Я повсеместно применял этот механизм, и (к замечанию о сложности) могу сказать - что он гораздо удобнее и проще предложенного. Огромный плюс в том что все регистры видны сразу, а не по-одному. Кроме того, в некоторых случаях сложной реструктуризации описанный в статье подход не применим вовсе. Ждать несколько часов, чтобы увидеть ошибку - "такое себе"..
(18)Моя обработка просто копирует данные и восстанавливает. И все. На премия дарвина я и не претендую. ИР не пользовался никогда. Честно, даже не слышал про это. На УФ тоже есть?
(19) Нет, в УФ только расширение, которое работает в толстом УФ клиенте. Попробуйте, это набор очень удобных механизмов. Я использую ИР уже ~5 лет, и за все это время ни разу не пришлось тратить время на "волшебные велосипеды" - обработок типа "провести эти 10500 документов с отбором по этому контрагенту" и т.п. Там все есть, причем сделано хорошо. Программистом для программистов. Есть описания, есть форум.
Здравствуйте! БУ 3.0.89.38
"Невозможно подключить дополнительную обработку из файла.
Возможно, она не подходит для этой версии программы.
Техническая информация:
Метод объекта не обнаружен (СведенияОВнешнейОбработке)"
?
Спасибо очень помогли! Не загружался CFник, пришлось удалить 2 регистра сведений и через вашу обработку перенес их.
Обработка в коде «ПриСозданииНаСервере» создает каталог кодом:
Каталог = КаталогВременныхФайлов() + "RegisterData";
а в процедуре «СериализоватьРегистр» дополняет его именем файла:
ИмяФайла = Каталог + "\" + ИмяРегистра +"_"++"_"+".xml";
В таком варианте, если запустить обработку сразу на нескольких копиях обновляемой базы, либо запустить повторно перезапись в одной базе - создастся временный файл xml с одинаковым адресом и именем файла, что может привести к затиранию данного файла повторной выгрузкой, либо выгрузкой этого же регистра из другой копии базы. Это является уязвимостью обработки и может привести к потере данных. К тому же, это усложняет возможность редактировать файл выгрузки вручную, поскольку неизвестно место его сохранения.
Аналогично, если выгрузка регистра производится на одном сервере, а загрузка происходит на другом - обработка не работает, потому что на другом сервере не может найти указанный файл, выгруженный на первом сервере.
Гораздо правильнее было бы создать диалог выбора файла для сохраняемого файла xml, чтобы пользователь мог сам управлять промежуточным файлом выгрузки и определяться с его выгрузкой и загрузкой по кнопкам «выгрузить» и «загрузить».
Читайте также: