تكوين 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 ، قام العميل بتحميل نسخة من قاعدة البيانات العاملة ولم يقم بإيقاف تشغيلها في نسخة السجل. مهام التبادل التلقائي ، ونتيجة لذلك ، تم تشكيل جزء من الرسائل إلى العقد البعيدة من قاعدة البيانات العاملة ، وجزء من النسخة ، مما أدى إلى إلغاء تزامن التكوينات

هناك أيضًا رأي مفاده أن استخدام آلية تحديث قاعدة البيانات الديناميكية يؤدي إلى هذا الخطأ. هناك شكوك هنا ، لأنه من ناحية ، لا يؤثر التحديث الديناميكي أبدًا على بنية قاعدة البيانات ، ولا تزال آليات RIB تعمل مع بنية قاعدة البيانات ، وليس مع جزء التطبيق الخاص بها ، ومع ذلك ، يستخدم RIB آلية إنشاء توقيع رقمي لـ إصدار التكوين (سأطلق عليه اسم التجزئة باختصار) ، وعندما يتغير جزء التطبيق ، يجب إعادة حساب التجزئة بشكل طبيعي. لن أنكر هذا ولا أؤكد ذلك لأن. إذا واجهت هذا الموقف ، فأنا لم أجد دليلًا واضحًا على ذلك.

أستخدم طريقتين لإصلاحه ، اعتمادًا على الموقف.

الطريقة الأولى

تم ذكر الأول (الأكثر شيوعًا) مرارًا وتكرارًا في كل من مؤتمر الشركاء وعلى موارد الإنترنت الأخرى المتعلقة بـ 1C. يتم استخدامه في معظم الحالات ، على الرغم من الرسالة المتعلقة بالتباين في التكوينات ، عند مقارنتها يدويًا ، يبدو أنها متطابقة.

التسلسل:

1. تفريغ ملف cf من البنك المركزي ؛
2. قمنا بفك ربط UB من RIB (طريقة SetMainNode ، يمكن العثور على المعالجة الجاهزة في التطبيق أو في المنشورات الأخرى) ؛
3. استبدال أسيوط. UB على ملف cf الذي تم تفريغه في الخطوة الأولى ، لذلك نستخدم قائمة "تحميل التكوين من ملف" (وليس عن طريق مقارنة الاتحاد !!!) ؛
4. دعنا نستعيد علامة RIB لـ UB.

في معظم الحالات ، تكون هذه الإجراءات أكثر من كافية لاستعادة التبادل ، ولكن ليس دائمًا ...

الطريقة الثانية

يتم استخدامه إذا لم تنجح الطريقة الأولى ، ولا يمكن تفريغ العقدة مرة أخرى.

الخلفية: كان العميل يقوم بإعداد RIB متتالي وحدث خطأ في المستوى الأول من التتالي (المستوى الثاني يعمل بشكل لا تشوبه شائبة طوال هذا الوقت). تم تطوير التكوين بالاشتراك مع خدمة تكنولوجيا المعلومات الخاصة بالعميل ، ومنذ حدوث الخطأ ، تغير تكوين CB عدة مرات. لم يتم النظر في خيار التراجع عن التغييرات من حيث المبدأ ، لأن كان فقدان جزء من البيانات وإغلاق العديد من الإدارات أمرًا غير مقبول تمامًا. النسخة الأولى من تصحيح الخطأ لم تعطِ أي نتائج ملموسة. نتيجة لذلك ، كان لابد من إيجاد حلول أخرى.

جاءت الفكرة لمحاولة تغيير تجزئات ملفات التكوين مباشرة في ملفات XML التبادلية. وصف بنية ملف الصرف من الكتاب " التطوير المهنيفي 1C: نظام Enterprise 8 "أعطى فكرة سيئة عن التشكيل التوقيعات الرقميةالتكوينات والتغييرات عليها ، لكنها حددت اتجاه البحث: قيم Digest1 و Digest2. لقد اكتشفت كل شيء آخر تجريبيًا بحتًا (أي عن طريق التجربة والخطأ) ، لكنني تمكنت من إنشاء نمط.

