Αυτό το σφάλμα είναι τυπικό για . Το σφάλμα "Η διαμόρφωση κόμβου κατανεμημένου IS δεν ταιριάζει με την αναμενόμενη" είναι σφάλμα συστήματος. Αυτό συμβαίνει κυρίως λόγω συντριβής κατά την ανταλλαγή δεδομένων μέσω του URIB.
Αυτό μπορεί να λυθεί με έναν αρκετά απλό τρόπο. Ας το αναλογιστούμε.
Εντολή
1. Δημιουργήστε αντίγραφα των βάσεων δεδομένων στις οποίες θα εργαστείτε (Στο διαμορφωτή "Διαχείριση - Ξεφόρτωση βάσης πληροφοριών").
2. Εκτελέστε το πρόγραμμα διαμόρφωσης για την κύρια βάση δεδομένων του κόμβου RIB.
3. Αποθηκεύστε τη διαμόρφωση του κεντρικού κόμβου σε ένα αρχείο βάσης δεδομένων ("Διαμόρφωση - Αποθήκευση διαμόρφωσης σε αρχείο...")
4. Ανοίξτε το διαμορφωτή βάσης υποτελούς κόμβου.
Λάβετε δωρεάν μαθήματα βίντεο 267 1C:
5. Καταργήστε τη διαμόρφωση του υποτελούς κόμβου από την υποστήριξη (Διαμόρφωση - Υποστήριξη - Ρυθμίσεις υποστήριξης - Κατάργηση υποστήριξης):
6. Φορτώστε τη διαμόρφωση της βάσης δεδομένων ("Configuration - Load configuration from file...").
8. Μετά την αναδιάρθρωση, πρέπει να εισέλθετε στην επιχειρησιακή λειτουργία και να εγκαταστήσετε τον κύριο κόμβο διαμόρφωσης. Αυτό μπορεί να γίνει χρησιμοποιώντας ειδική επεξεργασία -. Η επεξεργασία λειτουργεί τόσο σε λειτουργία διαχειριζόμενης εφαρμογής όσο και σε κανονική λειτουργία εφαρμογής.
9. Κατά την επεξεργασία, επιλέξτε τον κύριο κόμβο και κάντε κλικ στο "Εκτέλεση":
10. Έγινε! Προσπαθήστε να ξεκινήσετε την ανταλλαγή, το σύστημα θα πρέπει να εκτελέσει σωστά την ανταλλαγή.
Για αρχή, εδώ είναι μια λίστα με τις συντομογραφίες που χρησιμοποιώ:
- RIB - κατανεμημένη βάση πληροφοριών
- CB - κεντρική βάση, ριζικός κόμβος RIB
- UB - απομακρυσμένη βάση, βάση δεδομένων του απομακρυσμένου κόμβου RIB
Από τη δική μου εμπειρία, μπορώ να πω ότι αντιμετώπισα δύο λόγους για το σφάλμα:
- κατά την παραλαβή του αρχείου μηνύματος στο UB, η βάση «έπεσε», σε σχέση με την οποία, προφανώς, υπήρξε αποσυγχρονισμός μεταξύ του conf. Κεντρική Τράπεζα και UB·
- στο MSSQL, ο πελάτης φόρτωσε ένα αντίγραφο της βάσης δεδομένων εργασίας και δεν το απενεργοποίησε στο αντίγραφο του reg. εργασίες αυτόματης ανταλλαγής, ως αποτέλεσμα, μέρος των μηνυμάτων σε απομακρυσμένους κόμβους σχηματίστηκε από τη βάση δεδομένων εργασίας και μέρος από το αντίγραφο, το οποίο οδήγησε στον αποσυγχρονισμό των διαμορφώσεων
Υπάρχει επίσης η άποψη ότι η χρήση του μηχανισμού ενημέρωσης δυναμικής βάσης δεδομένων οδηγεί σε αυτό το σφάλμα. Υπάρχουν αμφιβολίες εδώ, επειδή αφενός, η δυναμική ενημέρωση δεν επηρεάζει ποτέ τη δομή της βάσης δεδομένων και οι μηχανισμοί RIB εξακολουθούν να λειτουργούν με τη δομή της βάσης δεδομένων και όχι με το τμήμα εφαρμογής της, ωστόσο, το RIB χρησιμοποιεί τον μηχανισμό για τη δημιουργία ψηφιακής υπογραφής την έκδοση διαμόρφωσης (θα την ονομάσω συνοπτικά κατακερματισμό) και όταν αλλάξει το τμήμα της εφαρμογής, ο κατακερματισμός πρέπει φυσικά να επανυπολογιστεί. Δεν θα το αρνηθώ, ούτε θα το επιβεβαιώσω, γιατί. αν αντιμετώπιζα αυτή την κατάσταση, τότε δεν βρήκα σαφείς αποδείξεις γι' αυτό.
Χρησιμοποιώ 2 μεθόδους για να το διορθώσω, ανάλογα με την περίσταση.
ΠΡΩΤΗ ΜΕΘΟΔΟΣ
Το πρώτο (το πιο κοινό) αναφέρεται επανειλημμένα τόσο στη διάσκεψη συνεργατών όσο και σε άλλους πόρους του Διαδικτύου που σχετίζονται με το 1C. Χρησιμοποιείται στις περισσότερες περιπτώσεις, όταν παρά το μήνυμα για τις αποκλίσεις των διαμορφώσεων, όταν συγκρίνονται χειροκίνητα, φαίνεται ότι είναι πανομοιότυπες.
Αλληλουχία:
- ξεφορτώστε το αρχείο cf από την Κεντρική Τράπεζα.
- αποσυνδέουμε το UB από το RIB (η μέθοδος SetMainNode, η έτοιμη επεξεργασία μπορεί να βρεθεί στην εφαρμογή ή σε άλλες δημοσιεύσεις).
- αντικαταστήστε conf. UB στο αρχείο cf που εκφορτώθηκε στο πρώτο βήμα, για αυτό χρησιμοποιούμε το μενού "Φόρτωση διαμόρφωσης από αρχείο" (και όχι με σύγκριση-ένωση !!!).
- ας επαναφέρουμε το σήμα του RIB για το UB.
Στις περισσότερες περιπτώσεις, αυτές οι ενέργειες είναι υπεραρκετές για την αποκατάσταση της ανταλλαγής, αλλά όχι πάντα...
ΔΕΥΤΕΡΗ ΜΕΘΟΔΟΣ
Χρησιμοποιείται εάν η πρώτη μέθοδος δεν λειτούργησε και δεν είναι δυνατή η εκ νέου εκφόρτωση του κόμβου.
Ιστορικό: ο πελάτης έφτιαχνε ένα διαδοχικό RIB και παρουσιάστηκε ένα σφάλμα στο πρώτο επίπεδο του καταρράκτη (το δεύτερο επίπεδο λειτουργούσε άψογα όλο αυτό το διάστημα). Η διαμόρφωση αναπτύχθηκε από κοινού με την υπηρεσία IT του πελάτη και από τότε που παρουσιάστηκε το σφάλμα, η διαμόρφωση CB έχει αλλάξει αρκετές φορές. Η επιλογή επαναφοράς των αλλαγών δεν εξετάστηκε καν κατ' αρχήν, γιατί η απώλεια μέρους των δεδομένων και το κλείσιμο πολλών τμημάτων ήταν εντελώς απαράδεκτα. Η πρώτη έκδοση της διόρθωσης σφάλματος δεν έδωσε απτά αποτελέσματα. Ως αποτέλεσμα, έπρεπε να βρεθούν άλλες λύσεις.
Η ιδέα ήρθε να προσπαθήσουμε να αλλάξουμε τους κατακερματισμούς των αρχείων διαμόρφωσης απευθείας στα αρχεία XML της ανταλλαγής. Περιγραφή της δομής του αρχείου ανταλλαγής από το βιβλίο " Επαγγελματική ανάπτυξηστο σύστημα 1C:Enterprise 8" έδωσε μια κακή ιδέα για το σχηματισμό ψηφιακές υπογραφέςδιαμορφώσεις και αλλαγές σε αυτές, αλλά καθόρισε την κατεύθυνση αναζήτησης: Τιμές Digest1 και Digest2. Όλα τα άλλα τα κατάλαβα καθαρά εμπειρικά (δηλαδή με δοκιμή και λάθος), αλλά κατάφερα να δημιουργήσω ένα μοτίβο.
Τα πειράματα δοκιμής πήγαν καλά. Και στις βάσεις όλα πήγαν καλά.
Έτσι, η σειρά των ενεργειών:
- εκτελέστε τα βήματα 1 - 4 της πρώτης τεχνικής.
- ξεφορτώστε το αρχείο ανταλλαγής από το UB, αλλά μην το ανεβάσετε στο CB.
- ξεφορτώστε το αρχείο ανταλλαγής από την Κεντρική Τράπεζα, αλλά μην το ανεβάσετε στο UB.
- στο αρχείο ανταλλαγής από το CB, αντικαθιστούμε το μπλοκ που περιέχει πληροφορίες σχετικά με αλλαγές διαμόρφωσης και κατακερματισμούς (Digest1 και Digest2) με ένα μπλοκ κατακερματισμών από το αρχείο UB (δείτε ένα παράδειγμα παρακάτω)
- ανεβάζουμε το αρχείο από το 4ο σημείο στο UB.
- φροντίστε να αντικαταστήσετε το αρχείο ανταλλαγής από το UB (2η παράγραφος)! αυτό το αρχείο δεν πρέπει να φορτώνεται κατά την ανταλλαγή στο CB!
- για έλεγχο, κάνουμε πολλές διαδοχικές ανταλλαγές.
Εάν χρησιμοποιείται συμπίεση δεδομένων κατά τη διάρκεια της ανταλλαγής, τότε είτε απενεργοποιήστε τη συμπίεση ή πρώτα αποσυσκευάστε το αρχείο, αλλάξτε το, μετά συσκευάστε το ξανά και στείλτε το.
Αποκλεισμός ανταλλαγής αρχείων από το CB
Πρέπει να αντικατασταθείτε από ένα μπλοκ του αρχείου ανταλλαγής από το UB (σημειώστε ότι το digest1 του αρχείου από το UB είναι πάντα ίσο με το "00000000000000000000000000000000"!!)
Οι ενέργειες που αναφέρονται πρέπει να εκτελούνται με εξαιρετική προσοχή, μια εσφαλμένη ακολουθία είναι γεμάτη με την πλήρη αλειτουργία του RIB. Επομένως, πριν από αυτές τις ενέργειες, η δημιουργία αντιγράφων ασφαλείας είναι ΥΠΟΧΡΕΩΤΙΚΗ!
Διαφορετικά, δεν μπορώ παρά να σου ευχηθώ καλή τύχη!
Τα σφάλματα δυναμικής ενημέρωσης (ή άλλες δυσλειτουργίες πλατφόρμας) μπορεί να είναι οι αιτίες σφαλμάτων ανταλλαγής κατανεμημένων βάσεων πληροφοριών:
"Λαμβάνονται δεδομένα από τον κόμβο για τον οποίο έχουν καταχωρηθεί αλλαγές διαμόρφωσης"
"Η διαμόρφωση κόμβου κατανεμημένου IS δεν είναι η αναμενόμενη"
Πώς να επαναφέρετε την ανταλλαγή;
Αλλά ας ξεκινήσουμε όχι με την αποκατάσταση, αλλά με την ευκαιρία να ξοδέψουμεαλλάξτε το "χειροκίνητα", το οποίο είναι σημαντικό κατά τη διάρκεια της ημέρας, γιατί, όπως πάντα, όλα πρέπει να λειτουργούν "χθες" :) Μπορείτε να το κάνετε αυτό με τη βοήθεια υπέροχων θεραπειών που δεν θυμάμαιNu όπου κατέβασα (συγγραφείς, απαντήστε - θα αφήσω συνδέσμους στον πόρο σας και από το δικό μου, εάν χρειαστεί, θα διαγράψω). Η επεξεργασία καθιστά δυνατή την εκφόρτωση μόνο καταχωρισμένων αλλαγών δεδομένων στη βάση δεδομένων (σύμφωνα με το καθορισμένο σχέδιο ανταλλαγής για έναν συγκεκριμένο κόμβο!) σε XML χωρίς να ξεφορτώνονται οι αλλαγές διαμόρφωσης και εάν τα αντικείμενα διαμόρφωσης δεν έχουν αλλάξει πολύ, τότε υπάρχουν πολύ μεγάλες πιθανότητες φόρτωση αυτών των δεδομένων. Μπορείτε να τα κατεβάσετε από τον σύνδεσμο στο τέλος του άρθρου.
Όσο για την ανάκαμψη. Υπάρχουν απλούστεροι τρόποι που δεν περιλαμβάνουν όλα τα στοιχεία της παρακάτω λίστας, αλλά δεν βοηθούν πάντα, όπως συνέβη σε μια από τις περιπτώσεις μου. Ως εκ τούτου, δίνω τη μέθοδο που με βοήθησε, παρακάμπτει πιθανά προβλήματα πιο ολοκληρωμένα. Περαιτέρω στα βήματα.
Συνιστάται να κάνετε αυτά τα βήματα όταν δεν υπάρχουν χρήστες που να εργάζονται στη βάση δεδομένων. Εάν αυτό δεν είναι δυνατό, τότε θα πρέπει να «τελειώσετε» τη μέθοδο για τον εαυτό σας, και επομένως πρέπει πρώτα να κατανοήσετε τη λογική της.
1. Δημιουργήστε αντίγραφα ασφαλείας παντού.
2. Για πελάτες-διακομιστές: απενεργοποιήστε τις βάσεις δεδομένων μέσω της «διαχείρισης διακομιστή» και συνδεθείτε αμέσως με την εγκατάσταση του αποκλεισμού προγραμματισμένων εργασιών (έτσι θα γίνει επαναφορά της κρυφής μνήμης διακομιστή). Μετά από αυτό, μην ξεχάσετε να μεταφέρετε το αρχείο καταγραφής εγγραφής στον νέο κατάλογο.
3. Σε όλους τους υπολογιστές που χρησιμοποιούνται για ανάκτηση, διαγράψτε τη βάση δεδομένων από τη λίστα των βάσεων δεδομένων εκκίνησης 1C και δημιουργήστε μια νέα (η κρυφή μνήμη του χρήστη θα διαγραφεί)
4. Στο configurator (στην κεντρική βάση δεδομένων) προσθέστε μια νέα σταθερά για να αποθηκεύσετε τις αλλαγές στη conf.
5. Καθαρίστε όλους τους καταλόγους ανταλλαγής.
6. Κάντε εκφορτώσεις σε όλα τα υποκαταστήματα (μέχρι στιγμής μόνο εκφορτώσεις).
7. Προσπαθήστε να ανεβάσετε (μόνο ανεβάστε) τα ληφθέντα δεδομένα σε όλα τα υποκαταστήματα. Είναι φυσικό να αποδεχόμαστε τις αλλαγές του συν.
Αν όλα είναι καλά παντού, πάμε παρακάτω, αν όλα είναι άσχημα, πιστεύουμε ότι μπορεί να βοηθήσει η μεταφόρτωση του .cf από την κεντρική βάση δεδομένων και η ΦΟΡΤΩΣΗ του στον κλάδο (όχι σύγκριση-ένωση). Στον υποτελή κόμβο, θα πρέπει να αποσυνδέσετε τη βάση από το RIB (η επεξεργασία θα βοηθήσει σε αυτό - κάντε λήψη από τον παρακάτω σύνδεσμο). Υπάρχει ένα άρθρο για αυτό το θέμα στο infostart.ru.
8. Ακυρώνουμε την εγγραφή αλλαγών για υποκαταστήματα στην Κεντρική Τράπεζα (άλλωστε έχουμε ήδη λάβει όλες τις αλλαγές παντού). Είναι σημαντικό να το κάνετε σε αυτό το στάδιο, ώστε οι συσσωρευμένες αλλαγές από διαφορετικούς κλάδους να φτάσουν σε άλλους κλάδους. (κατεβάστε την επεξεργασία για unbinding-binding από τον παρακάτω σύνδεσμο).
9. Κάνουμε τη φόρτωση στην Κεντρική Τράπεζα και αν όλα είναι καλά, τότε κάνουμε τη φορτοεκφόρτωση με κάθε υποκατάστημα πολλές φορές για να παγιωθεί το αποτέλεσμα.
10. Τα πάντα.
Μπορείτε να ενεργοποιήσετε την εκτέλεση προγραμματισμένων εργασιών για βάσεις δεδομένων πελάτη-διακομιστή.
Για να αποτρέψετε προβλήματα που προκαλούν αυτό το σφάλμα, συνιστάται να μην κάνετε μια δυναμική ενημέρωση (τουλάχιστον αρκετές φορές στη σειρά - πριν από τη μεταφόρτωση αλλαγών σε υποκαταστήματα) και επίσης συνιστάται να ελέγξετε το πλαίσιο ελέγχου "μεταφόρτωση δεδομένων μόνο μετά την επιτυχή μεταφόρτωση" στις ρυθμίσεις ανταλλαγής.
Για αρχή, εδώ είναι μια λίστα με τις συντομογραφίες που χρησιμοποιώ:
- RIB - κατανεμημένη βάση πληροφοριών
- CB - κεντρική βάση, ριζικός κόμβος RIB
- UB - απομακρυσμένη βάση, βάση δεδομένων του απομακρυσμένου κόμβου RIB
Από τη δική μου εμπειρία, μπορώ να πω ότι αντιμετώπισα δύο λόγους για το σφάλμα:
- κατά την παραλαβή του αρχείου μηνύματος στο UB, η βάση «έπεσε», σε σχέση με την οποία, προφανώς, υπήρξε αποσυγχρονισμός μεταξύ του conf. Κεντρική Τράπεζα και UB·
- στο MSSQL, ο πελάτης φόρτωσε ένα αντίγραφο της βάσης δεδομένων εργασίας και δεν το απενεργοποίησε στο αντίγραφο του reg. εργασίες αυτόματης ανταλλαγής, ως αποτέλεσμα, μέρος των μηνυμάτων σε απομακρυσμένους κόμβους σχηματίστηκε από τη βάση δεδομένων εργασίας και μέρος από το αντίγραφο, το οποίο οδήγησε στον αποσυγχρονισμό των διαμορφώσεων
Υπάρχει επίσης η άποψη ότι η χρήση του μηχανισμού ενημέρωσης δυναμικής βάσης δεδομένων οδηγεί σε αυτό το σφάλμα. Υπάρχουν αμφιβολίες εδώ, επειδή αφενός, η δυναμική ενημέρωση δεν επηρεάζει ποτέ τη δομή της βάσης δεδομένων και οι μηχανισμοί RIB εξακολουθούν να λειτουργούν με τη δομή της βάσης δεδομένων και όχι με το τμήμα εφαρμογής της, ωστόσο, το RIB χρησιμοποιεί τον μηχανισμό για τη δημιουργία ψηφιακής υπογραφής την έκδοση διαμόρφωσης (θα την ονομάσω συνοπτικά κατακερματισμό) και όταν αλλάξει το τμήμα της εφαρμογής, ο κατακερματισμός πρέπει φυσικά να επανυπολογιστεί. Δεν θα το αρνηθώ, ούτε θα το επιβεβαιώσω, γιατί. αν αντιμετώπιζα αυτή την κατάσταση, τότε δεν βρήκα σαφείς αποδείξεις γι' αυτό.
Χρησιμοποιώ 2 μεθόδους για να το διορθώσω, ανάλογα με την περίσταση.
ΠΡΩΤΗ ΜΕΘΟΔΟΣ
Το πρώτο (το πιο κοινό) αναφέρεται επανειλημμένα τόσο στη διάσκεψη συνεργατών όσο και σε άλλους πόρους του Διαδικτύου που σχετίζονται με το 1C. Χρησιμοποιείται στις περισσότερες περιπτώσεις, όταν παρά το μήνυμα για τις αποκλίσεις των διαμορφώσεων, όταν συγκρίνονται χειροκίνητα, φαίνεται ότι είναι πανομοιότυπες.
Αλληλουχία:
- ξεφορτώστε το αρχείο cf από την Κεντρική Τράπεζα.
- αποσυνδέουμε το UB από το RIB (η μέθοδος SetMainNode, η έτοιμη επεξεργασία μπορεί να βρεθεί στην εφαρμογή ή σε άλλες δημοσιεύσεις).
- αντικαταστήστε conf. UB στο αρχείο cf που εκφορτώθηκε στο πρώτο βήμα, για αυτό χρησιμοποιούμε το μενού "Φόρτωση διαμόρφωσης από αρχείο" (και όχι με σύγκριση-ένωση !!!).
- ας επαναφέρουμε το σήμα του RIB για το UB.
Στις περισσότερες περιπτώσεις, αυτές οι ενέργειες είναι υπεραρκετές για την αποκατάσταση της ανταλλαγής, αλλά όχι πάντα...
ΔΕΥΤΕΡΗ ΜΕΘΟΔΟΣ
Χρησιμοποιείται εάν η πρώτη μέθοδος δεν λειτούργησε και δεν είναι δυνατή η εκ νέου εκφόρτωση του κόμβου.
Ιστορικό: ο πελάτης έφτιαχνε ένα διαδοχικό RIB και παρουσιάστηκε ένα σφάλμα στο πρώτο επίπεδο του καταρράκτη (το δεύτερο επίπεδο λειτουργούσε άψογα όλο αυτό το διάστημα). Η διαμόρφωση αναπτύχθηκε από κοινού με την υπηρεσία IT του πελάτη και από τότε που παρουσιάστηκε το σφάλμα, η διαμόρφωση CB έχει αλλάξει αρκετές φορές. Η επιλογή επαναφοράς των αλλαγών δεν εξετάστηκε καν κατ' αρχήν, γιατί η απώλεια μέρους των δεδομένων και το κλείσιμο πολλών τμημάτων ήταν εντελώς απαράδεκτα. Η πρώτη έκδοση της διόρθωσης σφάλματος δεν έδωσε απτά αποτελέσματα. Ως αποτέλεσμα, έπρεπε να βρεθούν άλλες λύσεις.
Η ιδέα ήρθε να προσπαθήσουμε να αλλάξουμε τους κατακερματισμούς των αρχείων διαμόρφωσης απευθείας στα αρχεία XML της ανταλλαγής. Η περιγραφή της δομής του αρχείου ανταλλαγής από το βιβλίο "Επαγγελματική ανάπτυξη στο σύστημα 1C:Enterprise 8" έδωσε μια κακή ιδέα για το σχηματισμό ψηφιακών υπογραφών των διαμορφώσεων και τις αλλαγές σε αυτές, αλλά καθόρισε την κατεύθυνση αναζήτησης: Digest1 και Digest2 τιμές. Όλα τα άλλα τα κατάλαβα καθαρά εμπειρικά (δηλαδή με δοκιμή και λάθος), αλλά κατάφερα να δημιουργήσω ένα μοτίβο.
Τα πειράματα δοκιμής πήγαν καλά. Και στις βάσεις όλα πήγαν καλά.
Έτσι, η σειρά των ενεργειών:
- εκτελέστε τα βήματα 1 - 4 της πρώτης τεχνικής.
- ξεφορτώστε το αρχείο ανταλλαγής από το UB, αλλά μην το ανεβάσετε στο CB.
- ξεφορτώστε το αρχείο ανταλλαγής από την Κεντρική Τράπεζα, αλλά μην το ανεβάσετε στο UB.
- στο αρχείο ανταλλαγής από το CB, αντικαθιστούμε το μπλοκ που περιέχει πληροφορίες σχετικά με αλλαγές διαμόρφωσης και κατακερματισμούς (Digest1 και Digest2) με ένα μπλοκ κατακερματισμών από το αρχείο UB (δείτε ένα παράδειγμα παρακάτω)
- ανεβάζουμε το αρχείο από το 4ο σημείο στο UB.
- φροντίστε να αντικαταστήσετε το αρχείο ανταλλαγής από το UB (2η παράγραφος)! αυτό το αρχείο δεν πρέπει να φορτώνεται κατά την ανταλλαγή στο CB!
- για έλεγχο, κάνουμε πολλές διαδοχικές ανταλλαγές.
Εάν χρησιμοποιείται συμπίεση δεδομένων κατά τη διάρκεια της ανταλλαγής, τότε είτε απενεργοποιήστε τη συμπίεση ή πρώτα αποσυσκευάστε το αρχείο, αλλάξτε το, μετά συσκευάστε το ξανά και στείλτε το.
Αποκλεισμός ανταλλαγής αρχείων από το CB
...ακολουθούν μπλοκ που περιγράφουν τις αλλαγές διαμόρφωσης...
Πρέπει να αντικατασταθεί με ένα μπλοκ του αρχείου ανταλλαγής από το UB (σημείωση digest1 του αρχείου από το UB είναι πάντα "000000000000000000000000000000" !!!)
Οι ενέργειες που αναφέρονται πρέπει να εκτελούνται με εξαιρετική προσοχή, μια εσφαλμένη ακολουθία είναι γεμάτη με την πλήρη αλειτουργία του 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.
Η απόχρωση είναι η εξής: παρεμβολές με κόμβους ενημέρωσης παρατηρούνται σε εκείνες τις βάσεις που δημιουργήθηκαν από την κεντρική ακριβώς στην έκδοση 2.1.9.18. Όλα όσα δημιουργήθηκαν σε προηγούμενες εκδόσεις ενημερώθηκαν κανονικά. Αυτό, πιθανώς, εξηγεί γιατί μερικές βάσεις για το TS ενημερώθηκαν επίσης με επιτυχία, και μετά πήγαν τα τζάμπες.
Δεν επινόησα τίποτα με τη δημιουργία ενός νέου στοιχείου στον κατάλογο και τη ρύθμιση του ως προκαθορισμένου. Μεταφέρθηκε αυτό το στοιχείο από το αντίγραφο του κέντρου στο 2.1 μέσω εκφόρτωσης/φόρτωσης XML και επανέλαβε την ενημέρωση στην προβληματική "βάση" - όλα πήγαν καλά.
() Χρησιμοποιήστε λοιπόν τη μέθοδο εάν δεν έχετε βρει ακόμα την απάντηση.
Ερώτηση: Σφάλμα ενημέρωσης διαμόρφωσης
Ενημερώνω τη διαμόρφωση του Accounting 2.0.64.14 σε 2.0.64.24. πλατφόρμα 8.2.19
Εμφανίζεται ένα σφάλμα αμέσως:
Σφάλμα κατά την πρόσβαση στο αρχείο... διαδρομή... προσωρινό αρχείο.tmp.
Πού να κοιτάξουμε;
Απάντηση:έλυσε αυτό το πρόβλημα περιμένοντας μια νέα "σταθερή" κυκλοφορία
Ερώτηση: Σφάλμα στα δικαιώματα χρήστη στο BSP
Χαιρετίσματα!!! Γράφω ένα conf που βασίζεται στο BSP 2.2, φαίνεται ότι έχω ήδη εμπειρία και έχω μελετήσει τα docks πάνω κάτω, αλλά την πρώτη φορά που ξεκινάω το 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 Serializer (XDTO Factory);
Συνδρομητής = NewXDTOSerializer.ReadXDTO(xdtoSubscriber);
Notification=New Deliverable Notification;
Notification.Recipients.Add(Subscriber);
Notification.Text=Κείμενο;
Notification.SoundAlert=SoundAlert.Default;
Notice.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notification,AuzData,True);
Τώρα το σφάλμα είναι η επικύρωση απομακρυσμένου κεντρικού υπολογιστή απέτυχε. Έσπασε όλο μου το κεφάλι. Έπιασα κλήσεις διακομιστή - αισθάνεται άδειο που δεν γυρίζει πουθενά ... Δοκίμασα σε τρία διαφορετικά μηχανήματα με διαφορετικούς άξονες. εξαντλημένος... βοήθεια...
Απάντηση:Πάνω
Απάντηση:Έτσι, αποφάσισα να φτιάξω ξανά την εικόνα του κόμβου. Κατά την εκκίνηση του κόμβου, λέει ότι πρέπει να ξεκινήσει με \c για να ξεκινήσει η ενημέρωση της βάσης πληροφοριών
και εκ νέου εικόνα.
Αποδεικνύεται ότι αυτό είναι κάτι λόγω μιας λανθασμένης ενημέρωσης.
Προσπάθησα να τρέξω με αυτό το κλειδί και να κάνω μια ανταλλαγή με έναν υπάρχοντα κόμβο. Δεν έγιναν ενημερώσεις στον κόμβο, δεν ζητήθηκε να γίνει επανεκκίνηση.
Και ως αποτέλεσμα, στον κύριο κόμβο, το μήνυμα δεν έγινε ξανά αποδεκτό με το ίδιο σφάλμα.
Τί μπορεί να γίνει?
Μπορεί να αλλάξει κάτι πλασματικό στον κύριο κόμβο στο conf και να κάνει ανταλλαγή; Ή δεν θα ενημερώσει ολόκληρο το conf, αλλά μόνο αυτό που θα αλλάξω; Θα προσπαθήσω να κάνω έναν κόμπο προς το παρόν. Θα περιμένω όμως τις ιδέες σας.
Ερώτηση: Κατανεμημένη βάση δεδομένων - το σφάλμα κατά την ανταλλαγή δεν εξαλείφεται
Καλημέρα σε όλους!
Η κατάσταση είναι η εξής.
Κατά τη φόρτωση μιας ανταλλαγής από έναν περιφερειακό κόμβο, λαμβάνω το μήνυμα "Η διαμόρφωση του κατανεμημένου κόμβου IS δεν ταιριάζει με την αναμενόμενη".
Μετά ακολουθώ τις οδηγίες.
Ξεφορτώνω τη διαμόρφωση από την κεντρική βάση δεδομένων στο CF, αποσυνδέω την περιφερειακή βάση δεδομένων από τον κεντρικό κόμβο μέσω επεξεργασίας, αφαιρώ τη διαμόρφωση στην περιφερειακή βάση δεδομένων από την υποστήριξη, φορτώνω τη διαμόρφωση από ένα αρχείο.
Δεσμεύω τον κεντρικό κόμβο στην περιφερειακή βάση δεδομένων με επεξεργασία.
Αποθήκευση, εφαρμογή.
Ξεφορτώνω για άλλη μια φορά την ανταλλαγή από την κεντρική βάση δεδομένων.
Φορτώνω στο περιφερειακό. Ξεφορτώνω την ανταλλαγή από την περιφερειακή βάση δεδομένων.
Μεταφόρτωση στο κεντρικό. Παίρνω πάλι το μήνυμα "Η διαμόρφωση του κατανεμημένου κόμβου IS δεν ταιριάζει με το αναμενόμενο".
Αλλά αυτό είναι μια πραγματική ανοησία - φορτώνω τη διαμόρφωση στην κεντρική βάση δεδομένων και κανείς δεν άλλαξε τη ρύθμιση παραμέτρων στην περιφερειακή βάση δεδομένων.
Πώς να ξεπεράσετε ένα τέτοιο σφάλμα;
Απάντηση:Δεν πέρασε ποτέ από το μυαλό κανένας να συμβουλέψει τόσο προφανή πράγματα μετά από πολλά χρόνια βρισιάς στη δαιμονική ενημέρωση :)
Ερώτηση: RIB και ενημερώσεις
Γεια σε όλους. Σχεδιάζεται να χρησιμοποιηθεί ασφάλεια κατανεμημένων πληροφοριών.
η διαμόρφωση άλλαξε. Η ενημέρωση της διαμόρφωσης της κεντρικής βάσης δεδομένων πραγματοποιείται από τον προγραμματιστή. Στη συνέχεια, με τα αρχεία ανταλλαγής, αυτές οι αλλαγές θα μεταφερθούν σε περιφερειακές βάσεις δεδομένων.
Το ερώτημα είναι: τι γίνεται με την εκκίνηση των χειριστών μετά την ενημέρωση της διαμόρφωσης της βάσης δεδομένων και την πρώτη σύνδεση σε λειτουργία χρήστη;
ενημέρωση κύριας διαμόρφωσης - ενημέρωση διαμόρφωσης βάσης δεδομένων - εκτέλεση χειριστών ενημέρωσης σε λειτουργία χρήστη
Για παράδειγμα, χάθηκαν πολλές εκδόσεις, πρέπει να κάνετε διαδοχική αναβάθμιση για να κάνετε αναβάθμιση σε 3 εκδόσεις. Δεν υπάρχουν προβλήματα με την ενημέρωση της κεντρικής βάσης δεδομένων, αλλά τι γίνεται με τις περιφερειακές; Είναι επίσης απαραίτητο να τα ενημερώσετε σε 3 στάδια (ενημέρωση της κεντρικής βάσης δεδομένων με την πρώτη έκδοση, ενημέρωση του RIB, ενημέρωση της κεντρικής βάσης δεδομένων με τη δεύτερη έκδοση, ενημέρωση του RIB κ.λπ.;)
Σας ευχαριστώ όλους για τη βοήθειά σας!
Απάντηση:() τρυπήστε τη μύτη σας, δεν μπορώ να βρω τον κώδικα που εκτελείται κατά την εγγραφή αλλαγών αντικειμένων.
Φαίνεται ότι εάν χρησιμοποιείτε τη μέθοδο OnSendingData, τότε ο κύριος κόμβος θα εξακολουθεί να συγκεντρώνει αλλαγμένα αντικείμενα για αποστολή στον υποτελή κόμβο. Και αυτοί είναι επιπλέον πόροι υπολογιστή
Επομένως, θέλω τα αντικείμενα στον κύριο κόμβο να μην καταχωρούνται για αποστολή αμέσως τη στιγμή της αλλαγής τους (On Write, για παράδειγμα). Σε ποιο σημείο, για παράδειγμα, στην τυπική Λογιστική αναθ. 3, καταχωρούνται αυτά τα αντικείμενα για αποστολή;
Ερώτηση: [ΕΠΙΛΥΘΗΚΕ] Σφάλμα επικοινωνίας με την ηλεκτρονική υποστήριξη
Αγαπητοί ειδικοί, πείτε μου, σας παρακαλώ!
1C:Enterprise 8.3 (8.3.11.2899)
Πολλές βάσεις δεδομένων διαφορετικών διαμορφώσεων περιστρέφονται στον διακομιστή 1C, σε όλες η υποστήριξη Διαδικτύου είναι συνδεδεμένη και λειτουργεί καλά. Συμπ. φόρτωση συναλλαγματικών ισοτιμιών, τραπεζών, αντισυμβαλλομένων ελέγχου, SPARK κ.λπ.
Οι ρυθμίσεις διακομιστή μεσολάβησης είναι ίδιες για όλες τις βάσεις δεδομένων.
Αλλά στις βάσεις δεδομένων BP-3 CORP, εμφανίζεται πάντα ένα σφάλμα:Στο αρχείο καταγραφής εγγραφής:
Αποτυχία λήψης εισιτηρίου ελέγχου ταυτότητας στην υπηρεσία.
Απέτυχε η φόρτωση του περιεχομένου(). (GeneralModule.InternetUserSupportClientServer.Module(362)): Σφάλμα κατά την κλήση της μεθόδου περιβάλλοντος (SendToProcess)
Response = 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, η επαλήθευση πιστοποιητικού στα παράθυρα πραγματοποιείται χρησιμοποιώντας λειτουργικό σύστημα." -
Εγκαταστήστε τις πιο πρόσφατες ενημερώσεις για το λειτουργικό σας σύστημα, Περιέχουν σημαντικές ενημερώσεις εξαρτήματα συστήματος, τα οποία είναι υπεύθυνα για την εργασία με πιστοποιητικά.
Εγκαταστήστε επίσης ΤΕΛΕΥΤΑΙΑ ΑΝΑΒΑΘΜΙΣΗπιστοποιητικά ρίζας που διανέμονται από τη 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();
εξαιτίας:
Βρέθηκαν περισσότερα από ένα ρεκόρ».Η αξιότιμη πλατφόρμα εγγραφής δεν μπορεί να δοκιμαστεί σε διαφορετικές εκδόσεις πλατφορμών
προσπάθησε να πάρει μια καθαρή συνδιάλεξη τελευταία έκδοσηκαι μόλις ανόητα ολοκληρώθηκε η αντικατάσταση στη φόρτωση
δεν βοήθησε καθόλου, πάντα το ίδιο πράγμα. Πες μου ξαφνικά ποιος συνάντησε;
Απάντηση:
κόμβος από true σε false
Φόρτωση...