การกำหนดค่า ib ไม่เป็นไปตามที่คาดไว้ ทำการสำรองข้อมูลทุกที่

ข้อผิดพลาดนี้เป็นเรื่องปกติสำหรับ ข้อผิดพลาด "การกำหนดค่าโหนด IS แบบกระจายไม่ตรงกับที่คาดไว้" เป็นข้อผิดพลาดของระบบ ส่วนใหญ่เกิดขึ้นเนื่องจากข้อขัดข้องระหว่างการแลกเปลี่ยนข้อมูลผ่าน URIB

สิ่งนี้สามารถแก้ไขได้ด้วยวิธีที่ค่อนข้างง่าย ลองพิจารณาดูครับ

คำแนะนำ

1. ทำสำเนาของฐานข้อมูลที่จะใช้งาน (ในตัวกำหนดค่า "การดูแลระบบ - ยกเลิกการโหลดฐานข้อมูล")

2. เรียกใช้ตัวกำหนดค่าสำหรับฐานข้อมูลหลักของโหนด RIB

3. บันทึกการกำหนดค่าโหนดกลางลงในไฟล์ฐานข้อมูล (“การกำหนดค่า - บันทึกการกำหนดค่าลงในไฟล์…”)

4. เปิดตัวกำหนดค่าฐานโหนดสเลฟ

รับบทเรียนวิดีโอ 267 1C ฟรี:

5. ยกเลิกการกำหนดค่าโหนดทาสจากการสนับสนุน (การกำหนดค่า - การสนับสนุน - การตั้งค่าการสนับสนุน - การยกเลิกการสนับสนุน):

6. โหลดการกำหนดค่าฐานข้อมูล ("การกำหนดค่า - โหลดการกำหนดค่าจากไฟล์...")

8. หลังจากปรับโครงสร้างใหม่ คุณต้องเข้าสู่โหมดองค์กรและติดตั้งโหนดหลักการกำหนดค่า สามารถทำได้โดยใช้การประมวลผลพิเศษ - การประมวลผลทำงานได้ทั้งในโหมดแอปที่มีการจัดการและโหมดแอปปกติ

9. ในการประมวลผล เลือกโหนดหลักแล้วคลิก "เรียกใช้":

10. เสร็จแล้ว! ลองเริ่มการแลกเปลี่ยน ระบบควรทำการแลกเปลี่ยนอย่างถูกต้อง

เริ่มต้นด้วย นี่คือรายการของตัวย่อที่ฉันใช้:

• RIB - ฐานข้อมูลแบบกระจาย
• CB - ฐานกลาง, รูตโหนด RIB
• UB - ฐานระยะไกล, ฐานข้อมูลของโหนดระยะไกล RIB

จากประสบการณ์ของตัวเอง ฉันสามารถพูดได้ว่าฉันพบสาเหตุของข้อผิดพลาดสองประการ:

1. ในขณะที่รับไฟล์ข้อความใน UB ฐาน "ลดลง" ซึ่งเกี่ยวข้องกับการซิงโครไนซ์ระหว่าง conf ธนาคารกลางและ UB;
2. ภายใต้ MSSQL ไคลเอนต์โหลดสำเนาของฐานข้อมูลที่ใช้งานได้และไม่ได้ปิดในสำเนาของ reg งานแลกเปลี่ยนอัตโนมัติ เป็นผลให้ส่วนหนึ่งของข้อความไปยังโหนดระยะไกลถูกสร้างขึ้นจากฐานข้อมูลที่ใช้งานได้และส่วนหนึ่งจากการคัดลอกซึ่งนำไปสู่การยกเลิกการซิงโครไนซ์ของการกำหนดค่า

นอกจากนี้ยังมีความเห็นว่าการใช้กลไกการอัพเดทฐานข้อมูลแบบไดนามิกทำให้เกิดข้อผิดพลาดนี้ มีข้อสงสัยเนื่องจากในแง่หนึ่ง การอัปเดตแบบไดนามิกไม่เคยส่งผลกระทบต่อโครงสร้างฐานข้อมูล และกลไก RIB ยังคงทำงานกับโครงสร้างฐานข้อมูล ไม่ใช่กับส่วนแอปพลิเคชัน อย่างไรก็ตาม RIB ใช้กลไกสำหรับสร้างลายเซ็นดิจิทัลของ เวอร์ชันการกำหนดค่า (ในฉันจะเรียกสั้นๆ ว่าแฮช) และเมื่อส่วนของแอปพลิเคชันเปลี่ยนแปลง แฮชจะต้องถูกคำนวณใหม่โดยธรรมชาติ ฉันจะไม่ปฏิเสธหรือยืนยันเพราะ หากประสบกับสถานการณ์เช่นนี้แล้วข้าพเจ้าไม่พบหลักฐานชัดเจนในเรื่องนี้

ฉันใช้ 2 วิธีในการแก้ไขขึ้นอยู่กับสถานการณ์

วิธีแรก

ครั้งแรก (ที่พบมากที่สุด) ถูกกล่าวถึงซ้ำ ๆ ทั้งในการประชุมพันธมิตรและแหล่งข้อมูลทางอินเทอร์เน็ตอื่น ๆ ที่เกี่ยวข้องกับ 1C ใช้ในกรณีส่วนใหญ่ แม้ว่าจะมีข้อความเกี่ยวกับความแตกต่างของการกำหนดค่า เมื่อเปรียบเทียบด้วยตนเอง ปรากฏว่าเหมือนกัน

ลำดับ:

1. ยกเลิกการโหลดไฟล์ cf จากธนาคารกลาง
2. เราปลด UB ออกจาก RIB (วิธี SetMainNode การประมวลผลสำเร็จรูปสามารถพบได้ในแอปพลิเคชันหรือในสิ่งพิมพ์อื่น ๆ )
3. เปลี่ยนคอนเฟิม UB ที่ยกเลิกการโหลดไฟล์ cf ในขั้นตอนแรก สำหรับสิ่งนี้ เราใช้เมนู "โหลดการกำหนดค่าจากไฟล์" (และไม่ใช่โดยการเปรียบเทียบยูเนียน !!!);
4. มาคืนสัญลักษณ์ของ RIB สำหรับ UB กันเถอะ