سارت تجارب الاختبار بشكل جيد. على القواعد أيضًا ، سار كل شيء على ما يرام.

إذن ، تسلسل الإجراءات:

1. نفذ الخطوات 1-4 من التقنية الأولى ؛
2. تفريغ ملف التبادل من UB ، لكن لا تقم بتحميله إلى CB ؛
3. تفريغ ملف الصرف من البنك المركزي ، ولكن لا تقم بتحميله إلى UB ؛
4. في ملف التبادل من CB ، نستبدل الكتلة التي تحتوي على معلومات حول تغييرات التكوين والتجزئة (Digest1 و Digest2) بكتلة من التجزئة من ملف UB (انظر المثال أدناه)
5. نقوم بتحميل الملف من النقطة الرابعة إلى UB ؛
6. تأكد من الكتابة فوق ملف التبادل من UB (الفقرة الثانية)! يجب عدم تحميل هذا الملف عند التبادل في CB!
7. للتحقق ، نجري العديد من التبادلات المتتالية.

إذا تم استخدام ضغط البيانات أثناء التبادل ، فقم بإيقاف الضغط ، أو قم أولاً بفك ضغط الملف ، قم بتغييره ، ثم أعد حزمه وأرسله.

منع تبادل الملفات من CB

106.0... ها هي الكتل التي تصف تغييرات التكوين ... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

تحتاج إلى استبدالها بكتلة من ملف التبادل من UB (لاحظ أن Digest1 للملف من UB يساوي دائمًا "00000000000000000000000000000000" !!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

يجب تنفيذ الإجراءات المذكورة بحذر شديد ، حيث أن التسلسل غير الصحيح محفوف بعدم التشغيل الكامل لـ RIB. لذلك ، قبل هذه الإجراءات ، يعد إنشاء نسخ احتياطية أمرًا إلزاميًا!

خلاف ذلك ، لا يسعني إلا أن أتمنى لك حظا سعيدا!

يمكن أن تكون أخطاء التحديث الديناميكي (أو مواطن الخلل الأخرى في النظام الأساسي) هي أسباب أخطاء تبادل قاعدة المعلومات الموزعة:

• "يتم تلقي البيانات من العقدة التي تم تسجيل تغييرات التكوين الخاصة بها"
  

• "تكوين عقدة IS الموزعة ليس كما هو متوقع"
  

كيفية استعادة الصرف؟

لكن لنبدأ ليس بالاستعادة ، ولكن بفرصة الإنفاقتغيير "يدويًا" ، وهو أمر مهم خلال اليوم ، لأنه ، كما هو الحال دائمًا ، يجب أن يعمل كل شيء "بالأمس" :) يمكنك القيام بذلك بمساعدة العلاجات الرائعة التي لا أتذكرهاNu حيث قمت بتنزيل (المؤلفون ، الرد - سأترك روابط لموردك ، ومن خاصتي ، إذا لزم الأمر ، سأحذفها). تسمح المعالجة بإلغاء تحميل تغييرات البيانات المسجلة فقط في قاعدة البيانات (وفقًا لخطة التبادل المحددة لعقدة معينة!) في XML دون إلغاء تحميل تغييرات التكوين ، وإذا لم تتغير كائنات التكوين كثيرًا ، فهناك فرص كبيرة جدًا لحدوث ذلك. تحميل هذه البيانات. يمكن تنزيلها من الرابط في نهاية المقال.

أما الانتعاش. هناك طرق أبسط لا تتضمن جميع العناصر في القائمة أدناه ، لكنها لا تساعد دائمًا ، كما كان الحال في إحدى حالاتي. لذلك ، أعطي الطريقة التي ساعدتني ، فهي تتجاوز المشاكل المحتملة بشكل أكثر شمولاً. مزيد من الخطوات.

يُنصح بإجراء هذه الخطوات في حالة عدم وجود مستخدمين عاملين في قاعدة البيانات. إذا لم يكن ذلك ممكنًا ، فسيتعين عليك "إنهاء" الطريقة بنفسك ، وبالتالي يجب عليك أولاً فهم منطقها.

