Въпрос: Грешка при актуализиране на RIB възела
Добър ден.
Актуализирах основния възел Rarus-Retail до 2.2.5.27, направих обмен с няколко RIB възела - всичко е наред.
Започнах масивна актуализация на останалите възли (подобно на „горната двойка“ (други RIB магазини)) - изскача грешка в клиентската част:
Разпространение на отчети в регистъра за актуализиране на списъка с рутинни задачи.
манипулатор на отложена актуализация
„Разпространение на отчети. Актуализиране на списъка с рутинни задачи“
Възникна грешка:
"(GeneralModule.GeneralPurpose.Module(3502)): Грешка при извикване на контекстен метод (съдържа)
Връщане на метаданни.Информационни регистри.Съдържа(Метаданниобект);
защото:
Несъответствие на типа (параметър номер „1“).
Някой сблъсквал ли се е с това? Вече се опитах да актуализирам платформата (до максимум 8.3.10 и я тествах на 32-64 компютъра)... не помогна. Но тестовите 2 магазина бяха актуализирани без проблеми, не мога да разбера как.
Отговор:() Ето как инсталирам основния възел. Писах малко за друго: след като развържете възел чрез обработка, следващия път, когато го стартирате, актуализацията на conf не започва веднага, но първо 1C отваря прозорец, в който ви моли да потвърдите, че възелът е не е свързан. След това се актуализира - след актуализацията възелът вече не е в списъка.
Всъщност на 2.1 си спомням, че го актуализирах с този метод, но на 2.2 нещо не работи. Може би в парка вече съм мушкал грешната последователност в действията)
СПОРЕД ТЕМАТА:
Разбрах какво имам. Оказа се, че съм пропуснал:
„В една от версиите 2.2 директорията за разпространение на отчети се появи с предварително дефинирания елемент „Лични данни““ - директория с този елемент беше налична и във 2.1.
Нюансът е следният: задръстванията с възли за актуализиране се наблюдават в онези бази данни, които са създадени от централната точно при версия 2.1.9.18. Всичко, което беше създадено в по-ранни версии, беше актуализирано нормално. Това вероятно обяснява защо няколко TS бази данни също бяха актуализирани успешно и след това имаше проблеми.
Не се опитах да измисля нищо, като създадох нов елемент в директорията и го зададох като предварително дефиниран. Прехвърлих този елемент от копие на центъра към 2.1 чрез разтоварване/зареждане на XML и повторих актуализацията на проблемната „база“ - всичко работи.
() Затова използвайте метода, ако все още не сте намерили отговора.
Въпрос: Грешка при актуализиране на конфигурацията
Актуализирам конфигурацията на Accounting 2.0.64.14 до 2.0.64.24. платформа 8.2.19
Веднага се появява грешка:
Грешка при достъп до файл... път... временен файл.tmp.
Къде да гледам?
Отговор:Този път реших проблема, като изчаках нова „стабилна“ версия
Въпрос: Грешка в потребителските права на BSP
Поздравления!!! Пиша conf, базиран на BSP 2.2, изглежда, че вече имам опит и съм проучил доковете надлъж и нашир, но когато стартирам информационната сигурност за първи път, се появява грешка:(GeneralModule.UsersService.Module(345)): Упълномощаването е неуспешно. Системата ще бъде изключена.
Потребител: Администраторът не е намерен в директорията на потребителите.Възникна грешка при опит за добавяне на потребител към директорията:
„Грешка при актуализиране на информационната база.
Параметърът за ограничаване на достъпа не е попълнен:
„Възможни права за задаване на права на обекти.“За разработчика: може да се наложи поддържащите данни да бъдат актуализирани,
които засягат работата на програмата. За да извършите актуализацията, можете:
- използвайте външна обработка
„Инструменти за програмисти: Актуализиране на данни за поддръжка“,
- или стартирайте програмата с параметъра на командния ред 1C:Enterprise 8
"/C LaunchInformationBaseUpdate",
- или увеличете номера на версията на конфигурацията, така че следващия път, когато стартирате
Приключиха процедурите по актуализиране на данните в информационната база."Кликнете, за да разширите...
Бих искал да чуя отговорите на „опитните“, за последващ активен диалог, може би дори сътрудничество
Отговор:
Vdeg каза:
Проблема решен?
Имам различен проблем: добавям потребител към BSP 2.2.5.29 и той или има пълни права (ако ги добавя ръчно), или никакви (вижда празен интерфейс без нито един справочник или документ). Тъй като в типичните BSP роли изобщо няма квадратчета за достъп до конкретни (мои) директории и документи. Как тогава ще се проследи достъпът на ниво запис за нов потребител???
Кликнете, за да разширите...
Как BSP трябва да знае какви директории имате и как искате да конфигурирате достъпа до тях?
Вероятно трябва да го направим сами
Въпрос: SendingDeliverableNotified Проверката на отдалечения възел е неуспешна
До миналия петък следният код работеше добре..
XdtoSubscriber = FactoryXDTO.Create(FactoryXDTO.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
Нов XDTO сериализатор = Нов XDTO сериализатор (XDTO фабрика);
Абонат = NewSerializerXDTO.ReadXDTO(xdtoSubscriber);
Известие=Ново уведомление за доставка;
Notification.Recipients.Add(Subscriber);
Notification.Text=Текст;
Notification.SoundNotification=SoundNotification.Default;
Notice.Sticker=1;
DATAAuz=ТОКЕН;
SendingDeliverableNotifications.Send(Notification, DataAuz, True);
Сега грешката: Отдалеченият възел не успя да провери. Счупи ми цялата глава. Хванах заявки от сървъра - беше празен, имаше чувството, че не контактува никъде... Пробвах го на три различни машини с различни оси. изсъхна.. помощ...
Отговор:нагоре
Отговор:И така, реших да направя ново изображение на възела. При стартиране на възела се казва, че трябва да започнете с \c да започнете да актуализирате информационната база
и преправете изображението.
Оказва се, че това се дължи на крива на актуализиране.
Опитах се да стартирам с този ключ и да направя обмен със съществуващ възел. Няма стартирани актуализации на възела, не поисках да рестартирам нищо.
И в резултат на това съобщението отново не беше прието в главния възел със същата грешка.
Какво може да се направи?
Мога ли фиктивно да променя нещо в главния възел в conf и да направя размяна? Или няма да актуализира цялата конфигурация, а само това, което променя? Засега ще се опитам да направя възел. Но ще чакам вашите идеи
Въпрос: Разпределена база данни - грешката по време на обмена не е разрешена
Добър ден на всички!
Ситуацията е следната.
При зареждане на обмен от периферен възел получавам съобщението „Конфигурацията на възела за сигурност на разпределената информация не съответства на очакваната.“
След това следвам инструкциите.
Разтоварвам конфигурацията от централната база данни в CF, развързвам периферната база данни от централния възел чрез обработка, премахвам конфигурацията в периферната база данни от поддръжка, зареждам конфигурацията от файл.
Свързвам централния възел за обработка в периферната база данни.
Запази, приложи.
Изтеглям обмена от централната база данни отново.
Зареждам го в периферията. Разтоварвам борсата от периферната база данни.
Зареждам го в централния. Отново получавам съобщението „Конфигурацията на възела за сигурност на разпределената информация не съответства на очакваната.“
Но това е голяма глупост - зареждам конфигурацията в централната база данни и никой не е променил конфигурацията в периферната база данни.
Как да се преодолее подобна грешка?
Отговор:Никога не е хрумвало на никого да съветва такива очевидни неща след много години злоупотреба относно демоничната актуализация :)
Въпрос: RIB и актуализации
Здравейте всички. Предвижда се използването на разпределена информационна сигурност.
конфигурацията е променена. Конфигурацията на централната база данни се актуализира от програмиста. След това тези промени ще бъдат предадени на периферни бази данни с помощта на файлове за обмен.
Въпросът е: какво ще кажете за стартиране на манипулатори след актуализиране на конфигурацията на базата данни и влизане за първи път в потребителски режим?
актуализиране на основната конфигурация - актуализиране на конфигурацията на базата данни - изпълнение на манипулатори за актуализиране в потребителски режим
Например, много издания бяха пропуснати, трябва последователно да актуализирате до 3 издания. Няма проблеми с актуализирането на централната база данни, но какво да кажем за периферните? Също така е необходимо да ги актуализирате на 3 етапа (актуализиране на централната база данни с първата версия, актуализиране на RIB, актуализиране на централната база данни с втората версия, актуализиране на RIB и т.н.?)
Благодаря на всички за помощта!
Отговор:() насочете носа си, не мога да намеря кода, който се изпълнява при регистриране на промени в обект.
Изглежда, че ако използвате метода WhenSendingData, тогава променените обекти все още ще се натрупват в главния възел за изпращане към подчинения възел. И това са допълнителни компютърни ресурси
Затова искам обектите в главния възел да не се регистрират за изпращане веднага в момента на промяната им (при запис например). На кое място например в стандартната Accounting Rev.3 се водят за картотекиране тези обекти?
Въпрос: [РЕШЕНО] Грешка при свързване с онлайн поддръжка
Уважаеми експерти, моля, кажете ми!
1C:Enterprise 8.3 (8.3.11.2899)
На сървъра 1C има няколко работещи бази данни с различни конфигурации, във всички тях интернет поддръжката е свързана и работи нормално. вкл. зареждане на валутни курсове, банки, проверка на контрагенти, SPARK и др.
Настройките на прокси във всички бази данни са изписани еднакво.
Но в базите данни BP-3 KORP винаги се появява грешка:В бордовия дневник:
Неуспешно получаване на билет за удостоверяване от услугата.
Неуспешно зареждане на content(). (GeneralModule.InternetUser SupportClientServer.Module(362)): Грешка при извикване на контекстния метод (SubmitForProcessing)
Отговор = Connection.SendForProcessing(HTTPRequest, ReceivingParameters.ResponseFileName);
защото:
Грешка в интернет: Проверката на отдалечения хост не бе успешнаКликнете, за да разширите...
Пробвах го на различни версии на платформата (8.3.10..., 8.3.11...) и на различни версии на конфигурацията (3.0.54.15, 3.0.57.10).
Тестването и коригирането също не помагат.
Какво може да не е наред?
Наистина ли BP-CORP има достъп до Интернет по специален начин?
Благодаря ти.
Отговор:
Отговор от 1C (това, което беше подчертано в червено, ми помогна):По време на прехода BSP като част от захранващия блок беше актуализиран от 2.4.3 на 2.4.4
В списъка с промени BSP 2.4.4
Повишена сигурност при установяване на защитена връзка с HTTPS интернет услуги. Ако бъдат открити различни проблеми със сертификата на интернет услугата, с която се прави опит за защитена връзка (сертификатът не е валиден, остарял или не е надежден), връзката няма да бъде установена.
В 8.3.10 проверката на сертификата в Windows се извършва с помощта на операционната система." -
Инсталирайте най-новите актуализации за вашата операционна система Те съдържат важни актуализации на системните компоненти, които отговарят за работата със сертификати.
Моля, инсталирайте и най-новите актуализации на основни сертификати, разпространявани от Microsoft в инсталационните пакети.
Изисква версия не по-ниска от IE8.0. Той съдържа важни актуализации на системните компоненти, които отговарят за работата със сертификати.
Като правило, след инсталиране на всички актуализации, проблемът е решен.
Проверете дали ако го въведете в лентата за търсене в Internet Explorer, връзката се отваря.
Потребителят, от чието име работите, има достъп до Интернет.
Ако това е файлова база данни на машината на клиента, трябва да я проверите на нея.
Ако това е база данни клиент-сървър, тогава на сървъра под потребителя, под който работи сървърът 1C.
Проверете само с IE браузър.
Проверете дали портове 443 и 80 са отворени
Ако се използва прокси сървър, проверете дали данните са конфигурирани в менюто Лични настройки.
Ако се използва версията клиент-сървър, тогава трябва да конфигурирате сървъра по такъв начин, че връзката с интернет с браузъра IE да работи правилно под потребителя, от чието име работи 1C сървърът.
Регистрирах проксито в настройките на IE на потребителя, под който работеше 1C сървърът - всичко работи.
Въпрос: Актуализация на Bukh 3
Добър ден
Счетоводство 3
Актуализирах от 3.0.43.208 на 3.0.43.235
грешки
първи
(GeneralModule.MessagingInternal.Module(381)): Грешка при извикване на контекстен метод (ThisNode)
защото:
Намерен е повече от един запис
второ
При извикване на манипулатора за актуализиране:
"MessagingInternal.SetCodeThisEndPoint()"
Възникна грешка:
"(GeneralModule.MessagingInternal.Module(381)): Грешка при извикване на контекстен метод (ThisNode)
ReturnExchangePlans.MessageExchange.ThisNode();
защото:
Намерен е повече от един запис."Четох, че има проблем с платформата, пробвах я на различни версии на платформите
Опитах се да взема чиста конфигурация на най-новата версия и просто глупаво да я заредя с пълна подмяна
Като цяло не помогна, винаги беше едно и също. Кажете ми, някой сблъсквал ли се е с това?
Отговор:
Промених възела от true на false по-горе, мислех, че не работи, и тогава отидох да видя, че работи
Разпределената информационна база (DIB) често се използва за организиране на работата на клонове и поделения, което позволява бърз обмен на информация при запазване на необходимата степен на автономност. Въпреки факта, че тази технология е доста надеждна, тя се поврежда от време на време. Днес ще разгледаме една от доста често срещаните грешки: ще ви разкажем за причините за възникването й и методите за справяне с нея.
Да започнем, както винаги, отначало. След като създадете RIB, всички промени в конфигурацията на информационната база могат да бъдат направени само в главния възел. Впоследствие, по време на следващия обмен, всички промени ще бъдат прехвърлени към подчинените възли и автоматично ще бъдат приложени там. Но беше гладко на хартия...
На практика понякога се случва между сесиите на обмен, особено ако каналът в периферията е лош, конфигурацията на главния възел успява да се промени два пъти. Например, направиха промени, качиха ги, периферната база данни получи промените, но все още не ги е приложила, което може да отнеме известно време, и все още не е изпратила потвърждение. Ако направите промени отново през този период и качите обмена отново, се оказва, че центърът очаква да види конфигурация № 1 в периферния възел и ще се опита да го актуализира до конфигурация № 3, но всъщност ще срещне конфигурация № .2 там. Понякога подобна ситуация възниква при динамично актуализиране на централната база данни. В резултат на това обменът ще стане невъзможен и вие ще получите съобщение за това Конфигурацията на възела за разпределена информационна сигурност не отговаря на очакваната!
Като цяло моралът на тази история е прост - не прецизирайте активно работещата база данни и ако го направите, завършете всички сесии за обмен, преди да направите следващите промени. Но какво ще стане, ако подобна неприятност се случи?
Простото решение е да се създаде ново изображение на подчинения възел, но на практика това обикновено не е приложимо. По правило възникването на сериозна грешка по време на обмена не се открива веднага, а известно време след като оперативните данни от периферните бази данни престанат да пристигат. В зависимост от графика за комуникация между възникването на проблема и откриването му може да измине цял работен ден или дори повече.
Тук си струва да хвърлите камък по разработчиците, които съобщават за грешка и подчертават ситуацията в червено по същия начин Номерът на съобщението е по-малък или равен на номера на предишно получено съобщение, което като цяло е съвсем нормално. В резултат на това възприятието на потребителите за грешки се притъпява и те просто спират да четат показаните съобщения, вярвайки, че всичко е наред и че другата страна все още не е извършила обмена.
Но да се върнем на нашата грешка. Решението е съвсем просто и лежи на повърхността: приведете конфигурацията на периферната основа до очакваната, т.е. приведете го в съответствие с конфигурацията на централния възел. Но на практика това не е толкова лесно. Ако отворим периферната база данни в конфигуратора, ще видим, че промените са блокирани от инструментите за управление на RIB.
За да промените конфигурацията на подчинен възел, ще трябва временно да го изключите от централната база данни. За тези цели можете да използвате една от опциите за обработка, които са изобилно налични в мрежата, или да изключите информационната сигурност от централния възел с помощта на параметъра за стартиране на конфигуратора/ResetMasterNode.
Отворете командния ред и въведете (като вземете предвид версията на платформата и действителния път на инсталиране):
"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" конфигурация /ResetMasterNodeСлед като изпълните тази команда, ще се появи обичайният прозорец за стартиране, изберете желаната база там и щракнете върху бутона Конфигуратор.
Едновременно стартиране на информационната сигурност няма да стане, т.е. може да изглежда, че нищо не се е случило, но като отворите отново базата данни в конфигуратора, можете да се уверите, че тя е прекъсната от главния възел и е достъпна за извършване на промени.
внимание!На платформи 8.3.7 - 8.3.9 изпълнението на тази команда води до срив. Грешката беше коригирана в платформа 8.3.10.
Ако не искате да се забърквате с командния ред, тогава можете да използвате едно от леченията по-долу; това беше намерено в Интернет и ние направихме само козметични промени в него. Моля, имайте предвид, че обработката е подходяща само за обикновено приложение за конфигурации на управлявано приложение, използвайте клавиша за стартиране на конфигуратора.
Работата с него е изключително проста, стартираме го в режим 1C:Enterprise, чрез Файл - Отворете, след което просто натиснете желания бутон, в нашия случай Деактивирайте главния възел.
Сега имаме нужда от най-новата конфигурация от централния възел. За това ще отворим централна информационна сигурноств конфигуратора и изпълнете Конфигурация - Запазване на конфигурацията във файл. Полученият файл с разширение вжще трябва да се изпрати до периферен възел.
След това в периферния възел стартираме защитата на информацията (като преди това сме го изключили от главния възел) в конфигуратора и го премахваме от поддръжката. За да направите това, изберете: Конфигурация - Поддръжка - Настройка на поддръжката.
В прозореца, който се отваря, първо активирайте опциите за редактиране.
След това премахваме конфигурацията от поддръжката.
Сега можете да заредите конфигурацията от файл, за да направите това, изберете Конфигурация - Зареждане на конфигурация от файли показват, че не се предава от централния възел вж-файл. След което ще получите предупреждение, че текущата конфигурация не е празна. Моля, имайте предвид, че манипулациите, които извършваме, са потенциално опасни и могат да доведат до необратими щети върху информационната сигурност, така че преди да продължите, уверете се, че имате актуално резервно копие.
Тази грешка е типична за. Грешката „Конфигурацията на възела за разпределена информационна сигурност не съответства на очакваната“ е системна. Основно възниква поради необичайно изключване по време на обмен на данни чрез URIB.
Това може да се реши по доста прост начин. Нека го разгледаме.
Инструкции
1. Направете копия на базите данни, върху които ще се работи (В конфигуратора „Администриране - Качване на информационна база“).
2. Стартирайте конфигуратора на основната база данни на RIB възела.
3. Запазете конфигурацията на централния възел във файл с база данни („Конфигурация - Запазване на конфигурацията във файл...“)
4. Отворете конфигуратора на базата данни на подчинен възел.
Вземете безплатно 267 видео урока за 1C:
5. Премахнете конфигурацията на подчинения възел от поддръжка (Конфигурация - Поддръжка - Настройки за поддръжка - Премахване от поддръжка):
6. Заредете конфигурацията на базата данни („Конфигурация – Зареждане на конфигурация от файл...“).
8. След преструктурирането трябва да влезете в корпоративния режим и да инсталирате основния конфигурационен възел. Това може да стане чрез специална обработка - . Обработката работи както в режим на управлявано приложение, така и в режим на редовно приложение.
9. При обработката трябва да изберете основния възел и да щракнете върху „Изпълни“:
10. Готово! Опитайте да започнете обмена, системата трябва да завърши обмена правилно.
Грешките при динамично актуализиране (или други проблеми на платформата) могат да бъдат причина за грешки при обмен на разпределена информационна база:
„Данните се получават от възела, за който са регистрирани промени в конфигурацията“
„Конфигурацията на възела за разпределена информационна сигурност не отговаря на очакваното“
Как да възстановите обмена?
Но нека започнем не с възстановяването, а с възможността за изпълнениеобменяйте „ръчно“, което е важно през деня, защото както винаги всичко трябва да работи „вчера“ :) Това може да стане с помощта на чудесни лечения, които не запомнихгол откъдето го изтеглих (автори, моля, отговорете - ще оставя връзки към вашия ресурс и ако е необходимо, ще го изтрия от моя). Обработката дава възможност да се изтеглят само регистрирани промени в данните в базата данни (според посочения план за обмен за конкретен възел!) в XML, без да се изтеглят промени в конфигурацията и ако конфигурационните обекти не са се променили много, тогава има много голям шанс за зареждане на тези данни. Те могат да бъдат изтеглени от връзката в края на статията.
Що се отнася до възстановяването. Има по-прости методи, които не включват всички елементи от списъка по-долу, но те не винаги помагат, както беше в един от моите случаи. Затова представям метода, който ми помогна; той заобикаля възможните проблеми по по-изчерпателен начин. Следваща стъпка по стъпка.
Препоръчително е да предприемете тези стъпки, когато в базата данни няма работещи потребители. Ако това не е възможно, тогава ще трябва да „завършите“ метода за себе си и следователно първо трябва да разберете неговата логика.
1. Правете резервни копия навсякъде.
2. За клиент-сървъри: деактивирайте базите данни чрез „администриране на сървъра“ и незабавно ги свържете с блокиране на планирани задачи (това ще нулира кеша на сървъра). След това не забравяйте да прехвърлите регистъра за регистрация в новата директория.
3. На всички компютри, използвани за възстановяване, изтрийте базата данни в списъка на началните бази данни на 1C и създайте нова (потребителският кеш ще бъде изчистен)
4. В конфигуратора (в централната база данни) добавете нова константа и запазете промените в conf.
5. Изчистете всички директории за обмен.
6. Направете разтоварвания към всички клонове (засега само разтоварвания).
7. Опитайте се да изтеглите (само да изтеглите) получените данни във всички клонове. Естествено е да приемете conf промените.
Ако всичко е добре навсякъде, продължаваме напред; ако всичко е лошо, смятаме, че разтоварването на .cf от централната база данни и ЗАРЕЖДАНЕТО му в клона (без сравняване-сливане) може да помогне. В подчинения възел трябва да прекратите връзката на базата данни с RIB (обработката ще помогне за това - изтеглете от връзката по-долу). Има статия по тази тема на infostart.ru.
8. Отменяме регистрацията на промените за клонове в Централната банка (в края на краищата вече сме получили всички промени навсякъде). Важно е на този етап да се направи така, че натрупаните промени от различни клонове да стигнат до други клонове. (изтегляне на обработка за необвързване-обвързване от връзката по-долу).
9. Зареждаме в Централната банка и ако всичко е наред, зареждаме и разтоварваме с всеки клон няколко пъти, за да консолидираме резултата.
10. Това е всичко.
Можете да разрешите изпълнението на рутинни задачи за бази данни клиент-сървър.
За да предотвратите проблеми, които причиняват тази грешка, се препоръчва да не правите динамични актуализации (поне няколко пъти подред - докато промените не бъдат качени в клонове), а също така е препоръчително да поставите отметка в квадратчето „качване на данни само при успешно качване“ в настройките на обмена.
Първо, ето списък със съкращения, които използвам:
- RIB - разпределена информационна база
- CB - централна основа, коренен възел на RIB
- UB - отдалечена база, база данни на отдалечен RIB възел
От моя собствен опит мога да кажа, че съм срещал две причини за грешката:
- При получаване на файла със съобщения базата данни „падна“ в системата за управление и следователно очевидно е имало десинхронизация между conf. Централна банка и UB;
- под MSSQL клиента изтегли копие на работещата база и не изключи рег. задачи за автоматичен обмен, в резултат на това някои съобщения до отдалечени възли бяха генерирани от работещата база данни, а някои от копие, което доведе до десинхронизиране на конфигурациите
Има също мнение, че тази грешка е причинена от използването на динамичен механизъм за актуализиране на база данни. Тук има съмнения, защото от една страна, динамичното актуализиране никога не засяга структурата на базата данни и механизмите на RIB все още работят със структурата на базата данни, а не с нейната приложна част, въпреки това RIB използва механизъм за генериране на цифров подпис на конфигурационната версия (в бъдеще ще я наричам за по-кратко хеш) и когато частта на приложението се промени, хешът естествено трябва да бъде преизчислен. Нито ще отрека, нито ще го потвърдя, защото... Ако се сблъсках с тази ситуация, не намерих никакви ясни доказателства за това.
За да го коригирам, използвам 2 метода, в зависимост от ситуацията.
ПЪРВА ТЕХНИКА
Първият (най-често срещаният) се споменава многократно както в партньорската конференция, така и в други интернет ресурси, свързани с 1C. Използва се в повечето случаи, когато въпреки съобщението за несъответствия в конфигурациите, ръчно сравнение показва, че те са идентични.
Последователност:
- разтоварете cf файла от централната банка;
- премахваме връзката на UB от RIB (методът Set MainNode, готовата обработка може да бъде намерена в приложението или в други публикации);
- замяна на конф. UB към cf файла, качен в първата стъпка, за това използваме менюто „Зареждане на конфигурация от файл“ (а не сравнение-сливане!!!);
- Нека възстановим знака RIB за UX.
В повечето случаи тези действия са повече от достатъчни за възстановяване на обмена, но не винаги...
ВТОРИ МЕТОД
Използва се, ако първият метод не работи и не е възможно възелът да се разтовари отново.
Предистория: клиентът настройваше каскадна RIB и възникна грешка в първото ниво на каскадата (второто ниво работеше безупречно през цялото това време). Конфигурацията е разработена съвместно с ИТ службата на клиента и след възникването на грешката конфигурацията на централната банка е променяна няколко пъти. Възможността за връщане на промените не беше обмислена дори по принцип, т.к загубата на някои данни и затварянето на няколко отдела беше напълно неприемливо. Първият вариант за коригиране на грешката не доведе до осезаеми резултати. Затова трябваше да търсим други решения.
Идеята дойде да се опитаме да заменим хешовете на конфигурационните файлове директно в XML файловете за обмен. Описанието на структурата на файла за обмен от книгата „Професионално развитие в системата 1C:Enterprise 8“ даде слаба представа за формирането на цифрови подписи на конфигурации и промени в тях, но определи посоката на търсене: стойностите на Digest1 и Digest2. Разбрах всичко останало чисто емпирично (т.е. чрез проба и грешка), но беше възможно да установя модел.
Тестовите експерименти бяха успешни. В работните бази също всичко мина добре.
И така, последователността от действия:
- изпълнете стъпки 1 - 4 от първия метод;
- Разтоварваме обменния файл от UB, но не го зареждаме в Централната банка;
- Разтоварваме обменния файл от Централната банка, но не го зареждаме в UB;
- в обменния файл от Централната банка заменяме блока, съдържащ информация за промени в конфигурацията и хешове (Digest1 и Digest2) с блок от хешове от UB файла (вижте примера по-долу)
- Качваме файла от 4-та точка в УБ;
- Не забравяйте да презапишете обменния файл от UB (2-ра точка)! този файл не трябва да се тегли при обмен в Централната банка!
- За проверка правим няколко последователни обмена.
Ако по време на обмена се използва компресиране на данни, ние или деактивираме компресирането, или първо разопаковаме файла, променяме го, след това го пакетираме обратно и го изпращаме.
Блокиране на файлове за обмен от Централната банка
трябва да бъде заменен с блок на файла за обмен от UB (обърнете внимание, че Digest1 за файл от UB винаги е равно на "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"!!!)
Изброените действия трябва да се извършват изключително внимателно; неправилната последователност може да доведе до пълна неработоспособност на RIB. Затова преди тези действия създаването на резервни копия е ЗАДЪЛЖИТЕЛНО!
За останалото мога само да ти пожелая успех!