ในกรณีส่วนใหญ่ การกระทำเหล่านี้มากเกินพอที่จะกู้คืนการแลกเปลี่ยน แต่ก็ไม่เสมอไป...

วิธีที่สอง

ใช้ในกรณีที่วิธีแรกไม่ได้ผล และไม่สามารถยกเลิกการโหลดโหนดได้อีก

ความเป็นมา: ลูกค้ากำลังตั้งค่า RIB แบบเรียงซ้อน และเกิดข้อผิดพลาดในระดับแรกของการเรียงซ้อน (ระดับที่สองทำงานได้อย่างไร้ที่ติตลอดมา) การกำหนดค่าได้รับการพัฒนาร่วมกับบริการ IT ของลูกค้า และเนื่องจากข้อผิดพลาดเกิดขึ้น การกำหนดค่า CB จึงมีการเปลี่ยนแปลงหลายครั้ง ตัวเลือกในการย้อนกลับการเปลี่ยนแปลงไม่ได้รับการพิจารณาในหลักการด้วยซ้ำเพราะ การสูญเสียข้อมูลบางส่วนและการปิดแผนกต่างๆ เป็นสิ่งที่ยอมรับไม่ได้โดยสิ้นเชิง การแก้ไขข้อผิดพลาดเวอร์ชันแรกไม่ได้ให้ผลลัพธ์ที่จับต้องได้ จึงต้องหาทางออกอื่น

แนวคิดนี้เกิดขึ้นเพื่อพยายามเปลี่ยนแฮชของไฟล์การกำหนดค่าโดยตรงในไฟล์ XML แลกเปลี่ยน คำอธิบายโครงสร้างของ exchange file จากหนังสือ " การพัฒนาวิชาชีพในระบบ 1C:Enterprise 8" ให้แนวคิดที่ไม่ดีเกี่ยวกับการก่อตั้ง ลายเซ็นดิจิทัลการกำหนดค่าและการเปลี่ยนแปลง แต่กำหนดทิศทางการค้นหา: ค่า Digest1 และ Digest2 ฉันค้นพบทุกสิ่งทุกอย่างจากประสบการณ์ล้วนๆ (นั่นคือโดยการลองผิดลองถูก) แต่ฉันสามารถสร้างรูปแบบได้

การทดลองทดสอบผ่านไปด้วยดี บนฐานทุกอย่างก็เป็นไปด้วยดีเช่นกัน

ดังนั้นลำดับของการกระทำ:

1. ทำตามขั้นตอนที่ 1 - 4 ของเทคนิคแรก
2. ยกเลิกการโหลดไฟล์แลกเปลี่ยนจาก UB แต่อย่าอัปโหลดไปยัง CB
3. ยกเลิกการโหลดไฟล์แลกเปลี่ยนจากธนาคารกลาง แต่อย่าอัปโหลดไปยัง UB
4. ในไฟล์แลกเปลี่ยนจาก CB เราแทนที่บล็อกที่มีข้อมูลเกี่ยวกับการเปลี่ยนแปลงการกำหนดค่าและแฮช (Digest1 และ Digest2) ด้วยบล็อกแฮชจากไฟล์ UB (ดูตัวอย่างด้านล่าง)
5. เราอัปโหลดไฟล์จากจุดที่ 4 ไปยัง UB
6. อย่าลืมเขียนทับไฟล์แลกเปลี่ยนจาก UB (ย่อหน้าที่ 2)! ห้ามโหลดไฟล์นี้เมื่อทำการแลกเปลี่ยนใน CB!
7. เพื่อตรวจสอบ เราทำการแลกเปลี่ยนติดต่อกันหลายครั้ง

หากใช้การบีบอัดข้อมูลระหว่างการแลกเปลี่ยน ให้ปิดการบีบอัด หรือคลายการบีบอัดไฟล์ก่อน เปลี่ยนแปลง จากนั้นจึงแพ็คกลับและส่ง

บล็อกการแลกเปลี่ยนไฟล์จาก CB

106.0...นี่คือบล็อกที่อธิบายถึงการเปลี่ยนแปลงการกำหนดค่า... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

ต้องแทนที่ด้วยบล็อกของไฟล์แลกเปลี่ยนจาก UB (โปรดทราบว่า Digest1 ของไฟล์จาก UB จะเท่ากับ "00000000000000000000000000000000" เสมอ!!! !)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

การดำเนินการที่ระบุไว้จะต้องดำเนินการด้วยความระมัดระวังอย่างยิ่ง ลำดับที่ไม่ถูกต้องจะเต็มไปด้วยความไม่สามารถใช้งานที่สมบูรณ์ของ RIB ดังนั้น ก่อนดำเนินการเหล่านี้ การสร้างสำเนาสำรองจึงเป็นสิ่งจำเป็น!

มิฉะนั้นฉันขอให้คุณโชคดีเท่านั้น!

ข้อผิดพลาดในการอัปเดตแบบไดนามิก (หรือข้อบกพร่องของแพลตฟอร์มอื่นๆ) อาจเป็นสาเหตุของข้อผิดพลาดการแลกเปลี่ยนฐานข้อมูลแบบกระจาย:

• "กำลังรับข้อมูลจากโหนดที่มีการลงทะเบียนการเปลี่ยนแปลงการกำหนดค่า"
  

• "การกำหนดค่าโหนด IS แบบกระจายไม่เป็นไปตามที่คาดไว้"
  

จะคืนค่าการแลกเปลี่ยนได้อย่างไร?

แต่ขอไม่เริ่มต้นด้วยการฟื้นฟู แต่ด้วยโอกาสที่จะใช้จ่ายเปลี่ยน "ด้วยตนเอง" ซึ่งเป็นสิ่งสำคัญในระหว่างวัน เพราะเช่นเคย ทุกอย่างควรใช้งานได้ "เมื่อวาน" :) คุณสามารถทำสิ่งนี้ได้ด้วยความช่วยเหลือของการรักษาที่ยอดเยี่ยมซึ่งฉันจำไม่ได้Nu ที่ฉันดาวน์โหลด (ผู้เขียนตอบ - ฉันจะทิ้งลิงก์ไปยังทรัพยากรของคุณและจากฉันถ้าจำเป็นฉันจะลบ). การประมวลผลทำให้สามารถยกเลิกการโหลดเฉพาะการเปลี่ยนแปลงข้อมูลที่ลงทะเบียนในฐานข้อมูล (ตามแผนการแลกเปลี่ยนที่ระบุสำหรับโหนดเฉพาะ!) ใน XML โดยไม่ต้องยกเลิกการโหลดการเปลี่ยนแปลงการกำหนดค่า และหากวัตถุการกำหนดค่าไม่ได้เปลี่ยนแปลงมากนัก ก็มีโอกาสสูงมากที่ กำลังโหลดข้อมูลนี้ สามารถดาวน์โหลดได้จากลิงค์ท้ายบทความ