1. عمل نسخ احتياطية في كل مكان.

2. بالنسبة لخوادم العميل: قم بتعطيل قواعد البيانات من خلال "إدارة الخادم" والاتصال فورًا بتثبيت حظر المهام المجدولة (وبالتالي سيتم إعادة تعيين ذاكرة التخزين المؤقت للخادم). بعد ذلك ، لا تنس نقل سجل التسجيل إلى الدليل الجديد.

3. على جميع أجهزة الكمبيوتر المستخدمة للاسترداد ، احذف قاعدة البيانات في قائمة قواعد بيانات 1C المبدئي وأنشئ قاعدة بيانات جديدة (سيتم مسح ذاكرة التخزين المؤقت للمستخدم)

4. في المُكوِّن (في قاعدة البيانات المركزية) ، أضف ثابتًا جديدًا لحفظ التغييرات في ملف conf.

5. تنظيف كافة أدلة الصرف.

6. القيام بعمليات تفريغ لجميع الفروع (حتى الآن تفريغ فقط).

7. حاول تحميل (تحميل فقط) البيانات المستلمة لجميع الفروع. من الطبيعي قبول التغييرات في conf.

إذا كان كل شيء جيدًا في كل مكان ، فإننا نذهب إلى أبعد من ذلك ، وإذا كان كل شيء سيئًا ، فنحن نعتقد أن تحميل .cf من قاعدة البيانات المركزية وتحميلها إلى الفرع (وليس اتحاد المقارنة) قد يساعد. في العقدة التابعة ، يجب أن تفك ربط القاعدة من RIB (ستساعد المعالجة في ذلك - التنزيل من الرابط أدناه). يوجد مقال حول هذا الموضوع في infostart.ru.

8. نقوم بإلغاء تسجيل التغييرات للفروع في البنك المركزي (بعد كل شيء ، لقد تلقينا بالفعل جميع التغييرات في كل مكان). من المهم القيام بذلك في هذه المرحلة حتى تصل التغييرات المتراكمة من الفروع المختلفة إلى الفروع الأخرى. (تحميل معالجة لفك الربط من الرابط أدناه).

9. نقوم بالتحميل إلى البنك المركزي ، وإذا كان كل شيء على ما يرام ، فإننا نقوم بالتحميل والتفريغ مع كل فرع عدة مرات لتوحيد النتيجة.

10. كل شيء.

يمكنك تمكين تنفيذ المهام المجدولة لقواعد بيانات خادم العميل.

لمنع المشاكل التي تسبب هذا الخطأ ، يوصى بعدم إجراء تحديث ديناميكي (عدة مرات متتالية على الأقل - قبل تحميل التغييرات إلى الفروع) ، كما يُنصح بتحديد خانة الاختيار "تحميل البيانات فقط عند التحميل الناجح" في إعدادات الصرف.

بادئ ذي بدء ، إليك قائمة بالاختصارات التي أستخدمها:

• RIB - قاعدة معلومات موزعة
• CB - القاعدة المركزية ، عقدة الجذر RIB
• UB - قاعدة بعيدة ، قاعدة بيانات العقدة البعيدة RIB

من تجربتي الخاصة ، يمكنني القول إنني واجهت سببين للخطأ:

1. أثناء تلقي ملف الرسائل في UB ، "سقطت" القاعدة ، والتي ، على ما يبدو ، كان هناك عدم التزامن بين conf. البنك المركزي و UB؛
2. تحت MSSQL ، قام العميل بتحميل نسخة من قاعدة البيانات العاملة ولم يقم بإيقاف تشغيلها في نسخة السجل. مهام التبادل التلقائي ، ونتيجة لذلك ، تم تشكيل جزء من الرسائل إلى العقد البعيدة من قاعدة البيانات العاملة ، وجزء من النسخة ، مما أدى إلى إلغاء تزامن التكوينات

