Kesalahan ini tipikal untuk . Kesalahan "Konfigurasi node IS terdistribusi tidak sesuai dengan yang diharapkan" adalah kesalahan sistem. Ini terutama terjadi karena crash selama pertukaran data melalui URIB.
Ini dapat diselesaikan dengan cara yang cukup sederhana. Mari kita pertimbangkan.
Petunjuk
1. Buat salinan database yang akan dikerjakan (Di konfigurator "Administrasi - Bongkar infobase").
2. Jalankan konfigurator untuk database utama node RIB.
3. Simpan konfigurasi node pusat ke file database (“Konfigurasi - Simpan konfigurasi ke file…”)
4. Buka konfigurator basis simpul budak.
Dapatkan 267 pelajaran video 1C gratis:
5. Nonaktifkan node slave dari dukungan (Konfigurasi - Dukungan - Pengaturan Dukungan - De-dukungan):
6. Muat konfigurasi basis data ("Konfigurasi - Muat konfigurasi dari file...").
8. Setelah restrukturisasi, Anda harus masuk ke mode perusahaan dan menginstal node master konfigurasi. Ini dapat dilakukan dengan menggunakan pemrosesan khusus -. Pemrosesan bekerja dalam mode aplikasi terkelola dan mode aplikasi biasa.
9. Dalam pemrosesan, pilih simpul utama dan klik "Jalankan":
10. Selesai! Cobalah untuk memulai pertukaran, sistem harus melakukan pertukaran dengan benar.
Untuk mulai dengan, berikut adalah daftar singkatan yang saya gunakan:
- RIB - basis informasi terdistribusi
- CB - basis pusat, simpul akar RIB
- UB - basis jarak jauh, database RIB node jarak jauh
Dari pengalaman saya sendiri, saya dapat mengatakan bahwa saya menemukan dua alasan kesalahan tersebut:
- saat menerima file pesan di UB, basis "jatuh", sehubungan dengan itu, tampaknya, ada desinkronisasi antara conf. Bank Sentral dan UB;
- di bawah MSSQL, klien memuat salinan database yang berfungsi dan tidak mematikannya di salinan reg. tugas pertukaran otomatis, akibatnya, sebagian pesan ke node jarak jauh dibentuk dari database yang berfungsi, dan sebagian lagi dari salinan, yang menyebabkan desinkronisasi konfigurasi
Ada juga pendapat bahwa penggunaan mekanisme pembaruan basis data dinamis menyebabkan kesalahan ini. Ada keraguan di sini, karena di satu sisi, pembaruan dinamis tidak pernah memengaruhi struktur basis data, dan mekanisme RIB masih bekerja dengan struktur basis data, dan bukan dengan bagian aplikasinya, namun demikian, RIB menggunakan mekanisme untuk menghasilkan tanda tangan digital dari versi konfigurasi (singkatnya saya akan menyebutnya hash), dan ketika bagian aplikasi berubah, hash harus dihitung ulang secara alami. Saya tidak akan menyangkal ini, atau menegaskan, karena. jika dihadapkan pada situasi ini, maka saya tidak menemukan bukti yang jelas tentang hal ini.
Saya menggunakan 2 metode untuk memperbaikinya, tergantung situasinya.
METODE PERTAMA
Yang pertama (paling umum) berulang kali disebutkan baik di konferensi mitra maupun di sumber daya Internet lain yang terkait dengan 1C. Ini digunakan dalam banyak kasus, meskipun ada pesan tentang perbedaan konfigurasi, jika dibandingkan secara manual, tampaknya keduanya identik.
Pengurutan:
- membongkar file cf dari Bank Sentral;
- kami melepaskan UB dari RIB (metode SetMainNode, pemrosesan siap pakai dapat ditemukan di aplikasi atau di publikasi lain);
- ganti conf. UB pada file cf dibongkar pada langkah pertama, untuk ini kami menggunakan menu "Muat konfigurasi dari file" (dan bukan dengan gabungan-perbandingan !!!);
- mari kita kembalikan tanda RIB untuk UB.
Dalam kebanyakan kasus, tindakan ini lebih dari cukup untuk memulihkan pertukaran, tetapi tidak selalu...
METODE KEDUA
Ini digunakan jika metode pertama tidak berfungsi, dan tidak mungkin untuk membongkar node lagi.
Latar belakang: klien sedang menyiapkan RIB kaskade dan terjadi kesalahan pada tingkat kaskade pertama (tingkat kedua bekerja dengan sempurna selama ini). Konfigurasi dikembangkan bersama dengan layanan TI klien, dan sejak kesalahan terjadi, konfigurasi CB telah berubah beberapa kali. Opsi untuk mengembalikan perubahan bahkan tidak dipertimbangkan pada prinsipnya, karena hilangnya sebagian data dan penutupan beberapa departemen sama sekali tidak dapat diterima. Versi pertama dari koreksi kesalahan tidak memberikan hasil yang nyata. Akibatnya, solusi lain harus ditemukan.
Muncul ide untuk mencoba mengubah hash file konfigurasi secara langsung di file XML pertukaran. Deskripsi struktur file pertukaran dari buku " Pengembangan profesional dalam sistem 1C:Enterprise 8" memberikan gambaran yang buruk tentang formasi tanda tangan digital konfigurasi dan mengubahnya, tetapi menentukan arah pencarian: nilai Digest1 dan Digest2. Saya menemukan segala sesuatu yang lain murni secara empiris (yaitu, dengan coba-coba), tetapi saya berhasil membuat pola.
Eksperimen uji berjalan dengan baik. Di pangkalan juga, semuanya berjalan dengan baik.
Jadi, urutan tindakannya:
- lakukan langkah 1 - 4 dari teknik pertama;
- bongkar file pertukaran dari UB, tetapi jangan diunggah ke CB;
- membongkar file pertukaran dari Bank Sentral, tetapi tidak mengunggahnya ke UB;
- dalam file pertukaran dari CB, kami mengganti blok yang berisi informasi tentang perubahan konfigurasi dan hash (Digest1 dan Digest2) dengan blok hash dari file UB (lihat contoh di bawah)
- kami mengunggah file dari poin ke-4 ke UB;
- pastikan untuk menimpa file pertukaran dari UB (paragraf ke-2)! file ini tidak boleh dimuat saat bertukar di CB!
- untuk memeriksa, kami melakukan beberapa pertukaran berturut-turut.
Jika kompresi data digunakan selama pertukaran, matikan kompresi, atau buka paket file terlebih dahulu, ubah, lalu kemas kembali dan kirimkan.
Blokir pertukaran file dari CB
Perlu diganti dengan blok file pertukaran dari UB (perhatikan bahwa digest1 file dari UB selalu sama dengan "00000000000000000000000000000000"
Tindakan yang terdaftar harus dilakukan dengan sangat hati-hati, urutan yang salah penuh dengan ketidakmampuan RIB sepenuhnya. Oleh karena itu, sebelum tindakan ini, membuat salinan cadangan adalah WAJIB!
Kalau tidak, saya hanya bisa berharap Anda beruntung!
Kesalahan pembaruan dinamis (atau gangguan platform lainnya) dapat menjadi penyebab kesalahan pertukaran infobase terdistribusi:
"Data sedang diterima dari node yang perubahan konfigurasinya telah didaftarkan"
"Konfigurasi node IS terdistribusi tidak seperti yang diharapkan"
Bagaimana cara mengembalikan pertukaran?
Tapi mari kita mulai bukan dengan restorasi, tapi dengan kesempatan untuk dibelanjakanubah "secara manual", yang penting di siang hari, karena, seperti biasa, semuanya harus berfungsi "kemarin" :) Anda dapat melakukan ini dengan bantuan perawatan luar biasa yang saya tidak ingatNu tempat saya mengunduh (penulis, tanggapi - saya akan meninggalkan tautan ke sumber daya Anda, dan dari milik saya, jika perlu, saya akan menghapus). Pemrosesan memungkinkan untuk membongkar hanya perubahan data terdaftar dalam database (sesuai dengan rencana pertukaran yang ditentukan untuk node tertentu!) dalam XML tanpa membongkar perubahan konfigurasi, dan jika objek konfigurasi tidak banyak berubah, maka ada kemungkinan besar untuk memuat data ini. Ini dapat diunduh dari tautan di akhir artikel.
Adapun pemulihan. Ada cara yang lebih sederhana yang tidak menyertakan semua item dalam daftar di bawah ini, tetapi tidak selalu membantu, seperti yang terjadi di salah satu kasus saya. Oleh karena itu, saya memberikan metode yang membantu saya, melewati kemungkinan masalah secara lebih komprehensif. Selanjutnya pada langkah-langkah.
Dianjurkan untuk melakukan langkah-langkah ini ketika tidak ada pengguna yang bekerja di database. Jika ini tidak memungkinkan, maka Anda harus "menyelesaikan" metode itu sendiri, dan oleh karena itu Anda harus terlebih dahulu memahami logikanya.
1. Buat cadangan di mana saja.
2. Untuk klien-server: nonaktifkan database melalui "administrasi server" dan segera sambungkan dengan instalasi pemblokiran tugas terjadwal (sehingga cache server akan diatur ulang). Setelah itu, jangan lupa untuk mentransfer log registrasi ke direktori baru.
3. Di semua komputer yang digunakan untuk pemulihan, hapus database dalam daftar database pemula 1C dan buat yang baru (cache pengguna akan dihapus)
4. Di konfigurator (di database pusat) tambahkan konstanta baru untuk menyimpan perubahan ke conf.
5. Bersihkan semua direktori pertukaran.
6. Lakukan bongkar ke semua cabang (selama ini baru bongkar).
7. Coba upload (upload saja) data yang diterima ke semua cabang. Wajar untuk menerima perubahan conf.
Jika semuanya baik di mana-mana, kami melangkah lebih jauh, jika semuanya buruk, kami pikir mengunggah .cf dari database pusat dan MEMBUATnya ke cabang (bukan gabungan-perbandingan) dapat membantu. Di simpul budak, Anda harus melepaskan basis dari RIB (pemrosesan akan membantu dalam hal ini - unduh dari tautan di bawah). Ada artikel tentang topik ini di infostart.ru.
8. Kami membatalkan pendaftaran perubahan cabang di Bank Sentral (toh, kami sudah menerima semua perubahan di mana-mana). Penting untuk dilakukan pada tahap ini agar akumulasi perubahan dari berbagai cabang sampai ke cabang lain. (unduh proses unbinding-binding dari link di bawah).
9. Kami melakukan pemuatan ke Bank Sentral dan jika semuanya baik-baik saja, maka kami melakukan pemuatan dan pembongkaran dengan masing-masing cabang beberapa kali untuk mengkonsolidasikan hasilnya.
10. Semuanya.
Anda dapat mengaktifkan eksekusi tugas terjadwal untuk database server-klien.
Untuk mencegah masalah yang menyebabkan kesalahan ini, disarankan untuk tidak melakukan pembaruan dinamis (setidaknya beberapa kali berturut-turut - sebelum mengunggah perubahan ke cabang), dan disarankan juga untuk mencentang kotak "unggah data hanya setelah unggahan berhasil". dalam pengaturan pertukaran.
Untuk mulai dengan, berikut adalah daftar singkatan yang saya gunakan:
- RIB - basis informasi terdistribusi
- CB - basis pusat, simpul akar RIB
- UB - basis jarak jauh, database RIB node jarak jauh
Dari pengalaman saya sendiri, saya dapat mengatakan bahwa saya menemukan dua alasan kesalahan tersebut:
- saat menerima file pesan di UB, basis "jatuh", sehubungan dengan itu, tampaknya, ada desinkronisasi antara conf. Bank Sentral dan UB;
- di bawah MSSQL, klien memuat salinan database yang berfungsi dan tidak mematikannya di salinan reg. tugas pertukaran otomatis, akibatnya, sebagian pesan ke node jarak jauh dibentuk dari database yang berfungsi, dan sebagian lagi dari salinan, yang menyebabkan desinkronisasi konfigurasi
Ada juga pendapat bahwa penggunaan mekanisme pembaruan basis data dinamis menyebabkan kesalahan ini. Ada keraguan di sini, karena di satu sisi, pembaruan dinamis tidak pernah memengaruhi struktur basis data, dan mekanisme RIB masih bekerja dengan struktur basis data, dan bukan dengan bagian aplikasinya, namun demikian, RIB menggunakan mekanisme untuk menghasilkan tanda tangan digital dari versi konfigurasi (singkatnya saya akan menyebutnya hash), dan ketika bagian aplikasi berubah, hash harus dihitung ulang secara alami. Saya tidak akan menyangkal ini, atau menegaskan, karena. jika dihadapkan pada situasi ini, maka saya tidak menemukan bukti yang jelas tentang hal ini.
Saya menggunakan 2 metode untuk memperbaikinya, tergantung situasinya.
METODE PERTAMA
Yang pertama (paling umum) berulang kali disebutkan baik di konferensi mitra maupun di sumber daya Internet lain yang terkait dengan 1C. Ini digunakan dalam banyak kasus, meskipun ada pesan tentang perbedaan konfigurasi, jika dibandingkan secara manual, tampaknya keduanya identik.
Pengurutan:
- membongkar file cf dari Bank Sentral;
- kami melepaskan UB dari RIB (metode SetMainNode, pemrosesan siap pakai dapat ditemukan di aplikasi atau di publikasi lain);
- ganti conf. UB pada file cf dibongkar pada langkah pertama, untuk ini kami menggunakan menu "Muat konfigurasi dari file" (dan bukan dengan gabungan-perbandingan !!!);
- mari kita kembalikan tanda RIB untuk UB.
Dalam kebanyakan kasus, tindakan ini lebih dari cukup untuk memulihkan pertukaran, tetapi tidak selalu...
METODE KEDUA
Ini digunakan jika metode pertama tidak berfungsi, dan tidak mungkin untuk membongkar node lagi.
Latar belakang: klien sedang menyiapkan RIB kaskade dan terjadi kesalahan pada tingkat kaskade pertama (tingkat kedua bekerja dengan sempurna selama ini). Konfigurasi dikembangkan bersama dengan layanan TI klien, dan sejak kesalahan terjadi, konfigurasi CB telah berubah beberapa kali. Opsi untuk mengembalikan perubahan bahkan tidak dipertimbangkan pada prinsipnya, karena hilangnya sebagian data dan penutupan beberapa departemen sama sekali tidak dapat diterima. Versi pertama dari koreksi kesalahan tidak memberikan hasil yang nyata. Akibatnya, solusi lain harus ditemukan.
Muncul ide untuk mencoba mengubah hash file konfigurasi secara langsung di file XML pertukaran. Deskripsi struktur file pertukaran dari buku "Professional development in the 1C:Enterprise 8 system" memberikan gambaran yang buruk tentang pembentukan tanda tangan digital dari konfigurasi dan perubahan di dalamnya, tetapi menentukan arah pencarian: Digest1 dan Nilai intisari2. Saya menemukan segala sesuatu yang lain murni secara empiris (yaitu, dengan coba-coba), tetapi saya berhasil membuat pola.
Eksperimen uji berjalan dengan baik. Di pangkalan juga, semuanya berjalan dengan baik.
Jadi, urutan tindakannya:
- lakukan langkah 1 - 4 dari teknik pertama;
- bongkar file pertukaran dari UB, tetapi jangan diunggah ke CB;
- membongkar file pertukaran dari Bank Sentral, tetapi tidak mengunggahnya ke UB;
- dalam file pertukaran dari CB, kami mengganti blok yang berisi informasi tentang perubahan konfigurasi dan hash (Digest1 dan Digest2) dengan blok hash dari file UB (lihat contoh di bawah)
- kami mengunggah file dari poin ke-4 ke UB;
- pastikan untuk menimpa file pertukaran dari UB (paragraf ke-2)! file ini tidak boleh dimuat saat bertukar di CB!
- untuk memeriksa, kami melakukan beberapa pertukaran berturut-turut.
Jika kompresi data digunakan selama pertukaran, matikan kompresi, atau buka paket file terlebih dahulu, ubah, lalu kemas kembali dan kirimkan.
Blokir pertukaran file dari CB
...ini adalah blok yang menjelaskan perubahan konfigurasi...
harus diganti dengan block exchange file dari UB (catatan Digest1 file dari UB selalu "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000!!!"
Tindakan yang terdaftar harus dilakukan dengan sangat hati-hati, urutan yang salah penuh dengan ketidakmampuan RIB sepenuhnya. Oleh karena itu, sebelum tindakan ini, membuat salinan cadangan adalah WAJIB!
Kalau tidak, saya hanya bisa berharap Anda beruntung!
Pertanyaan: Kesalahan pembaruan node RIB
Selamat siang.
Memperbarui node Rarus-Retail utama ke 2.2.5.27, melakukan pertukaran dengan beberapa node RIB - semuanya baik-baik saja.
Saya memulai pembaruan massal dari node yang tersisa (mirip dengan "pasangan teratas" (toko lain di RIB)) - kesalahan muncul di sisi klien:
Distribusi Laporan Registrasi Data untuk Pemutakhiran Daftar Tugas Terjadwal"
penangan pembaruan yang ditangguhkan
"Distribusi Laporan. Perbarui Daftar Tugas Terjadwal"
Sebuah kesalahan telah terjadi:
"(GeneralModule.GeneralPurpose.Module(3502)): Kesalahan memanggil metode konteks (Berisi)
Kembalikan Metadata.InformationRegisters.Contains(MetadataObject);
karena:
Jenis ketidakcocokan (nomor parameter "1")".
Adakah yang bisa menemukan? Saya sudah mencoba memperbarui platform (hingga maksimum 8.3.10, dan memeriksanya di 32-64 komputer) ... tidak membantu. Tapi bagaimanapun juga, toko uji 2 diperbarui tanpa masalah, saya tidak mengerti caranya.
Menjawab:() Beginilah cara saya menginstal node utama. Saya menulis sedikit tentang hal lain: setelah Anda melepaskan simpul dengan memproses, kali berikutnya Anda memulai pembaruan conf tidak segera dimulai, tetapi 1C pertama membuka jendela di mana ia meminta Anda untuk mengonfirmasi bahwa simpul sedang dilepaskan. Setelah itu, diperbarui - setelah pembaruan, node tidak lagi ada dalam daftar.
Nyatanya, pada 2.1, saya ingat bahwa saya memperbaruinya menggunakan metode ini, tetapi ada sesuatu yang tidak berhasil pada 2.2. Mungkin, di taman, dia sudah memasukkan urutan tindakan yang salah)
DENGAN TOPIK:
Mengerti apa adanya. Ternyata dia mengabaikan:
"Di salah satu rilis 2.2, sebuah direktori muncul Mendistribusikan laporan dengan elemen yang telah ditentukan sebelumnya"Data pribadi" - direktori dengan elemen ini juga ada di 2.1.
Nuansanya begini: kusen dengan pembaruan node diamati pada basis yang dibuat dari pusat tepatnya pada rilis 2.1.9.18. Semua yang dibuat pada rilis sebelumnya diperbarui secara normal. Ini, mungkin, menjelaskan mengapa beberapa pangkalan untuk TS juga berhasil diperbarui, dan kemudian tiang temboknya hilang.
Saya tidak menemukan apa pun dengan membuat elemen baru di direktori dan mengaturnya seperti yang telah ditentukan sebelumnya. Mentransfer elemen ini dari salinan pusat ke 2.1 melalui pembongkaran/pemuatan XML dan mengulangi pembaruan pada "basis" yang bermasalah - semuanya berjalan dengan baik.
() Jadi gunakan cara tersebut jika Anda belum menemukan jawabannya.
Pertanyaan: Kesalahan pembaruan konfigurasi
Saya memperbarui konfigurasi Akuntansi 2.0.64.14 ke 2.0.64.24. platform 8.2.19
Terjadi kesalahan segera:
Kesalahan mengakses file... jalur... file sementara.tmp.
Di mana mencarinya?
Menjawab: memecahkan masalah itu dengan menunggu rilis "stabil" baru
Pertanyaan: Kesalahan dalam hak pengguna di BSP
Salam!!! Saya menulis conf berdasarkan BSP 2.2, sepertinya saya sudah memiliki pengalaman, dan telah mempelajari dok dari atas ke bawah, tetapi pertama kali saya memulai IB, terjadi kesalahan:(CommonModule.UsersService.Module(345)): Otorisasi gagal. Sistem akan dimatikan.
Pengguna: Administrator tidak ditemukan di direktori "Pengguna".Terjadi kesalahan saat mencoba menambahkan pengguna ke direktori:
"Pembaruan Infobase gagal.
Parameter pembatasan akses tidak diisi:
"Kemungkinan hak untuk mengatur hak objek".Untuk pengembang: Anda mungkin perlu memperbarui data pendukung,
yang mempengaruhi jalannya program. Untuk melakukan pembaruan, Anda dapat:
- mengambil keuntungan pemrosesan eksternal
"Alat Pengembang: Perbarui Data Dukungan",
- jalankan program dengan parameter garis komando 1C: Perusahaan 8
"/C Mulaimemperbarui Infobase",
- tingkatkan nomor versi konfigurasi sehingga di awal berikutnya
prosedur untuk memperbarui data infobase telah selesai."Klik untuk mengungkapkan...
Saya ingin mendengar jawaban dari yang "berpengalaman", untuk dialog aktif selanjutnya, bahkan mungkin kerja sama
Menjawab:
vdeg berkata:
Masalah terpecahkan?
Saya memiliki masalah dengan paket yang berbeda: Saya menambahkan pengguna ke BSP 2.2.5.29, dan dia memiliki hak penuh (jika Anda menambahkannya secara manual) atau tidak sama sekali (melihat antarmuka kosong tanpa direktori tunggal dan dokumen). Karena dalam peran BSP biasa tidak ada kotak centang sama sekali untuk mengakses direktori dan dokumen (saya) tertentu. Bagaimana kemudian akses tingkat rekaman untuk pengguna baru akan dilacak???
Klik untuk mengungkapkan...
Dan bagaimana seharusnya BSP mengetahui jenis direktori yang Anda miliki dan bagaimana Anda ingin mengonfigurasi akses ke sana?
Mungkin kita harus melakukannya sendiri.
Pertanyaan: SendingDeliverableNotified Host jarak jauh gagal verifikasi
Hingga Jumat lalu, kode berikut berfungsi dengan baik ..
XdtoSubscriber = Pabrik XDTO.Buat(Jenis Pabrik XDTO(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = Pabrik XDTO.Buat(Jenis Pabrik XDTO(";), "GCM");
NewXDTO Serializer = Serializer XDTO Baru (Pabrik XDTO);
Pelanggan = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Notification=New DeliverableNotification;
Notification.Recipients.Add(Subscriber);
Notification.Text=Teks;
Notification.SoundAlert=SoundAlert.Default;
Pemberitahuan.Stiker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notification,AuzData,True);
Sekarang kesalahannya adalah Remote Host Failed Validation. Pecah seluruh kepalaku. Saya menangkap panggilan server - rasanya kosong karena tidak berbelok ke mana pun ... Saya mencoba di tiga mesin berbeda dengan sumbu berbeda. lelah.. tolong..
Menjawab: Ke atas
Menjawab: Jadi, saya memutuskan untuk membuat gambar node lagi. Saat memulai node, dikatakan perlu dimulai dengan \c untuk mulai memperbarui infobase
dan gambar ulang.
Ternyata ini adalah sesuatu karena pembaruan yang bengkok.
Saya mencoba menjalankan dengan kunci ini dan melakukan pertukaran dengan node yang ada. Tidak ada pembaruan yang diluncurkan di node, tidak ada yang diminta untuk memulai ulang.
Dan akibatnya, di node utama, pesan itu kembali tidak diterima dengan kesalahan yang sama.
Apa yang bisa dilakukan?
Bisakah mengubah sesuatu yang fiktif di node utama di conf dan melakukan pertukaran? Atau apakah dia tidak akan memperbarui seluruh conf, tetapi hanya yang akan saya ubah? Saya akan mencoba membuat simpul untuk saat ini. Tapi saya akan menunggu ide Anda.
Pertanyaan: Basis data terdistribusi - kesalahan selama pertukaran tidak dihilangkan
Hari baik untuk semua!
Situasinya adalah sebagai berikut.
Saat memuat pertukaran dari node periferal, saya menerima pesan "Konfigurasi node IS terdistribusi tidak sesuai dengan yang diharapkan".
Lalu saya ikuti petunjuknya.
Saya membongkar konfigurasi dari database pusat ke CF, melepaskan database periferal dari node pusat dengan memproses, menghapus konfigurasi di database periferal dari dukungan, memuat konfigurasi dari file.
Saya mengikat simpul pusat di basis data periferal dengan memproses.
Simpan, terapkan.
Saya membongkar sekali lagi pertukaran dari database pusat.
Saya memuat di periferal. Saya membongkar pertukaran dari database periferal.
Mengunggah ke pusat. Sekali lagi saya mendapat pesan "Konfigurasi node IS terdistribusi tidak sesuai dengan yang diharapkan".
Tapi ini benar-benar tidak masuk akal - saya memuat konfigurasi ke database pusat dan tidak ada yang mengubah konfigurasi di database periferal.
Bagaimana cara mengatasi kesalahan seperti itu?
Menjawab: tidak pernah terpikir oleh siapa pun untuk menasihati hal-hal yang begitu jelas setelah bertahun-tahun bersumpah pada pembaruan setan :)
Pertanyaan: RIB dan pembaruan
Halo semua. Direncanakan untuk menggunakan keamanan informasi terdistribusi.
konfigurasi berubah. Memperbarui konfigurasi database pusat dilakukan oleh programmer. Kemudian, dengan pertukaran file, perubahan ini akan ditransfer ke basis data periferal.
Pertanyaannya adalah: bagaimana dengan peluncuran penangan setelah memperbarui konfigurasi basis data dan login pertama dalam mode pengguna?
memperbarui konfigurasi utama - memperbarui konfigurasi basis data - menjalankan penangan pembaruan dalam mode pengguna
Misalnya, banyak rilis yang terlewatkan, Anda perlu memutakhirkan secara berurutan untuk memutakhirkan ke 3 rilis. Tidak ada masalah dengan memperbarui database pusat, tetapi bagaimana dengan periferal? Anda juga perlu memperbaruinya dalam 3 tahap (memperbarui database pusat dengan rilis pertama, memperbarui RIB, memperbarui database pusat dengan rilis kedua, memperbarui RIB, dll.?)
Terima kasih atas bantuan Anda!
Menjawab:() menyodok hidung Anda, saya tidak dapat menemukan kode yang dijalankan saat mendaftarkan perubahan objek.
Tampaknya jika Anda menggunakan metode OnSendingData, node master masih akan mengakumulasi objek yang diubah untuk dikirim ke node slave. Dan ini adalah sumber daya komputer tambahan
Oleh karena itu, saya ingin objek di simpul utama tidak didaftarkan untuk dikirim segera pada saat perubahannya (On Write, misalnya). Di tempat apa, misalnya, dalam standar Akuntansi rev.3, benda-benda ini didaftarkan untuk dikirim?
Pertanyaan: [ASK] Kesalahan menghubungi dukungan online
Pakar yang terhormat, tolong beri tahu saya!
1C: Perusahaan 8.3 (8.3.11.2899)
Beberapa basis data dengan konfigurasi berbeda berputar di server 1C, semuanya mendukung Internet terhubung dan berfungsi dengan baik. Termasuk memuat nilai tukar, bank, memeriksa rekanan, SPARK, dll.
Pengaturan proxy sama untuk semua database.
Namun di database BP-3 CORP, selalu terjadi kesalahan:Di log pendaftaran:
Gagal mendapatkan tiket autentikasi di layanan.
Gagal memuat konten(). (GeneralModule.InternetUserSupportClientServer.Module(362)): Kesalahan memanggil metode konteks (SendToProcess)
Response = Connection.SendForProcessing(HTTPRequest, ReceiveParameters.ResponseFileName);
karena:
Kesalahan Internet: Autentikasi gagal host jarak jauhKlik untuk mengungkapkan...
Mencobanya versi yang berbeda platform (8.3.10..., 8.3.11...), dan pada versi konfigurasi yang berbeda (3.0.54.15, 3.0.57.10).
Menguji dan memperbaiki juga tidak membantu.
Apa yang bisa salah?
Apakah BP-CORP membuka Internet dengan cara khusus?
Terima kasih.
Menjawab:
Jawaban dari 1C (apa yang disorot dengan warna merah membantu saya):Selama transisi, BSP diperbarui sebagai bagian dari BP dari 2.4.3 ke 2.4.4
Dalam daftar perubahan di BSP 2.4.4
Peningkatan keamanan saat membuat sambungan aman ke layanan Internet HTTPS. Setelah deteksi berbagai masalah dengan sertifikat layanan Internet yang digunakan untuk mencoba koneksi aman (sertifikat tidak valid, kedaluwarsa, atau tidak tepercaya), koneksi tidak akan dibuat.
Di 8.3.10, verifikasi sertifikat di windows dilakukan menggunakan sistem operasi." -
Instal pembaruan terbaru untuk OS Anda, Mereka berisi pembaruan penting komponen sistem, yang bertanggung jawab untuk bekerja dengan sertifikat.
Silakan juga menginstal pembaruan terbaru sertifikat root yang didistribusikan oleh Microsoft dalam paket yang dapat diinstal.
Memerlukan versi setidaknya IE8.0. Ini berisi pembaruan penting untuk komponen sistem yang bertanggung jawab untuk bekerja dengan sertifikat.
Sebagai aturan, setelah menginstal semua pembaruan, masalahnya teratasi.
Periksa apakah jika Anda memasukkan di bilah pencarian di Internet Explorer, tautannya terbuka.
Pengguna yang atas nama Anda bekerja memiliki akses ke Internet.
Jika ini adalah database file di mesin klien, itu harus diperiksa.
Jika ini adalah database klien-server, maka di server di bawah pengguna tempat server 1C berjalan.
Periksa dengan browser IE saja.
Periksa apakah port 443 dan 80 terbuka
Jika Anda menggunakan Server Proksi, periksa apakah data di menu Pengaturan Pribadi sudah dikonfigurasi.
Jika versi client-server digunakan, maka Anda harus mengonfigurasi server sedemikian rupa sehingga koneksi Internet dengan browser IE berfungsi dengan benar di bawah pengguna yang menjalankan server 1C.
Saya mendaftarkan proxy di pengaturan IE pengguna tempat server 1C berjalan - semuanya berfungsi.
Pertanyaan: Perbarui boo 3
Selamat tinggal
Akuntansi 3
melakukan pembaruan dari 3.0.43.208 ke 3.0.43.235
kesalahan
Pertama
(GeneralModule.MessagingInternal.Module(381)): Kesalahan memanggil metode konteks (ThisNode)
karena:
Lebih dari satu entri ditemukan
Kedua
Saat memanggil penangan pembaruan:
"MessagingInternal.SetThisEndPointCode()"
Sebuah kesalahan telah terjadi:
"(GeneralModule.MessagingInternal.Module(381)): Kesalahan memanggil metode konteks (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
karena:
Lebih dari satu catatan ditemukan."Platform tulis yang tidak dapat ditulis telah dicoba pada berbagai versi platform
mencoba untuk mengambil conf bersih versi terbaru dan dengan bodohnya menyelesaikan penggantian untuk memuat
tidak membantu sama sekali, selalu hal yang sama. Katakan tiba-tiba siapa yang datang?
Menjawab:
simpul dari benar ke salah
Memuat...