สำหรับการกู้คืน มีวิธีง่ายๆ ที่ไม่รวมรายการทั้งหมดในรายการด้านล่าง แต่ก็ไม่ได้ช่วยเสมอไป เช่นเดียวกับในกรณีหนึ่งของฉัน ดังนั้นฉันจึงให้วิธีการที่ช่วยให้ฉันหลีกเลี่ยงปัญหาที่เป็นไปได้อย่างครอบคลุมมากขึ้น ในขั้นตอนต่อไป

ขอแนะนำให้ทำตามขั้นตอนเหล่านี้เมื่อไม่มีผู้ใช้ที่ใช้งานอยู่ในฐานข้อมูล หากเป็นไปไม่ได้ คุณจะต้อง "เสร็จสิ้น" วิธีการด้วยตัวคุณเอง ดังนั้น คุณต้องเข้าใจตรรกะของมันก่อน

1. ทำการสำรองข้อมูลทุกที่

2. สำหรับเซิร์ฟเวอร์ไคลเอนต์: ปิดใช้งานฐานข้อมูลผ่าน "การดูแลระบบเซิร์ฟเวอร์" และเชื่อมต่อกับการติดตั้งการบล็อกงานตามกำหนดเวลาทันที (ดังนั้นแคชเซิร์ฟเวอร์จะถูกรีเซ็ต) หลังจากนั้นอย่าลืมโอนบันทึกการลงทะเบียนไปยังไดเร็กทอรีใหม่

3. ในคอมพิวเตอร์ทุกเครื่องที่ใช้สำหรับการกู้คืน ให้ลบฐานข้อมูลในรายการฐานข้อมูลเริ่มต้น 1C และสร้างใหม่ (แคชของผู้ใช้จะถูกล้าง)

4. ในคอนฟิกูเรเตอร์ (ในฐานข้อมูลกลาง) ให้เพิ่มค่าคงที่ใหม่เพื่อบันทึกการเปลี่ยนแปลงคอนฟิก

5. ล้างไดเร็กทอรีการแลกเปลี่ยนทั้งหมด

6. ทำการขนถ่ายไปยังสาขาทั้งหมด (จนถึงตอนนี้ขนถ่ายเท่านั้น)

7. พยายามอัพโหลด (เฉพาะอัพโหลด) ข้อมูลที่ได้รับไปยังทุกสาขา เป็นเรื่องธรรมดาที่จะยอมรับการเปลี่ยนแปลงของคอนเฟิร์ม

หากทุกอย่างดีในทุกที่ เราจะไปต่อ หากทุกอย่างไม่ดี เราคิดว่าการอัปโหลด .cf จากฐานข้อมูลกลางและการโหลดไปยังสาขา (ไม่ใช่การเปรียบเทียบสหภาพ) อาจช่วยได้ ในโหนดสเลฟ คุณควรปลดฐานออกจาก RIB (การประมวลผลจะช่วยได้ - ดาวน์โหลดจากลิงค์ด้านล่าง) มีบทความในหัวข้อนี้ที่ infostart.ru

8. เรายกเลิกการลงทะเบียนการเปลี่ยนแปลงสำหรับสาขาในธนาคารกลาง (หลังจากนั้นเราได้รับการเปลี่ยนแปลงทั้งหมดแล้วทุกที่) สิ่งสำคัญคือต้องดำเนินการในขั้นตอนนี้เพื่อให้การเปลี่ยนแปลงที่สะสมจากสาขาต่างๆ ไปถึงสาขาอื่น (ดาวน์โหลดขั้นตอนการปลด-ผูกมัดได้จากลิงค์ด้านล่าง)

9. เราทำการโหลดไปยังธนาคารกลางและหากทุกอย่างเรียบร้อยดี เราจะทำการโหลดและยกเลิกการโหลดกับแต่ละสาขาหลายครั้งเพื่อรวมผลลัพธ์

10. ทุกอย่าง

คุณสามารถเปิดใช้งานการดำเนินการตามกำหนดเวลาสำหรับฐานข้อมูลไคลเอนต์เซิร์ฟเวอร์

เพื่อป้องกันปัญหาที่ทำให้เกิดข้อผิดพลาดนี้ ขอแนะนำว่าอย่าทำการอัปเดตแบบไดนามิก (อย่างน้อยหลายครั้งติดต่อกัน - ก่อนที่จะอัปโหลดการเปลี่ยนแปลงไปยังสาขา) และขอแนะนำให้ทำเครื่องหมายที่ช่องทำเครื่องหมาย "อัปโหลดข้อมูลเมื่ออัปโหลดสำเร็จเท่านั้น" ในการตั้งค่าการแลกเปลี่ยน

เริ่มต้นด้วย นี่คือรายการของตัวย่อที่ฉันใช้:

• RIB - ฐานข้อมูลแบบกระจาย
• CB - ฐานกลาง, รูตโหนด RIB
• UB - ฐานระยะไกล, ฐานข้อมูลของโหนดระยะไกล RIB

จากประสบการณ์ของตัวเอง ฉันสามารถพูดได้ว่าฉันพบสาเหตุของข้อผิดพลาดสองประการ:

1. ในขณะที่รับไฟล์ข้อความใน UB ฐาน "ลดลง" ซึ่งเกี่ยวข้องกับการซิงโครไนซ์ระหว่าง conf ธนาคารกลางและ UB;
2. ภายใต้ MSSQL ไคลเอนต์โหลดสำเนาของฐานข้อมูลที่ใช้งานได้และไม่ได้ปิดในสำเนาของ reg งานแลกเปลี่ยนอัตโนมัติ เป็นผลให้ส่วนหนึ่งของข้อความไปยังโหนดระยะไกลถูกสร้างขึ้นจากฐานข้อมูลที่ใช้งานได้และส่วนหนึ่งจากการคัดลอกซึ่งนำไปสู่การยกเลิกการซิงโครไนซ์ของการกำหนดค่า