هناك أيضًا رأي مفاده أن استخدام آلية تحديث قاعدة البيانات الديناميكية يؤدي إلى هذا الخطأ. هناك شكوك هنا ، لأنه من ناحية ، لا يؤثر التحديث الديناميكي أبدًا على بنية قاعدة البيانات ، ولا تزال آليات RIB تعمل مع بنية قاعدة البيانات ، وليس مع جزء التطبيق الخاص بها ، ومع ذلك ، يستخدم RIB آلية إنشاء توقيع رقمي لـ إصدار التكوين (سأطلق عليه اسم التجزئة باختصار) ، وعندما يتغير جزء التطبيق ، يجب إعادة حساب التجزئة بشكل طبيعي. لن أنكر هذا ولا أؤكد ذلك لأن. إذا واجهت هذا الموقف ، فأنا لم أجد دليلًا واضحًا على ذلك.

أستخدم طريقتين لإصلاحه ، اعتمادًا على الموقف.

الطريقة الأولى

تم ذكر الأول (الأكثر شيوعًا) مرارًا وتكرارًا في كل من مؤتمر الشركاء وعلى موارد الإنترنت الأخرى المتعلقة بـ 1C. يتم استخدامه في معظم الحالات ، على الرغم من الرسالة المتعلقة بالتباين في التكوينات ، عند مقارنتها يدويًا ، يبدو أنها متطابقة.

التسلسل:

1. تفريغ ملف cf من البنك المركزي ؛
2. قمنا بفك ربط UB من RIB (طريقة SetMainNode ، يمكن العثور على المعالجة الجاهزة في التطبيق أو في المنشورات الأخرى) ؛
3. استبدال أسيوط. UB على ملف cf الذي تم تفريغه في الخطوة الأولى ، لذلك نستخدم قائمة "تحميل التكوين من ملف" (وليس عن طريق مقارنة الاتحاد !!!) ؛
4. دعنا نستعيد علامة RIB لـ UB.

في معظم الحالات ، تكون هذه الإجراءات أكثر من كافية لاستعادة التبادل ، ولكن ليس دائمًا ...

الطريقة الثانية

يتم استخدامه إذا لم تنجح الطريقة الأولى ، ولا يمكن تفريغ العقدة مرة أخرى.

الخلفية: كان العميل يقوم بإعداد RIB متتالي وحدث خطأ في المستوى الأول من التتالي (المستوى الثاني يعمل بشكل لا تشوبه شائبة طوال هذا الوقت). تم تطوير التكوين بالاشتراك مع خدمة تكنولوجيا المعلومات الخاصة بالعميل ، ومنذ حدوث الخطأ ، تغير تكوين CB عدة مرات. لم يتم النظر في خيار التراجع عن التغييرات من حيث المبدأ ، لأن كان فقدان جزء من البيانات وإغلاق العديد من الإدارات أمرًا غير مقبول تمامًا. النسخة الأولى من تصحيح الخطأ لم تعطِ أي نتائج ملموسة. نتيجة لذلك ، كان لابد من إيجاد حلول أخرى.

جاءت الفكرة لمحاولة تغيير تجزئات ملفات التكوين مباشرة في ملفات XML التبادلية. أعطى وصف بنية ملف التبادل من كتاب "التطوير المهني في 1C: نظام المؤسسة 8" فكرة سيئة عن تكوين التواقيع الرقمية للتكوينات والتغييرات فيها ، لكنه حدد اتجاه البحث: Digest1 و قيم Digest2. لقد اكتشفت كل شيء آخر تجريبيًا بحتًا (أي عن طريق التجربة والخطأ) ، لكنني تمكنت من إنشاء نمط.

سارت تجارب الاختبار بشكل جيد. على القواعد أيضًا ، سار كل شيء على ما يرام.

إذن ، تسلسل الإجراءات:

