Тази грешка е типична за. Грешката „Конфигурацията на възела за разпределена информационна сигурност не съответства на очакваната“ е системна. Основно възниква поради необичайно изключване по време на обмен на данни чрез URIB.
Това може да се реши по доста прост начин. Нека го разгледаме.
Инструкции
1. Направете копия на базите данни, върху които ще се работи (В конфигуратора „Администриране - Качване на информационна база“).
2. Стартирайте конфигуратора на основната база данни на RIB възела.
3. Запазете конфигурацията на централния възел във файл с база данни („Конфигурация - Запазване на конфигурацията във файл...“)
4. Отворете конфигуратора на базата данни на подчинен възел.
Вземете безплатно 267 видео урока за 1C:
5. Премахнете конфигурацията на подчинения възел от поддръжка (Конфигурация - Поддръжка - Настройки за поддръжка - Премахване от поддръжка):
6. Заредете конфигурацията на базата данни („Конфигурация – Зареждане на конфигурация от файл...“).
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 винаги е равен на "0000000000000000000000000000000000"!!!)
Изброените действия трябва да се извършват изключително внимателно; неправилната последователност може да доведе до пълна неработоспособност на RIB. Затова преди тези действия създаването на резервни копия е ЗАДЪЛЖИТЕЛНО!
За останалото мога само да ти пожелая успех!
Грешки при динамично актуализиране (или други проблеми на платформата) могат да бъдат причина за грешки при обмен на разпределена информационна база:
„Данните се получават от възела, за който са регистрирани промени в конфигурацията“
„Конфигурацията на възела за разпределена информационна сигурност не отговаря на очакваното“
Как да възстановите обмена?
Но нека започнем не с възстановяването, а с възможността за изпълнениеобменяйте „ръчно“, което е важно през деня, защото както винаги всичко трябва да работи „вчера“ :) Това може да стане с помощта на чудесни лечения, които не запомнихгол откъдето го изтеглих (автори, моля, отговорете - ще оставя връзки към вашия ресурс и ако е необходимо, ще го изтрия от моя). Обработката дава възможност да се изтеглят само регистрирани промени в данните в базата данни (според посочения план за обмен за конкретен възел!) в 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 винаги е равен на „00000000000000000000000000000000“ !!!)
Изброените действия трябва да се извършват изключително внимателно; неправилната последователност може да доведе до пълна неработоспособност на RIB. Затова преди тези действия създаването на резервни копия е ЗАДЪЛЖИТЕЛНО!
За останалото мога само да ти пожелая успех!
Въпрос: Грешка при актуализиране на 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:Предприятия 8
"/C LaunchInformationBaseUpdate",
- или увеличете номера на версията на конфигурацията, така че следващия път, когато стартирате
Приключиха процедурите по актуализиране на данните в информационната база."Кликнете, за да разширите...
Бих искал да чуя отговорите на „опитните“, за последващ активен диалог, може би дори сътрудничество
Отговор:
Vdeg каза:
Проблема решен?
Имам различен проблем: добавям потребител към BSP 2.2.5.29 и той или има пълни права (ако ги добавите ръчно), или никакви (вижда празен интерфейс без единична директорияи документ). Тъй като в типичните BSP роли изобщо няма квадратчета за достъп до конкретни (мои) директории и документи. Как тогава ще се проследи достъпът на ниво запис за нов потребител???
Кликнете, за да разширите...
Как BSP трябва да знае какви директории имате и как искате да конфигурирате достъпа до тях?
Вероятно трябва да го направим сами
Въпрос: SendingDeliverableNotified Проверката на отдалечения възел е неуспешна
До миналия петък следният код работеше добре..
XdtoSubscriber = FactoryXDTO.Create(FactoryXDTO.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = FactoryXDTO.Create(FactoryXDTO.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 по-горе, мислех, че не работи, и тогава отидох да видя, че работи
Зареждане...