นอกจากนี้ยังมีความเห็นว่าการใช้กลไกการอัพเดทฐานข้อมูลแบบไดนามิกทำให้เกิดข้อผิดพลาดนี้ มีข้อสงสัยเนื่องจากในแง่หนึ่ง การอัปเดตแบบไดนามิกไม่เคยส่งผลกระทบต่อโครงสร้างฐานข้อมูล และกลไก RIB ยังคงทำงานกับโครงสร้างฐานข้อมูล ไม่ใช่กับส่วนแอปพลิเคชัน อย่างไรก็ตาม RIB ใช้กลไกสำหรับสร้างลายเซ็นดิจิทัลของ เวอร์ชันการกำหนดค่า (ในฉันจะเรียกสั้นๆ ว่าแฮช) และเมื่อส่วนของแอปพลิเคชันเปลี่ยนแปลง แฮชจะต้องถูกคำนวณใหม่โดยธรรมชาติ ฉันจะไม่ปฏิเสธหรือยืนยันเพราะ หากประสบกับสถานการณ์เช่นนี้แล้วข้าพเจ้าไม่พบหลักฐานชัดเจนในเรื่องนี้

ฉันใช้ 2 วิธีในการแก้ไขขึ้นอยู่กับสถานการณ์

วิธีแรก

ครั้งแรก (ที่พบมากที่สุด) ถูกกล่าวถึงซ้ำ ๆ ทั้งในการประชุมพันธมิตรและแหล่งข้อมูลทางอินเทอร์เน็ตอื่น ๆ ที่เกี่ยวข้องกับ 1C ใช้ในกรณีส่วนใหญ่ แม้ว่าจะมีข้อความเกี่ยวกับความแตกต่างของการกำหนดค่า เมื่อเปรียบเทียบด้วยตนเอง ปรากฏว่าเหมือนกัน

ลำดับ:

1. ยกเลิกการโหลดไฟล์ cf จากธนาคารกลาง
2. เราปลด UB ออกจาก RIB (วิธี SetMainNode การประมวลผลสำเร็จรูปสามารถพบได้ในแอปพลิเคชันหรือในสิ่งพิมพ์อื่น ๆ )
3. เปลี่ยนคอนเฟิม UB ที่ยกเลิกการโหลดไฟล์ cf ในขั้นตอนแรก สำหรับสิ่งนี้ เราใช้เมนู "โหลดการกำหนดค่าจากไฟล์" (และไม่ใช่โดยการเปรียบเทียบยูเนียน !!!);
4. มาคืนสัญลักษณ์ของ RIB สำหรับ UB กันเถอะ

ในกรณีส่วนใหญ่ การกระทำเหล่านี้มากเกินพอที่จะกู้คืนการแลกเปลี่ยน แต่ก็ไม่เสมอไป...

วิธีที่สอง

ใช้ในกรณีที่วิธีแรกไม่ได้ผล และไม่สามารถยกเลิกการโหลดโหนดได้อีก

ความเป็นมา: ลูกค้ากำลังตั้งค่า RIB แบบเรียงซ้อน และเกิดข้อผิดพลาดในระดับแรกของการเรียงซ้อน (ระดับที่สองทำงานได้อย่างไร้ที่ติตลอดมา) การกำหนดค่าได้รับการพัฒนาร่วมกับบริการ IT ของลูกค้า และเนื่องจากข้อผิดพลาดเกิดขึ้น การกำหนดค่า CB จึงมีการเปลี่ยนแปลงหลายครั้ง ตัวเลือกในการย้อนกลับการเปลี่ยนแปลงไม่ได้รับการพิจารณาในหลักการด้วยซ้ำเพราะ การสูญเสียข้อมูลบางส่วนและการปิดแผนกต่างๆ เป็นสิ่งที่ยอมรับไม่ได้โดยสิ้นเชิง การแก้ไขข้อผิดพลาดเวอร์ชันแรกไม่ได้ให้ผลลัพธ์ที่จับต้องได้ จึงต้องหาทางออกอื่น

แนวคิดนี้เกิดขึ้นเพื่อพยายามเปลี่ยนแฮชของไฟล์การกำหนดค่าโดยตรงในไฟล์ XML แลกเปลี่ยน คำอธิบายโครงสร้างของไฟล์แลกเปลี่ยนจากหนังสือ "การพัฒนามืออาชีพในระบบ 1C: Enterprise 8" ให้แนวคิดที่ไม่ดีเกี่ยวกับการก่อตัวของลายเซ็นดิจิทัลของการกำหนดค่าและการเปลี่ยนแปลงในนั้น แต่กำหนดทิศทางการค้นหา: Digest1 และ Digest2 ค่า ฉันค้นพบทุกสิ่งทุกอย่างจากประสบการณ์ล้วนๆ (นั่นคือโดยการลองผิดลองถูก) แต่ฉันสามารถสร้างรูปแบบได้

การทดลองทดสอบผ่านไปด้วยดี บนฐานทุกอย่างก็เป็นไปด้วยดีเช่นกัน

ดังนั้นลำดับของการกระทำ:

1. ทำตามขั้นตอนที่ 1 - 4 ของเทคนิคแรก
2. ยกเลิกการโหลดไฟล์แลกเปลี่ยนจาก UB แต่อย่าอัปโหลดไปยัง CB
3. ยกเลิกการโหลดไฟล์แลกเปลี่ยนจากธนาคารกลาง แต่อย่าอัปโหลดไปยัง UB
4. ในไฟล์แลกเปลี่ยนจาก CB เราแทนที่บล็อกที่มีข้อมูลเกี่ยวกับการเปลี่ยนแปลงการกำหนดค่าและแฮช (Digest1 และ Digest2) ด้วยบล็อกแฮชจากไฟล์ UB (ดูตัวอย่างด้านล่าง)
5. เราอัปโหลดไฟล์จากจุดที่ 4 ไปยัง UB
6. อย่าลืมเขียนทับไฟล์แลกเปลี่ยนจาก UB (ย่อหน้าที่ 2)! ห้ามโหลดไฟล์นี้เมื่อทำการแลกเปลี่ยนใน CB!
7. เพื่อตรวจสอบ เราทำการแลกเปลี่ยนติดต่อกันหลายครั้ง