1. نفذ الخطوات 1-4 من التقنية الأولى ؛
2. تفريغ ملف التبادل من UB ، لكن لا تقم بتحميله إلى CB ؛
3. تفريغ ملف الصرف من البنك المركزي ، ولكن لا تقم بتحميله إلى UB ؛
4. في ملف التبادل من CB ، نستبدل الكتلة التي تحتوي على معلومات حول تغييرات التكوين والتجزئة (Digest1 و Digest2) بكتلة من التجزئة من ملف UB (انظر المثال أدناه)
5. نقوم بتحميل الملف من النقطة الرابعة إلى UB ؛
6. تأكد من الكتابة فوق ملف التبادل من UB (الفقرة الثانية)! يجب عدم تحميل هذا الملف عند التبادل في 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 جهاز كمبيوتر) ... لم يساعد. ولكن بعد كل شيء ، تم تحديث متجرين تجريبيين دون مشاكل ، لا أستطيع أن أفهم كيف.

إجابة:() هكذا أقوم بتثبيت العقدة الرئيسية. لقد كتبت قليلاً عن شيء آخر: بعد فك ربط العقدة عن طريق المعالجة ، في المرة التالية التي تبدأ فيها تحديث conf لا يبدأ فورًا ، ولكن 1C الأول يفتح نافذة يطلب منك فيها تأكيد أن العقدة غير مقيدة. بعد ذلك ، يتم تحديثه - بعد التحديث ، لم تعد العقدة موجودة في القائمة.
في الواقع ، في الإصدار 2.1 ، أتذكر أنني قمت بتحديثه باستخدام هذه الطريقة ، ولكن لم يتم تشغيل شيء ما في 2.2. ربما ، في الحديقة ، قام بالفعل بدس التسلسل الخاطئ في الإجراءات)

حسب الموضوع:
فهمت ما هو. اتضح أنه تغاضى عن:
"في أحد الإصدارات 2.2 ، ظهر دليل يوزع التقارير مع عنصر محدد مسبقًا"البيانات الشخصية" - كان الدليل الذي يحتوي على هذا العنصر أيضًا على 2.1.

الفارق الدقيق هو: لوحظ وجود عضادات مع عقد التحديث على تلك القواعد التي تم إنشاؤها من القاعدة المركزية على وجه التحديد في الإصدار 2.1.9.18. تم تحديث كل شيء تم إنشاؤه في الإصدارات السابقة بشكل طبيعي. هذا ، على الأرجح ، يفسر سبب تحديث قاعدتين لـ TS بنجاح ، ثم انتقلت العضادات.

لم أخترع أي شيء مع إنشاء عنصر جديد في الدليل وتعيينه على أنه محدد مسبقًا. نقل هذا العنصر من نسخة المركز إلى 2.1 من خلال تفريغ / تحميل XML وكرر التحديث على "القاعدة" الإشكالية - كل شيء سار على ما يرام.

() لذا استخدم الطريقة إذا لم تجد الإجابة بعد.

سؤال: خطأ في تحديث التكوين

أقوم بتحديث تكوين المحاسبة 2.0.64.14 إلى 2.0.64.24. المنصة 8.2.19
حدث خطأ على الفور:
خطأ في الوصول إلى الملف ... المسار ... file.tmp مؤقت.
أين تبحث؟

إجابة:حل هذه المشكلة عن طريق انتظار إصدار جديد "مستقر"

السؤال: خطأ في حقوق المستخدم في BSP

تحيات!!! أنا أكتب conf بناءً على 2.2 BSP ، يبدو أن لدي خبرة بالفعل ، وقد درست الأحواض صعودًا وهبوطًا ، ولكن في المرة الأولى التي أبدأ فيها برنامج IB ، حدث خطأ:

(CommonModule.UsersService.Module (345)): فشل التخويل. سيتم إغلاق النظام.
المستخدم: لم يتم العثور على المسؤول في دليل "المستخدمون".

حدث خطأ أثناء محاولة إضافة مستخدم إلى الدليل:
"فشل تحديث قاعدة المعلومات.
لم يتم ملء معلمة تقييد الوصول:
"الحقوق الممكنة لتحديد حقوق الكائن".

