Această eroare este tipică pentru . Eroarea „Configurația nodului IS distribuit nu corespunde așteptată” este o eroare de sistem. Apare în principal din cauza unui blocaj în timpul schimbului de date prin URIB.
Acest lucru poate fi rezolvat într-un mod destul de simplu. Să luăm în considerare.
Instruire
1. Faceți copii ale bazelor de date la care se va lucra (În configuratorul „Administrare - Descărcați baza de informații”).
2. Rulați configuratorul pentru baza de date principală a nodului RIB.
3. Salvați configurația nodului central într-un fișier de bază de date ("Configuration - Save configuration to file...")
4. Deschideți configuratorul de bază al nodului slave.
Obțineți 267 de lecții video 1C gratuit:
5. De-configurați nodul slave din asistență (Configurare - Asistență - Setări de asistență - Dezactivare):
6. Încărcați configurația bazei de date ("Configuration - Load configuration from file...").
8. După restructurare, trebuie să intrați în modul întreprindere și să instalați nodul principal de configurare. Acest lucru se poate face folosind o prelucrare specială -. Procesarea funcționează atât în modul aplicație gestionată, cât și în modul aplicație obișnuită.
9. În procesare, selectați nodul principal și faceți clic pe „Run”:
10. Gata! Încercați să începeți schimbul, sistemul ar trebui să efectueze schimbul corect.
Pentru început, iată o listă a abrevierilor pe care le folosesc:
- RIB - bază de informații distribuite
- CB - bază centrală, nod rădăcină RIB
- UB - bază la distanță, baza de date a nodului la distanță RIB
Din propria mea experiență, pot spune că am întâlnit două motive pentru eroare:
- la primirea dosarului cu mesaje în UB, baza „a căzut”, în legătură cu care, se pare, s-a produs o desincronizare între conf. Banca Centrală și UB;
- sub MSSQL, clientul a încărcat o copie a bazei de date de lucru și nu a dezactivat-o în copia reg. sarcini de schimb automat, ca urmare, o parte din mesajele către nodurile de la distanță a fost formată din baza de date de lucru și o parte din copie, ceea ce a dus la desincronizarea configurațiilor
Există, de asemenea, opinia că utilizarea mecanismului de actualizare dinamică a bazei de date duce la această eroare. Există îndoieli aici, deoarece, pe de o parte, actualizarea dinamică nu afectează niciodată structura bazei de date, iar mecanismele RIB încă funcționează cu structura bazei de date, și nu cu partea sa de aplicație, cu toate acestea, RIB utilizează mecanismul pentru generarea unei semnături digitale a versiunea de configurare (în o voi numi pe scurt un hash), iar atunci când partea aplicației se schimbă, hash-ul trebuie în mod natural recalculat. Nu voi nega acest lucru, nici nu voi afirma, pentru că. dacă mă confrunt cu această situație, atunci nu am găsit dovezi clare în acest sens.
Folosesc 2 metode pentru a o repara, în funcție de situație.
PRIMA METODĂ
Primul (cel mai des întâlnit) este menționat în mod repetat atât în conferința partenerului, cât și pe alte resurse de pe Internet legate de 1C. Este folosit în cele mai multe cazuri, când în ciuda mesajului despre discrepanțe ale configurațiilor, la comparație manuală, se pare că acestea sunt identice.
Secvențiere:
- descărcați fișierul cf de la Banca Centrală;
- dezlegam UB-ul de RIB (metoda SetMainNode, procesarea gata se gaseste in aplicatie sau in alte publicatii);
- înlocuiți conf. UB pe fisierul cf descarcat in primul pas, pentru asta folosim meniul "Incarcare configurare din fisier" (si nu prin comparatie-union !!!);
- să restabilim semnul RIB pentru UB.
În majoritatea cazurilor, aceste acțiuni sunt mai mult decât suficiente pentru a restabili schimbul, dar nu întotdeauna...
A DOUA METODĂ
Este folosit dacă prima metodă nu a funcționat și nu este posibilă descărcarea din nou a nodului.
Context: clientul configura un RIB în cascadă și a apărut o eroare la primul nivel al cascadei (al doilea nivel a funcționat impecabil în tot acest timp). Configurația a fost dezvoltată împreună cu serviciul IT al clientului, iar de când a apărut eroarea, configurația CB s-a schimbat de mai multe ori. Opțiunea de anulare a modificărilor nu a fost nici măcar luată în considerare în principiu, deoarece pierderea unei părți a datelor și închiderea mai multor departamente au fost complet inacceptabile. Prima versiune a corectării erorilor nu a dat niciun rezultat tangibil. Ca urmare, au trebuit găsite alte soluții.
Ideea a venit să încercăm să schimbi hash-urile fișierelor de configurare direct în fișierele XML de schimb. Descrierea structurii fișierului de schimb din carte " Dezvoltare profesionalăîn sistemul 1C:Enterprise 8" a dat o idee slabă despre formație semnături digitale configurații și modificări ale acestora, dar au determinat direcția de căutare: valorile Digest1 și Digest2. Mi-am dat seama de orice altceva pur empiric (adică prin încercare și eroare), dar am reușit să stabilesc un model.
Experimentele de testare au mers bine. Și pe baze, totul a mers bine.
Deci, succesiunea de acțiuni:
- efectuați pașii 1 - 4 ai primei tehnici;
- descărcați fișierul de schimb din UB, dar nu îl încărcați în CB;
- descărcați fișierul de schimb de la Banca Centrală, dar nu îl încărcați la UB;
- în fișierul de schimb din CB, înlocuim blocul care conține informații despre modificările de configurare și hash-uri (Digest1 și Digest2) cu un bloc de hash-uri din fișierul UB (vezi un exemplu de mai jos)
- incarcam fisierul de la punctul 4 in UB;
- asigurați-vă că suprascrieți fișierul de schimb din UB (alineatul 2)! acest fișier nu trebuie încărcat la schimbul în CB!
- pentru a verifica, facem mai multe schimburi consecutive.
Dacă este utilizată compresia datelor în timpul schimbului, atunci fie dezactivați compresia, fie mai întâi despachetați fișierul, schimbați-l, apoi împachetați-l înapoi și trimiteți-l.
Blocați schimbul de fișiere de la CB
trebuie înlocuit cu un bloc al fișierului de schimb din UB (rețineți că Digest1 al fișierului din UB este întotdeauna egal cu „00000000000000000000000000000000”!!
Acțiunile enumerate trebuie efectuate cu precauție extremă, o secvență incorectă este plină de inoperabilitatea completă a RIB. Prin urmare, înainte de aceste acțiuni, crearea copiilor de rezervă este OBLIGATORIE!
Altfel, nu pot decât să-ți urez succes!
Erorile de actualizare dinamică (sau alte erori ale platformei) pot fi cauzele erorilor de schimb de informații distribuite:
„Se primesc date de la nodul pentru care au fost înregistrate modificări de configurare”
„Configurația nodului IS distribuit nu este așa cum se aștepta”
Cum să restabiliți schimbul?
Dar să începem nu cu restaurarea, ci cu posibilitatea de a cheltuischimba "manual", ceea ce este important in timpul zilei, pentru ca, ca intotdeauna, totul ar trebui sa functioneze "ieri" :) Poti face asta cu ajutorul unor tratamente minunate pe care nu le mai amintescNu de unde am descarcat (autori, raspunde - voi lasa link-uri catre resursa ta, iar din a mea, daca este cazul, voi sterge). Procesarea face posibilă descărcarea doar a modificărilor de date înregistrate în baza de date (conform planului de schimb specificat pentru un anumit nod!) în XML fără a descărca modificări de configurare, iar dacă obiectele de configurare nu s-au schimbat prea mult, atunci există șanse foarte mari de încărcarea acestor date. Acestea pot fi descărcate din linkul de la sfârșitul articolului.
Cât despre recuperare. Există modalități mai simple care nu includ toate elementele din lista de mai jos, dar nu ajută întotdeauna, așa cum a fost cazul într-unul dintre cazurile mele. Prin urmare, dau metoda care m-a ajutat, ocolește mai cuprinzător posibilele probleme. Mai departe pe pași.
Este recomandabil să faceți acești pași atunci când nu există utilizatori care lucrează în baza de date. Dacă acest lucru nu este posibil, atunci va trebui să „terminați” metoda pentru dvs. și, prin urmare, trebuie să înțelegeți mai întâi logica acesteia.
1. Faceți copii de siguranță peste tot.
2. Pentru client-servere: dezactivați bazele de date prin „administrarea serverului” și conectați-vă imediat cu instalarea blocării sarcinilor programate (astfel cache-ul serverului va fi resetat). După aceea, nu uitați să transferați jurnalul de înregistrare în noul director.
3. Pe toate computerele utilizate pentru recuperare, ștergeți baza de date din lista bazelor de date de pornire 1C și creați una nouă (cache-ul utilizatorului va fi șters)
4. În configurator (în baza de date centrală) adăugați o nouă constantă pentru a salva modificările la conf.
5. Curățați toate directoarele de schimb.
6. Faceti descarcari la toate filialele (pana acum doar descarcari).
7. Încercați să încărcați (numai încărcați) datele primite în toate filialele. Este firesc să acceptăm modificările conf.
Dacă totul este bine peste tot, mergem mai departe, dacă totul este rău, credem că încărcarea .cf din baza de date centrală și ÎNCĂRCAREA lui în ramură (nu o uniune de comparație) poate ajuta. În nodul slave, ar trebui să dezlegați baza de la RIB (procesarea vă va ajuta în acest sens - descărcați de pe linkul de mai jos). Există un articol pe acest subiect pe infostart.ru.
8. Anulăm înregistrarea modificărilor pentru sucursalele din Banca Centrală (la urma urmei, am primit deja toate modificările peste tot). Este important să faceți în această etapă, astfel încât modificările acumulate de la diferite ramuri să ajungă la alte ramuri. (descărcați procesarea pentru dezlegare-legare din linkul de mai jos).
9. Facem încărcarea în Banca Centrală și dacă totul este bine, atunci facem încărcarea și descărcarea cu fiecare sucursală de câteva ori pentru a consolida rezultatul.
10. Totul.
Puteți activa executarea sarcinilor programate pentru bazele de date client-server.
Pentru a preveni problemele care provoacă această eroare, se recomandă să nu faceți o actualizare dinamică (de cel puțin mai multe ori la rând - înainte de a încărca modificările în ramuri), și este, de asemenea, recomandabil să bifați caseta de selectare „încărcare date numai la încărcare cu succes” în setările de schimb.
Pentru început, iată o listă a abrevierilor pe care le folosesc:
- RIB - bază de informații distribuite
- CB - bază centrală, nod rădăcină RIB
- UB - bază la distanță, baza de date a nodului la distanță RIB
Din propria mea experiență, pot spune că am întâlnit două motive pentru eroare:
- la primirea dosarului cu mesaje în UB, baza „a căzut”, în legătură cu care, se pare, s-a produs o desincronizare între conf. Banca Centrală și UB;
- sub MSSQL, clientul a încărcat o copie a bazei de date de lucru și nu a dezactivat-o în copia reg. sarcini de schimb automat, ca urmare, o parte din mesajele către nodurile de la distanță a fost formată din baza de date de lucru și o parte din copie, ceea ce a dus la desincronizarea configurațiilor
Există, de asemenea, opinia că utilizarea mecanismului de actualizare dinamică a bazei de date duce la această eroare. Există îndoieli aici, deoarece, pe de o parte, actualizarea dinamică nu afectează niciodată structura bazei de date, iar mecanismele RIB încă funcționează cu structura bazei de date, și nu cu partea sa de aplicație, cu toate acestea, RIB utilizează mecanismul pentru generarea unei semnături digitale a versiunea de configurare (în o voi numi pe scurt un hash), iar atunci când partea aplicației se schimbă, hash-ul trebuie în mod natural recalculat. Nu voi nega acest lucru, nici nu voi afirma, pentru că. dacă mă confrunt cu această situație, atunci nu am găsit dovezi clare în acest sens.
Folosesc 2 metode pentru a o repara, în funcție de situație.
PRIMA METODĂ
Primul (cel mai des întâlnit) este menționat în mod repetat atât în conferința partenerului, cât și pe alte resurse de pe Internet legate de 1C. Este folosit în cele mai multe cazuri, când în ciuda mesajului despre discrepanțe ale configurațiilor, la comparație manuală, se pare că acestea sunt identice.
Secvențiere:
- descărcați fișierul cf de la Banca Centrală;
- dezlegam UB-ul de RIB (metoda SetMainNode, procesarea gata se gaseste in aplicatie sau in alte publicatii);
- înlocuiți conf. UB pe fisierul cf descarcat in primul pas, pentru asta folosim meniul "Incarcare configurare din fisier" (si nu prin comparatie-union !!!);
- să restabilim semnul RIB pentru UB.
În majoritatea cazurilor, aceste acțiuni sunt mai mult decât suficiente pentru a restabili schimbul, dar nu întotdeauna...
A DOUA METODĂ
Este folosit dacă prima metodă nu a funcționat și nu este posibilă descărcarea din nou a nodului.
Context: clientul configura un RIB în cascadă și a apărut o eroare la primul nivel al cascadei (al doilea nivel a funcționat impecabil în tot acest timp). Configurația a fost dezvoltată împreună cu serviciul IT al clientului, iar de când a apărut eroarea, configurația CB s-a schimbat de mai multe ori. Opțiunea de anulare a modificărilor nu a fost nici măcar luată în considerare în principiu, deoarece pierderea unei părți a datelor și închiderea mai multor departamente au fost complet inacceptabile. Prima versiune a corectării erorilor nu a dat niciun rezultat tangibil. Ca urmare, au trebuit găsite alte soluții.
Ideea a venit să încercăm să schimbi hash-urile fișierelor de configurare direct în fișierele XML de schimb. Descrierea structurii fișierului de schimb din cartea „Dezvoltarea profesională în sistemul 1C:Enterprise 8” a dat o idee slabă despre formarea semnăturilor digitale ale configurațiilor și modificările acestora, dar a determinat direcția de căutare: Digest1 și Digest2 valori. Mi-am dat seama de orice altceva pur empiric (adică prin încercare și eroare), dar am reușit să stabilesc un model.
Experimentele de testare au mers bine. Și pe baze, totul a mers bine.
Deci, succesiunea de acțiuni:
- efectuați pașii 1 - 4 ai primei tehnici;
- descărcați fișierul de schimb din UB, dar nu îl încărcați în CB;
- descărcați fișierul de schimb de la Banca Centrală, dar nu îl încărcați la UB;
- în fișierul de schimb din CB, înlocuim blocul care conține informații despre modificările de configurare și hash-uri (Digest1 și Digest2) cu un bloc de hash-uri din fișierul UB (vezi un exemplu de mai jos)
- incarcam fisierul de la punctul 4 in UB;
- asigurați-vă că suprascrieți fișierul de schimb din UB (alineatul 2)! acest fișier nu trebuie încărcat la schimbul în CB!
- pentru a verifica, facem mai multe schimburi consecutive.
Dacă este utilizată compresia datelor în timpul schimbului, atunci fie dezactivați compresia, fie mai întâi despachetați fișierul, schimbați-l, apoi împachetați-l înapoi și trimiteți-l.
Blocați schimbul de fișiere de la CB
... aici sunt blocuri care descriu modificările de configurare...
trebuie înlocuit cu un bloc al fișierului de schimb din UB (notați Digest1 al fișierului din UB este întotdeauna „00000000000000000000000000000000”!!!)
Acțiunile enumerate trebuie efectuate cu precauție extremă, o secvență incorectă este plină de inoperabilitatea completă a RIB. Prin urmare, înainte de aceste acțiuni, crearea copiilor de rezervă este OBLIGATORIE!
Altfel, nu pot decât să-ți urez succes!
Întrebare: Eroare de actualizare a nodului RIB
Bună ziua.
Am actualizat nodul principal Rarus-Retail la 2.2.5.27, am făcut un schimb cu câteva noduri RIB - totul este în regulă.
Am început o actualizare în masă a nodurilor rămase (similar cu „cuplul de sus” (alte magazine în RIB)) - apare o eroare în partea clientului:
Distribuirea rapoartelor. Înregistrați datele pentru actualizarea listei de sarcini programate"
handler de actualizare amânată
„Distribuirea rapoartelor. Actualizați lista sarcinilor programate”
A avut loc o eroare:
„(GeneralModule.GeneralPurpose.Module(3502)): Eroare la apelarea metodei contextului (Conține)
Return Metadata.InformationRegisters.Contains(MetadataObject);
din cauza:
Nepotrivire de tip (numărul parametrului „1”)”.
Poate da cineva peste? Am încercat deja să actualizez platforma (până la maxim 8.3.10, și am verificat-o pe 32-64 de computere) ... nu a ajutat. Dar până la urmă, magazinele de testare 2 au fost actualizate fără probleme, nu pot înțelege cum.
Răspuns:() Așa instalez nodul principal. Am mai scris puțin despre altceva: după ce dezlegați nodul prin procesare, data viitoare când începeți actualizarea conf nu începe imediat, dar mai întâi 1C deschide o fereastră în care vă cere să confirmați că nodul este deconectat. După aceea, este actualizat - după actualizare, nodul nu mai este în listă.
De fapt, pe 2.1, îmi amintesc că l-am actualizat folosind această metodă, dar ceva nu a decolat pe 2.2. Poate că, în parc, a introdus deja secvența greșită în acțiuni)
DUPA SUBIECTUL:
A înțeles ce este. S-a dovedit că a trecut cu vederea:
„Într-una dintre versiunile 2.2 a apărut un director care distribuie rapoarte cu element predefinit„Date personale” - un director cu acest element era și pe 2.1.
Nuanța este aceasta: jamburile cu noduri de actualizare se observă pe acele baze care au fost create din cea centrală tocmai în versiunea 2.1.9.18. Tot ceea ce a fost creat în versiunile anterioare a fost actualizat în mod normal. Acest lucru, probabil, explică de ce câteva baze pentru TS au fost, de asemenea, actualizate cu succes, iar apoi s-au dus blocurile.
Nu am inventat nimic cu crearea unui nou element în director și setarea lui ca predefinit. Am transferat acest element din copia centrului în 2.1 prin descărcarea/încărcarea XML și am repetat actualizarea pe „baza” problematică - totul a mers bine.
() Așa că folosește metoda dacă nu ai găsit încă răspunsul.
Întrebare: Eroare de actualizare a configurației
Actualizez configurația Contabilității 2.0.64.14 la 2.0.64.24. platforma 8.2.19
Apare imediat o eroare:
Eroare la accesarea fișierului... calea... fișier temporar.tmp.
Unde să caut?
Răspuns: a rezolvat această problemă așteptând o nouă versiune „stabilă”.
Întrebare: Eroare în drepturile utilizatorului pe BSP
Salutari!!! Scriu o conf bazată pe BSP 2.2, se pare că am deja experiență și am studiat docurile în sus și în jos, dar prima dată când pornesc IB, apare o eroare:(CommonModule.UsersService.Module(345)): Autorizarea nu a reușit. Sistemul va fi oprit.
Utilizator: administratorul nu a fost găsit în directorul „Utilizatori”.A apărut o eroare la încercarea de a adăuga un utilizator în director:
„Actualizarea bazei de informații a eșuat.
Parametrul de restricție de acces nu este completat:
„Drepturi posibile pentru setarea drepturilor de obiect”.Pentru dezvoltator: poate fi necesar să actualizați datele de sprijin,
care afectează funcționarea programului. Pentru a efectua o actualizare, puteți:
- profită prelucrare externă
„Instrumente pentru dezvoltatori: actualizați datele de asistență”,
- fie rulați programul cu parametrul Linie de comanda 1C: Întreprinderea 8
„/C Pornirea bazei de informații”,
- fie măriți numărul versiunii configurației astfel încât la următoarea pornire
au fost finalizate procedurile de actualizare a bazei de date”.Faceți clic pentru a dezvălui...
Aș dori să aud răspunsurile celor „cu experiență”, pentru un dialog activ ulterior, poate chiar cooperare
Răspuns:
vdeg a spus:
Problema rezolvata?
Am o problemă cu un alt plan: adaug un utilizator la BSP 2.2.5.29 și el fie are drepturi depline (dacă le adaugi manual), fie deloc (vede o interfață goală fără director unicși document). Deoarece în rolurile tipice BSP nu există casete de selectare pentru a accesa directoare și documente specifice (mei). Cum va fi urmărit accesul la nivel de înregistrare pentru noul utilizator???
Faceți clic pentru a dezvălui...
Și cum ar trebui BSP să afle ce fel de directoare aveți și cum doriți să configurați accesul la ele?
Probabil că ar trebui să o facem noi.
Întrebare: SendingDeliverableNotified Gazda la distanță nu a reușit verificarea
Până vinerea trecută, următorul cod a funcționat bine..
XdtoSubscriber = XDTO Factory.Create(XDTO Factory.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
NewXDTO Serializer = New XDTO Serializer(XDTO Factory);
Abonat = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Notificare=Notificare livrabilă nouă;
Notificare.Destinatari.Adăugați(Abonat);
Notification.Text=Text;
Notification.SoundAlert=SoundAlert.Default;
Notice.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notificare,AuzData,True);
Acum eroarea este Remote Host Failed Validation. Mi-a rupt tot capul. Am prins apeluri pe server - se simte gol că nu se întoarce nicăieri... Am încercat pe trei mașini diferite cu axe diferite. epuizat... ajutor...
Răspuns: Sus
Răspuns: Deci, am decis să fac din nou imaginea nodului. La pornirea nodului, se spune că trebuie pornit cu \c pentru a începe actualizarea bazei de informații
și re-imagine.
Se pare că acest lucru este ceva din cauza unei actualizări strâmbe.
Am încercat să rulez cu această cheie și să fac un schimb cu un nod existent. Nu au fost lansate actualizări în nod, nu s-a cerut repornirea nimicului.
Și, ca urmare, în nodul principal, mesajul nu a fost din nou acceptat cu aceeași eroare.
Ce se poate face?
Poate schimba ceva fictiv în nodul principal din conf și poate face un schimb? Sau nu va actualiza toata conf, ci doar ce voi schimba? Voi încerca să fac un nod deocamdată. Dar voi aștepta ideile tale.
Întrebare: Baza de date distribuită - eroarea din timpul schimbului nu este eliminată
Ziua bună tuturor!
Situația este următoarea.
La încărcarea unui schimb de la un nod periferic, primesc mesajul „Configurația nodului IS distribuit nu se potrivește cu cea așteptată”.
Apoi urmez instrucțiunile.
Descarc configurația din baza de date centrală în CF, dezleg baza de date periferică de la nodul central prin procesare, scot configurația din baza de date periferică din suport, încarc configurația dintr-un fișier.
Leagă nodul central în baza de date periferică prin procesare.
Salvează, aplică.
Descarc inca o data schimbul din baza de date centrala.
incarc in periferic. Descarc schimbul din baza de date periferică.
Încărcare în centrală. Din nou primesc mesajul „Configurația nodului IS distribuit nu se potrivește cu cea așteptată”.
Dar asta este o adevărată prostie - încarc configurația în baza de date centrală și nimeni nu a schimbat configurația în baza de date periferică.
Cum să depășești o astfel de eroare?
Răspuns: nu i-a trecut nimănui prin minte să sfătuiască lucruri atât de evidente după mulți ani de înjurări la actualizarea demonică :)
Întrebare: RIB și actualizări
Salutare tuturor. Este planificată utilizarea securității informațiilor distribuite.
configurația schimbată. Actualizarea configurației bazei de date centrale este efectuată de programator. Apoi, odată cu fișierele de schimb, aceste modificări vor fi transferate în bazele de date periferice.
Întrebarea este: cum rămâne cu lansarea handlerelor după actualizarea configurației bazei de date și prima autentificare în modul utilizator?
actualizarea configurației principale - actualizarea configurației bazei de date - executarea handlerelor de actualizare în modul utilizator
De exemplu, multe versiuni au fost ratate, trebuie să faceți upgrade secvenţial pentru a face upgrade la 3 versiuni. Nu sunt probleme cu actualizarea bazei de date centrale, dar ce zici de cele periferice? De asemenea, este necesară actualizarea acestora în 3 etape (actualizarea bazei de date centrală cu prima ediție, actualizarea RIB-ului, actualizarea bazei de date centrală cu a doua ediție, actualizarea RIB-ului etc.?)
Vă mulțumesc tuturor pentru ajutor!
Răspuns:() bagă-ți nasul, nu găsesc codul care se execută la înregistrarea modificărilor obiectelor.
Se pare că dacă utilizați metoda OnSendingData, atunci nodul master va acumula în continuare obiecte modificate pentru a le trimite către nodul slave. Și acestea sunt resurse computerizate suplimentare
Prin urmare, vreau ca obiectele din nodul principal să nu fie înregistrate pentru trimitere imediată în momentul modificării lor (On Write, de exemplu). În ce loc, de exemplu, în Contabilitatea standard rev. 3, sunt înregistrate aceste obiecte pentru trimitere?
Întrebare: [SOLUȚIONATĂ] Eroare la contactarea asistenței online
Dragi experți, spuneți-mi, vă rog!
1C: Enterprise 8.3 (8.3.11.2899)
Mai multe baze de date cu configurații diferite se rotesc pe serverul 1C, în toate acestea suportul de internet este conectat și funcționează bine. Incl. incarcare cursuri de schimb, banci, verificare contrapartide, SPARK etc.
Setările proxy sunt aceleași pentru toate bazele de date.
Dar în bazele de date BP-3 CORP, apare întotdeauna o eroare:În jurnalul de înregistrare:
Nu s-a putut obține un bilet de autentificare în serviciu.
Nu s-a încărcat conținutul (). (GeneralModule.InternetUserSupportClientServer.Module(362)): Eroare la apelarea metodei contextului (SendToProcess)
Răspuns = Connection.SendForProcessing(HTTPRequest, ReceiveParameters.ResponseFileName);
din cauza:
Eroare de internet: autentificarea gazdă la distanță a eșuatFaceți clic pentru a dezvălui...
A încercat versiuni diferite platforme (8.3.10..., 8.3.11...), și pe diferite versiuni de configurare (3.0.54.15, 3.0.57.10).
Nici testarea și repararea nu ajută.
Ce poate fi greșit?
BP-CORP merge cumva la Internet într-un mod special?
Mulțumesc.
Răspuns:
Răspunsul de la 1C (ceea ce este evidențiat cu roșu m-a ajutat):În timpul tranziției, BSP a fost actualizat ca parte a BP de la 2.4.3 la 2.4.4
În lista modificărilor din BSP 2.4.4
Securitate îmbunătățită la stabilirea unei conexiuni securizate la serviciile de Internet HTTPS. La depistare diverse probleme cu certificatul serviciului de Internet cu care se încearcă o conexiune securizată (certificat invalid, depășit sau de încredere), conexiunea nu va fi stabilită.
În 8.3.10, verificarea certificatului în Windows se realizează folosind sistem de operare." -
Instalați cele mai recente actualizări pentru sistemul dvs. de operare. Acestea conțin actualizări importante componentele sistemului, care sunt responsabili pentru lucrul cu certificate.
Vă rugăm să instalați ultima actualizare certificate rădăcină distribuite de Microsoft în pachete instalabile.
Necesită o versiune de cel puțin IE8.0. Conține actualizări importante ale componentelor sistemului care sunt responsabile pentru lucrul cu certificate.
De regulă, după instalarea tuturor actualizărilor, problema este rezolvată.
Verificați dacă introduceți în bara de căutare în Internet Explorer, linkul se deschide.
Utilizatorul în numele căruia lucrați are acces la Internet.
Dacă aceasta este o bază de date de fișiere pe computerul clientului, ar trebui verificată pe ea.
Dacă aceasta este o bază de date client-server, atunci pe serverul sub utilizatorul pe care rulează serverul 1C.
Verificați numai cu browserul IE.
Verificați dacă porturile 443 și 80 sunt deschise
Dacă utilizați un server proxy, verificați dacă datele din meniul Setări personale sunt configurate.
Dacă se folosește versiunea client-server, atunci ar trebui să configurați serverul în așa fel încât conexiunea la Internet cu browserul IE să funcționeze corect pe acesta sub utilizatorul în numele căruia rulează serverul 1C.
Am înregistrat proxy-ul în setările IE ale utilizatorului sub care rulează serverul 1C - totul a funcționat.
Întrebare: Actualizați boo 3
O zi buna
Contabilitatea 3
a făcut o actualizare de la 3.0.43.208 la 3.0.43.235
greșeli
primul
(GeneralModule.MessagingInternal.Module(381)): Eroare la apelarea metodei contextului (ThisNode)
din cauza:
S-au găsit mai multe intrări
al doilea
Când apelați handlerul de actualizare:
„MessagingInternal.SetThisEndPointCode()”
A avut loc o eroare:
„(GeneralModule.MessagingInternal.Module(381)): Eroare la apelarea metodei contextului (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
din cauza:
S-au găsit mai mult de o înregistrare.”Platformă estimată de scris nu poate fi încercată pe diferite versiuni de platforme
a încercat să ia o conf curată ultima versiuneși doar prostește înlocuirea completă pentru a încărca
nu a ajutat deloc, mereu același lucru. Spune-mi brusc cine a dat peste?
Răspuns:
nodul de la adevărat la fals
Se încarcă...