หากใช้การบีบอัดข้อมูลระหว่างการแลกเปลี่ยน ให้ปิดการบีบอัด หรือคลายการบีบอัดไฟล์ก่อน เปลี่ยนแปลง จากนั้นจึงแพ็คกลับและส่ง

บล็อกการแลกเปลี่ยนไฟล์จาก CB

106.0
...นี่คือบล็อกที่อธิบายถึงการเปลี่ยนแปลงการกำหนดค่า...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

ต้องแทนที่ด้วยบล็อกของไฟล์แลกเปลี่ยนจาก UB (หมายเหตุ Digest1 ของไฟล์จาก UB จะเป็น "00000000000000000000000000000000" เสมอ!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

การดำเนินการที่ระบุไว้จะต้องดำเนินการด้วยความระมัดระวังอย่างยิ่ง ลำดับที่ไม่ถูกต้องจะเต็มไปด้วยความไม่สามารถใช้งานที่สมบูรณ์ของ RIB ดังนั้น ก่อนดำเนินการเหล่านี้ การสร้างสำเนาสำรองจึงเป็นสิ่งจำเป็น!

มิฉะนั้นฉันขอให้คุณโชคดีเท่านั้น!

คำถาม: ข้อผิดพลาดในการอัปเดตโหนด RIB

สวัสดีตอนบ่าย.

อัปเดตโหนด Rarus-Retail หลักเป็น 2.2.5.27 ทำการแลกเปลี่ยนกับโหนด RIB สองสามโหนด - ทุกอย่างเรียบร้อยดี

ฉันเริ่มการอัปเดตจำนวนมากของโหนดที่เหลือ (คล้ายกับ "คู่ยอดนิยม" (ร้านค้าอื่น ๆ ใน RIB)) - ข้อผิดพลาดปรากฏขึ้นในฝั่งไคลเอ็นต์:

การกระจายรายงาน ลงทะเบียนข้อมูลสำหรับการอัปเดตรายการงานที่กำหนดเวลาไว้"
ตัวจัดการการอัปเดตที่เลื่อนออกไป
"การกระจายรายงาน อัปเดตรายการงานที่กำหนดเวลาไว้"
เกิดข้อผิดพลาด:
"(GeneralModule.GeneralPurpose.Module(3502)): เกิดข้อผิดพลาดในการเรียกเมธอดบริบท (ประกอบด้วย)
กลับ Metadata.InformationRegisters.Contains(MetadataObject);
เพราะว่า:
พิมพ์ไม่ตรงกัน (หมายเลขพารามิเตอร์ "1")"

มีใครเจอมั้ยคะ? ฉันได้ลองอัปเดตแพลตฟอร์มแล้ว (สูงสุด 8.3.10 สูงสุดและตรวจสอบบนคอมพิวเตอร์ 32-64 เครื่อง) ... มันไม่ได้ช่วยอะไร แต่หลังจากนั้น ร้านค้าทดสอบ 2 แห่งก็อัปเดตโดยไม่มีปัญหา ฉันไม่เข้าใจวิธีการ

คำตอบ:() นี่คือวิธีที่ฉันติดตั้งโหนดหลัก ฉันเขียนเกี่ยวกับสิ่งอื่นเล็กน้อย: หลังจากที่คุณคลายโหนดโดยการประมวลผล ครั้งต่อไปที่คุณเริ่มการอัปเดต conf จะไม่เริ่มทันที แต่ก่อนอื่น 1C จะเปิดหน้าต่างซึ่งขอให้คุณยืนยันว่าโหนดไม่ได้ถูกผูกไว้ หลังจากนั้นจะมีการอัปเดต - หลังจากอัปเดตโหนดจะไม่อยู่ในรายการอีกต่อไป
อันที่จริง ในเวอร์ชัน 2.1 ฉันจำได้ว่าฉันอัปเดตโดยใช้วิธีนี้ แต่มีบางอย่างไม่เกิดขึ้นบนเวอร์ชัน 2.2 บางทีในสวนสาธารณะเขาแหย่ลำดับการกระทำที่ไม่ถูกต้องแล้ว)

ตามเรื่อง:
เข้าใจว่าคืออะไร ปรากฎว่าเขามองข้าม:
"ในหนึ่งในรีลีส 2.2 ไดเร็กทอรีปรากฏขึ้น การกระจายรายงานด้วย องค์ประกอบที่กำหนดไว้ล่วงหน้า"ข้อมูลส่วนบุคคล" - ไดเร็กทอรีที่มีองค์ประกอบนี้อยู่ใน 2.1 ด้วย

ข้อแตกต่างคือสิ่งนี้: jambs ที่มีโหนดการอัปเดตจะถูกสังเกตบนฐานที่สร้างขึ้นจากส่วนกลางในรีลีส 2.1.9.18 อย่างแม่นยำ ทุกอย่างที่สร้างขึ้นในรีลีสก่อนหน้านี้ได้รับการอัปเดตตามปกติ นี่อาจอธิบายได้ว่าทำไมฐานสองฐานสำหรับ TS จึงได้รับการอัปเดตสำเร็จด้วย และจากนั้นวงกบก็หายไป

ฉันไม่ได้ประดิษฐ์อะไรเลยด้วยการสร้างองค์ประกอบใหม่ในไดเร็กทอรีและตั้งค่าเป็นที่กำหนดไว้ล่วงหน้า ถ่ายโอนองค์ประกอบนี้จากสำเนาของศูนย์เป็น 2.1 ผ่านการขนถ่าย / โหลด XML และอัปเดต "ฐาน" ที่มีปัญหาซ้ำ - ทุกอย่างเป็นไปด้วยดี

() ดังนั้นใช้วิธีนี้หากคุณยังไม่พบคำตอบ

คำถาม: ข้อผิดพลาดในการอัปเดตการกำหนดค่า