للمطور: قد تحتاج إلى تحديث البيانات الداعمة ،
التي تؤثر على عمل البرنامج. لإجراء تحديث ، يمكنك:
- استغل الفرصة المعالجة الخارجية
"أدوات المطور: تحديث بيانات الدعم" ،
- قم بتشغيل البرنامج باستخدام المعلمة سطر الأوامر 1C: المؤسسة 8
"/ C Startupdating Infobase" ،
- إما زيادة رقم إصدار التكوين بحيث يتم ذلك في البداية التالية
تم الانتهاء من إجراءات تحديث بيانات قاعدة المعلومات ".

انقر للكشف ...

أود أن أسمع إجابات "ذوي الخبرة" ، لحوار نشط لاحق ، وربما حتى تعاون

إجابة:

قال 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 الجديد (مصنع XDTO) ؛
المشترك = NewXDTOSerializer.ReadXDTO (xdtoSubscriber) ،
إعلام = DeliverableNotification جديد ؛
Notification.Recipients.Add (مشترك) ؛
Notification.Text = نص ؛
Notification.SoundAlert = SoundAlert.Default ،
Notice.Sticker = 1 ؛
DATAAuz = رمز ؛
SendingDeliverableNotifications.Send (إعلام ، AuzData ، صحيح) ؛

الآن الخطأ هو فشل التحقق من صحة المضيف البعيد. كسرت رأسي بالكامل. لقد اكتشفت مكالمات الخادم - أشعر بالفراغ لأنها لا تتحول إلى أي مكان ... جربت ثلاث أجهزة مختلفة بمحاور مختلفة. استنفدت .. مساعدة ...

إجابة:أعلى

إجابة:لذلك ، قررت أن أجعل صورة العقدة مرة أخرى. عند بدء العقدة ، تقول أنه يجب أن تبدأ بـ \ c لبدء تحديث قاعدة المعلومات
وإعادة الصورة.

اتضح أن هذا شيء بسبب التحديث الملتوي.

حاولت تشغيل هذا المفتاح وإجراء تبادل مع عقدة موجودة. لم يتم إطلاق أي تحديثات في العقدة ، ولم يُطلب أي شيء لإعادة التشغيل.

ونتيجة لذلك ، في العقدة الرئيسية ، لم يتم قبول الرسالة مرة أخرى بنفس الخطأ.

ماذا يمكن ان يفعل؟
هل يمكن تغيير شيء وهمي في العقدة الرئيسية في conf وإجراء التبادل؟ أم أنه لن يقوم بتحديث أسيوط بالكامل ، ولكن فقط ما الذي سأغيره؟ سأحاول عمل عقدة الآن. لكنني سأنتظر أفكارك.

سؤال: قاعدة البيانات الموزعة - لا يتم التخلص من الخطأ أثناء التبادل

يوم جيد للجميع!

الوضع هو التالي.

عند تحميل تبادل من عقدة طرفية ، أتلقى الرسالة "تكوين عقدة IS الموزعة لا يتطابق مع المتوقع".

ثم أتبع التعليمات.
أقوم بإلغاء تحميل التكوين من قاعدة البيانات المركزية إلى CF ، وفك ربط قاعدة البيانات الطرفية من العقدة المركزية عن طريق المعالجة ، وإزالة التكوين في قاعدة البيانات الطرفية من الدعم ، وتحميل التكوين من ملف.
أقوم بربط العقدة المركزية في قاعدة البيانات الطرفية عن طريق المعالجة.
حفظ وتطبيق.

أفرغ التبادل مرة أخرى من قاعدة البيانات المركزية.
أنا تحميل في الطرفية. أفرغ تحميل التبادل من قاعدة البيانات الطرفية.
تحميل إلى المركزية. مرة أخرى أحصل على الرسالة "تكوين عقدة IS الموزعة لا يتطابق مع المتوقع".
لكن هذا هراء حقيقي - أقوم بتحميل التكوين في قاعدة البيانات المركزية ولم يغير أحد التكوين في قاعدة البيانات الطرفية.

كيف تتغلب على مثل هذا الخطأ؟

إجابة:لم يخطر ببال أي شخص أن ينصح بمثل هذه الأشياء الواضحة بعد سنوات عديدة من القسم على التحديث الشيطاني :)