ฉันกำลังอัปเดตการกำหนดค่าของบัญชี 2.0.64.14 เป็น 2.0.64.24 แพลตฟอร์ม 8.2.19
เกิดข้อผิดพลาดทันที:
เกิดข้อผิดพลาดในการเข้าถึงไฟล์... เส้นทาง... file.tmp ชั่วคราว
จะดูที่ไหน?

คำตอบ:แก้ไขปัญหานั้นโดยรอการเปิดตัว "เสถียร" ใหม่

คำถาม: ข้อผิดพลาดในสิทธิ์ของผู้ใช้บน BSP

ทักทาย!!! ฉันกำลังเขียน Conf ตาม BSP 2.2 ดูเหมือนว่าฉันมีประสบการณ์แล้ว และได้ศึกษาท่าเทียบเรือขึ้นและลง แต่ครั้งแรกที่ฉันเริ่ม IB เกิดข้อผิดพลาดขึ้น:

(CommonModule.UsersService.Module(345)): การอนุญาตล้มเหลว ระบบจะปิดตัวลง
ผู้ใช้: ไม่พบผู้ดูแลระบบในไดเรกทอรี "ผู้ใช้"

เกิดข้อผิดพลาดขณะพยายามเพิ่มผู้ใช้ในไดเร็กทอรี:
"การอัปเดตฐานข้อมูลล้มเหลว
ไม่ได้เติมพารามิเตอร์การจำกัดการเข้าถึง:
"สิทธิ์ที่เป็นไปได้สำหรับการตั้งค่าสิทธิ์ของวัตถุ"

สำหรับนักพัฒนา: คุณอาจต้องอัปเดตข้อมูลสนับสนุน
ที่ส่งผลต่อการทำงานของโปรแกรม ในการดำเนินการอัปเดต คุณสามารถ:
- เอาเปรียบ การประมวลผลภายนอก
"เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์: อัปเดตข้อมูลสนับสนุน"
- เรียกใช้โปรแกรมด้วยพารามิเตอร์ บรรทัดคำสั่ง 1C:องค์กร 8
"/C การเริ่มต้นการอัปเดตฐานข้อมูล",
- เพิ่มจำนวนเวอร์ชันของการกำหนดค่าเพื่อให้เริ่มต้นครั้งถัดไป
ขั้นตอนการอัปเดตข้อมูลฐานข้อมูลเสร็จสมบูรณ์แล้ว"

คลิกเพื่อเปิด...

ฉันต้องการฟังคำตอบของ "ผู้มีประสบการณ์" สำหรับการสนทนาที่กระตือรือร้นในภายหลัง หรือแม้กระทั่งความร่วมมือ

คำตอบ:

vdeg บอกว่า :

แก้ไขปัญหา?

ฉันมีปัญหากับแผนอื่น: ฉันเพิ่มผู้ใช้ใน BSP 2.2.5.29 และเขามีสิทธิ์ทั้งหมด (ถ้าคุณเพิ่มด้วยตนเอง) หรือไม่มีเลย (เห็นอินเทอร์เฟซที่ว่างเปล่าโดยไม่มี ไดเรกทอรีเดียวและเอกสาร). เนื่องจากในบทบาท BSP ทั่วไปจะไม่มีช่องทำเครื่องหมายเลยสำหรับการเข้าถึงไดเร็กทอรีและเอกสารเฉพาะ (ของฉัน) การเข้าถึงระดับบันทึกสำหรับผู้ใช้ใหม่จะถูกติดตามอย่างไร???

คลิกเพื่อเปิด...

และ BSP จะทราบได้อย่างไรว่าคุณมีไดเร็กทอรีประเภทใดและต้องการกำหนดค่าการเข้าถึงไดเร็กทอรีเหล่านั้นอย่างไร
บางทีเราควรทำเอง

คำถาม: SendingDeliverableNotified รีโมตโฮสต์ล้มเหลวในการตรวจสอบ

จนถึงวันศุกร์ที่แล้วรหัสต่อไปนี้ใช้งานได้ดี ..