السؤال: RIB والتحديثات

أهلاً بكم. من المخطط استخدام أمن المعلومات الموزع.

تغير التكوين. يقوم المبرمج بتحديث تكوين قاعدة البيانات المركزية. بعد ذلك ، مع ملفات التبادل ، سيتم نقل هذه التغييرات إلى قواعد البيانات الطرفية.

السؤال هو: ماذا عن إطلاق المعالجات بعد تحديث تكوين قاعدة البيانات وأول تسجيل دخول في وضع المستخدم؟

تحديث التكوين الرئيسي - تحديث تكوين قاعدة البيانات - تنفيذ معالجات التحديث في وضع المستخدم

على سبيل المثال ، تم فقدان العديد من الإصدارات ، تحتاج إلى الترقية بشكل تسلسلي للترقية إلى 3 إصدارات. لا توجد مشاكل في تحديث قاعدة البيانات المركزية ، ولكن ماذا عن الأطراف الطرفية؟ من الضروري أيضًا تحديثها في 3 مراحل (تحديث قاعدة البيانات المركزية بالإصدار الأول ، وتحديث RIB ، وتحديث قاعدة البيانات المركزية بالإصدار الثاني ، وتحديث RIB ، وما إلى ذلك؟)

شكرا لكم جميعا لمساعدتكم!

إجابة:() نكز أنفك ، لا يمكنني العثور على الكود الذي يتم تنفيذه عند تسجيل تغييرات الكائن.
يبدو أنه إذا كنت تستخدم طريقة OnSendingData ، فستظل العقدة الرئيسية تتراكم الكائنات التي تم تغييرها لإرسالها إلى العقدة التابعة. وهذه موارد كمبيوتر إضافية
لذلك ، أريد عدم تسجيل الكائنات الموجودة في العقدة الرئيسية لإرسالها فورًا في وقت تغييرها (عند الكتابة ، على سبيل المثال). في أي مكان ، على سبيل المثال ، في مراجعة المحاسبة القياسية 3 ، يتم تسجيل هذه الكائنات للإرسال؟

سؤال: [تم الحل] خطأ في الاتصال بالدعم عبر الإنترنت

أعزائي الخبراء ، أخبرني ، من فضلك!
1C: المؤسسة 8.3 (8.3.11.2899)
يتم تدوير العديد من قواعد البيانات ذات التكوينات المختلفة على خادم 1C ، وفي كل منها يتم توصيل دعم الإنترنت ويعمل بشكل جيد. بما في ذلك. تحميل أسعار الصرف ، البنوك ، التحقق من الأطراف المقابلة ، SPARK ، إلخ.
إعدادات الوكيل هي نفسها لجميع قواعد البيانات.
ولكن في قواعد بيانات BP-3 CORP ، يحدث خطأ دائمًا:

في سجل التسجيل:

فشل الحصول على بطاقة المصادقة في الخدمة.
فشل تحميل المحتوى (). (GeneralModule.InternetUserSupportClientServer.Module (362)): خطأ في استدعاء أسلوب السياق (SendToProcess)
الاستجابة = Connection.SendForProcessing (HTTPRequest، ReceiveParameters.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 ، يتم إجراء التحقق من الشهادة في windows باستخدام نظام التشغيل." -
قم بتثبيت آخر التحديثات لنظام التشغيل الخاص بك ، فهي تحتوي على تحديثات مهمة مكونات النظام، وهي المسؤولة عن التعامل مع الشهادات.
يرجى أيضًا التثبيت اخر تحديثشهادات الجذر التي توزعها 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.SNode () ،
بسبب:
تم العثور على أكثر من سجل ".

جربت منصة الكتابة المحترمة على إصدارات مختلفة من المنصات
حاولت أن تأخذ أسيوط نظيفة احدث اصدارواستكمل فقط بغباء الاستبدال للتحميل
لم يساعد على الإطلاق ، دائمًا نفس الشيء. قل لي فجأة من جاء عبر؟

إجابة:

عقدة من صواب إلى خطأ