XdtoSubscriber = XDTO Factory.Create(XDTO Factory.Type(";));
xdtoSubscriber.DeviceID = รหัสอุปกรณ์;
xdtoSubscriber.SubscriberType = XDTO Factory.Create(XDTO Factory.Type(";), "GCM");
NewXDTO Serializer = ใหม่ XDTO Serializer (โรงงาน XDTO);
สมาชิก = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
การแจ้งเตือน = การแจ้งเตือนการส่งมอบใหม่;
Notification.Recipients.Add(สมาชิก);
Notification.Text=ข้อความ;
Notification.SoundAlert=SoundAlert.Default;
ประกาศ สติ๊กเกอร์ = 1;
DATAAuz=โทเค็น;
SendingDeliverableNotifications.Send(การแจ้งเตือน,AuzData,True);

ตอนนี้ข้อผิดพลาดคือการตรวจสอบโฮสต์ระยะไกลล้มเหลว แตกทั้งหัวเลย ฉันจับการเรียกของเซิร์ฟเวอร์ - รู้สึกว่างเปล่าจนไม่หันไปทางไหน ... ฉันลองกับเครื่องสามเครื่องที่มีแกนต่างกัน หมดแรง..ช่วย...

คำตอบ:ขึ้น

คำตอบ:ดังนั้นฉันจึงตัดสินใจสร้างภาพโหนดอีกครั้ง เมื่อเริ่มต้นโหนด มันบอกว่าต้องเริ่มต้นด้วย \c เพื่อเริ่มอัปเดตฐานข้อมูล
และรีอิมเมจ

ปรากฎว่าเป็นเพราะการอัปเดตที่คดเคี้ยว

ฉันพยายามเรียกใช้ด้วยคีย์นี้และแลกเปลี่ยนกับโหนดที่มีอยู่ ไม่มีการอัปเดตในโหนด ไม่มีการขอให้รีสตาร์ท

และด้วยเหตุนี้ในโหนดหลักจึงไม่ยอมรับข้อความอีกครั้งด้วยข้อผิดพลาดเดียวกัน

ทำอะไรได้บ้าง?
สามารถเปลี่ยนสิ่งที่สมมติขึ้นในโหนดหลักใน conf และทำการแลกเปลี่ยนได้หรือไม่? หรือเขาจะไม่อัพเดทคอนเฟิมทั้งหมดแต่จะเปลี่ยนเฉพาะอะไรบ้างคะ? ฉันจะพยายามทำปมในตอนนี้ แต่ฉันจะรอความคิดของคุณ

คำถาม: ฐานข้อมูลแบบกระจาย - ข้อผิดพลาดระหว่างการแลกเปลี่ยนจะไม่ถูกกำจัด

สวัสดีทุกคน!

สถานการณ์ดังต่อไปนี้

เมื่อโหลดการแลกเปลี่ยนจากโหนดต่อพ่วง ฉันได้รับข้อความ "การกำหนดค่าของโหนด IS แบบกระจายไม่ตรงกับที่คาดไว้"

จากนั้นฉันก็ทำตามคำแนะนำ
ฉันยกเลิกการโหลดการกำหนดค่าจากฐานข้อมูลส่วนกลางไปยัง CF, ยกเลิกการผูกฐานข้อมูลอุปกรณ์ต่อพ่วงจากโหนดกลางโดยการประมวลผล, ลบการกำหนดค่าในฐานข้อมูลอุปกรณ์ต่อพ่วงจากการสนับสนุน, โหลดการกำหนดค่าจากไฟล์
ฉันผูกโหนดกลางในฐานข้อมูลอุปกรณ์ต่อพ่วงโดยการประมวลผล
บันทึกสมัคร

ฉันยกเลิกการโหลดการแลกเปลี่ยนจากฐานข้อมูลกลางอีกครั้ง
ฉันโหลดในอุปกรณ์ต่อพ่วง ฉันยกเลิกการโหลดการแลกเปลี่ยนจากฐานข้อมูลอุปกรณ์ต่อพ่วง
กำลังอัพโหลดไปที่ส่วนกลาง ฉันได้รับข้อความอีกครั้ง "การกำหนดค่าของโหนด IS แบบกระจายไม่ตรงกับที่คาดไว้"
แต่นี่เป็นเรื่องไร้สาระจริง ๆ - ฉันโหลดการกำหนดค่าลงในฐานข้อมูลกลางและไม่มีใครเปลี่ยนการกำหนดค่าในฐานข้อมูลอุปกรณ์ต่อพ่วง

จะแก้ไขข้อผิดพลาดดังกล่าวได้อย่างไร?

คำตอบ:มันไม่เคยเกิดขึ้นกับใครเลยที่จะแนะนำสิ่งที่ชัดเจนเช่นนี้หลังจากสาบานมาหลายปีในการอัพเดทปีศาจ :)

คำถาม: RIB และการอัปเดต

สวัสดีทุกคน. มีการวางแผนที่จะใช้การรักษาความปลอดภัยข้อมูลแบบกระจาย

การกำหนดค่าเปลี่ยนไป การอัปเดตการกำหนดค่าของฐานข้อมูลกลางดำเนินการโดยโปรแกรมเมอร์ จากนั้น ด้วยการแลกเปลี่ยนไฟล์ การเปลี่ยนแปลงเหล่านี้จะถูกถ่ายโอนไปยังฐานข้อมูลส่วนต่อพ่วง

คำถามคือ: แล้วการเปิดตัวตัวจัดการหลังจากอัปเดตการกำหนดค่าฐานข้อมูลและการเข้าสู่ระบบครั้งแรกในโหมดผู้ใช้ล่ะ

อัปเดตการกำหนดค่าหลัก - อัปเดตการกำหนดค่าฐานข้อมูล - เรียกใช้งานตัวจัดการอัปเดตในโหมดผู้ใช้

ตัวอย่างเช่น พลาดหลายรุ่น คุณต้องอัปเกรดตามลำดับเพื่ออัปเกรดเป็น 3 รุ่น ไม่มีปัญหาในการอัปเดตฐานข้อมูลกลาง แต่อุปกรณ์ต่อพ่วงล่ะ นอกจากนี้ยังจำเป็นต้องอัปเดตใน 3 ขั้นตอน (อัปเดตฐานข้อมูลกลางด้วยรีลีสแรก อัปเดต RIB อัปเดตฐานข้อมูลกลางด้วยรีลีสที่สอง อัปเดต RIB เป็นต้น)

ขอขอบคุณทุกท่านสำหรับความช่วยเหลือของคุณ!

คำตอบ:() แหย่จมูกของคุณ ฉันไม่พบรหัสที่ดำเนินการเมื่อลงทะเบียนการเปลี่ยนแปลงวัตถุ
ดูเหมือนว่าถ้าคุณใช้เมธอด OnSendingData โหนดหลักจะยังคงสะสมวัตถุที่เปลี่ยนแปลงเพื่อส่งไปยังโหนดสเลฟ และนี่คือทรัพยากรเพิ่มเติมของคอมพิวเตอร์
ดังนั้น ฉันต้องการไม่ให้วัตถุในโหนดหลักลงทะเบียนเพื่อส่งทันทีในเวลาที่มีการเปลี่ยนแปลง (เช่น On Write) ตัวอย่างเช่น ในการบัญชีมาตรฐาน rev. 3 วัตถุเหล่านี้ลงทะเบียนเพื่อส่งในสถานที่ใด

คำถาม: [แก้ไขแล้ว] เกิดข้อผิดพลาดในการติดต่อฝ่ายสนับสนุนออนไลน์

เรียนผู้เชี่ยวชาญ โปรดบอกฉันที!
1C:Enterprise 8.3 (8.3.11.2899)
ฐานข้อมูลหลายฐานของการกำหนดค่าที่แตกต่างกันกำลังหมุนอยู่บนเซิร์ฟเวอร์ 1C ซึ่งทั้งหมดรองรับอินเทอร์เน็ตเชื่อมต่อและทำงานได้ดี รวม โหลดอัตราแลกเปลี่ยน ธนาคาร เช็คคู่สัญญา SPARK ฯลฯ
การตั้งค่าพร็อกซีจะเหมือนกันสำหรับฐานข้อมูลทั้งหมด
แต่ในฐานข้อมูล BP-3 CORP ข้อผิดพลาดจะเกิดขึ้นเสมอ:

ในบันทึกการลงทะเบียน:

ไม่สามารถรับตั๋วการรับรองความถูกต้องในบริการ
ไม่สามารถโหลดเนื้อหา () (GeneralModule.InternetUserSupportClientServer.Module(362)): เกิดข้อผิดพลาดในการเรียกเมธอดบริบท (SendToProcess)
การตอบสนอง = Connection.SendForProcessing (HTTPRequest, GetParameters.ResponseFileName);
เพราะว่า:
ข้อผิดพลาดทางอินเทอร์เน็ต: โฮสต์ระยะไกลล้มเหลวในการตรวจสอบสิทธิ์

คลิกเพื่อเปิด...

ลองใส่แล้ว รุ่นต่างๆแพลตฟอร์ม (8.3.10..., 8.3.11...) และเวอร์ชันการกำหนดค่าที่แตกต่างกัน (3.0.54.15, 3.0.57.10)
การทดสอบและการแก้ไขไม่ได้ช่วยอะไรเช่นกัน
อะไรจะผิด?
BP-CORP ไปที่อินเทอร์เน็ตในลักษณะพิเศษหรือไม่?
ขอบคุณ

คำตอบ:

คำตอบจาก 1C (สิ่งที่เน้นด้วยสีแดงช่วยฉัน):

ระหว่างการเปลี่ยนแปลง BSP ได้รับการอัปเดตเป็นส่วนหนึ่งของ BP จาก 2.4.3 เป็น 2.4.4
ในรายการการเปลี่ยนแปลงใน BSP 2.4.4
ปรับปรุงการรักษาความปลอดภัยเมื่อสร้างการเชื่อมต่อที่ปลอดภัยกับบริการอินเทอร์เน็ต HTTPS เมื่อตรวจพบ ปัญหาต่างๆด้วยใบรับรองของบริการอินเทอร์เน็ตที่กำลังพยายามเชื่อมต่อที่ปลอดภัย (ใบรับรองไม่ถูกต้อง ล้าสมัย หรือไม่น่าเชื่อถือ) การเชื่อมต่อจะไม่ถูกสร้าง
ใน 8.3.10 การตรวจสอบใบรับรองในหน้าต่างดำเนินการโดยใช้ ระบบปฏิบัติการ." -
ติดตั้งอัปเดตล่าสุดสำหรับระบบปฏิบัติการของคุณ ซึ่งประกอบด้วยการอัปเดตที่สำคัญ ส่วนประกอบของระบบซึ่งมีหน้าที่รับผิดชอบในการทำงานกับใบรับรอง
กรุณาติดตั้งด้วย ปรับปรุงล่าสุดใบรับรองหลักที่จัดจำหน่ายโดย Microsoft ในแพ็คเกจที่ติดตั้งได้
ต้องมีเวอร์ชันอย่างน้อย IE8.0 ประกอบด้วยการอัปเดตที่สำคัญสำหรับส่วนประกอบของระบบที่รับผิดชอบในการทำงานกับใบรับรอง
ตามกฎแล้วหลังจากติดตั้งการอัปเดตทั้งหมดแล้ว ปัญหาจะได้รับการแก้ไข
ตรวจสอบว่าหากคุณป้อนในแถบค้นหาใน Internet Explorer ลิงก์จะเปิดขึ้น
ผู้ใช้ที่คุณทำงานในนามสามารถเข้าถึงอินเทอร์เน็ตได้
หากนี่เป็นฐานข้อมูลไฟล์ในเครื่องไคลเอ็นต์ ควรตรวจสอบบนฐานข้อมูลนั้น
หากนี่คือฐานข้อมูลไคลเอ็นต์เซิร์ฟเวอร์ ให้ระบุบนเซิร์ฟเวอร์ภายใต้ผู้ใช้ที่เซิร์ฟเวอร์ 1C ทำงานอยู่
ตรวจสอบกับเบราว์เซอร์ IE เท่านั้น
ตรวจสอบว่าพอร์ต 443 และ 80 เปิดอยู่
หากคุณใช้พร็อกซีเซิร์ฟเวอร์ ให้ตรวจสอบว่าข้อมูลในเมนูการตั้งค่าส่วนบุคคลได้รับการกำหนดค่าหรือไม่
หากใช้เวอร์ชันไคลเอนต์เซิร์ฟเวอร์ คุณควรกำหนดค่าเซิร์ฟเวอร์ในลักษณะที่การเชื่อมต่ออินเทอร์เน็ตกับเบราว์เซอร์ IE ทำงานได้อย่างถูกต้องภายใต้ผู้ใช้ที่เซิร์ฟเวอร์ 1C กำลังทำงานในนาม​

ฉันลงทะเบียนพร็อกซีในการตั้งค่า IE ของผู้ใช้ที่เซิร์ฟเวอร์ 1C กำลังทำงานอยู่ - ทุกอย่างใช้งานได้

คำถาม: อัปเดต boo 3

ขอให้เป็นวันที่ดี
การบัญชี3
ทำการอัปเดตจาก 3.0.43.208 เป็น 3.0.43.235
ข้อผิดพลาด
อันดับแรก
(GeneralModule.MessagingInternal.Module(381)): เกิดข้อผิดพลาดในการเรียกเมธอดบริบท (ThisNode)

เพราะว่า:
พบมากกว่าหนึ่งรายการ
ที่สอง
เมื่อเรียกตัวจัดการการอัปเดต:
"MessagingInternal.SetThisEndPointCode()"
เกิดข้อผิดพลาด:
"(GeneralModule.MessagingInternal.Module(381)): เกิดข้อผิดพลาดในการเรียกเมธอดบริบท (ThisNode)
ReturnInterchangePlans.MessageExchange.ThisNode();
เพราะว่า:
พบบันทึกมากกว่าหนึ่งรายการ"

แพลตฟอร์มเขียนลาดเทที่นับถือลองบนแพลตฟอร์มเวอร์ชันต่างๆ
พยายามที่จะใช้ conf ที่สะอาด รุ่นล่าสุดและเพียงแค่เปลี่ยนโหลดให้สมบูรณ์อย่างโง่เขลา
ไม่ช่วยอะไรเลย เหมือนเดิมตลอด บอกฉันทีใครมาขวาง?

คำตอบ:

โหนดจากจริงเป็นเท็จ