Έχει γίνει υπέρβαση του μεγέθους του εσωτερικού αρχείου 1c. Σφάλμα DB "Έχει ξεπεραστεί το μέγιστο επιτρεπόμενο μέγεθος εσωτερικού αρχείου"

Όταν χρησιμοποιείτε την έκδοση αρχείου των βάσεων πληροφοριών, εμφανίζεται συχνά το σφάλμα "Υπέρβαση μέγιστου ορίου". επιτρεπόμενο μέγεθος εσωτερικό αρχείο», συνδέεται πρωτίστως με τις ιδιαιτερότητες της υλοποίησης του λειτουργία αρχείου. Περιέχει 4 αρχεία:

• Αρχείο περιγραφής δομής πίνακα
• Αρχείο ευρετηρίου (μεταφέρθηκε από το κύριο αρχείο)
• Αρχείο τιμών
• Αρχείο καταγραφής

Ισχύουν επίσης περιορισμοί, όπως: μέγιστο μέγεθοςτο εσωτερικό αρχείο δεν πρέπει να υπερβαίνει τα 4 GB, το μήκος του κλειδιού στο ευρετήριο δεν πρέπει να υπερβαίνει τα 1920 byte και τέλος, ο αριθμός των πεδίων για ευρετηρίαση δεν πρέπει να υπερβαίνει τα 256 πεδία. Το πιο σημαντικό πράγμα για εμάς είναι το όριο μεγέθους αρχείου των 4 GB. Πώς μπορεί να είναι αυτό; λες. Υπάρχουν αρχεία βάσης δεδομένων 10 και 12 GB. Ναι, αυτό είναι σωστό - αυτό σημαίνει ότι κανένα από τα εσωτερικά αρχεία δεν ξεπέρασε τα 4 GB. Τολμώ να σε απογοητεύσω. Ωστόσο, το μέγιστο μέγεθος της βάσης δεδομένων, το ίδιο το αρχείο 1Cv8.CD, εξακολουθεί να περιορίζεται στα 16 GB από προεπιλογή (αλλά ακόμα και αυτό μπορεί να παρακαμφθεί), καθώς πρόκειται για περιορισμό διεύθυνσης καταγραφής σύστημα αρχείων NTFS (τα αρχεία 16 GB δεν αντιγράφονται στα Windows, επειδή εάν η ανάγνωση/εγγραφή αποτύχει σε ένα τμήμα που είναι μεγαλύτερο από αυτά τα 16 GB, το λειτουργικό σύστημα δεν μπορεί να ελέγξει την ακεραιότητα του συστήματος αρχείων.)

Για να λύσετε αυτό το πρόβλημα, πρέπει να υπολογίσετε ποιο τραπέζι καταλαμβάνει πολύ χώρο. Για να το κάνετε αυτό, μπορείτε να χρησιμοποιήσετε λογισμικό τρίτων κατασκευαστών Tool_1CD, το οποίο σας επιτρέπει να κοιτάξετε μέσα στο αρχείο 1Cv8.CD, δηλαδή να προσδιορίσετε το μέγεθος των πινάκων, να μεταφορτώσετε στο Μορφή XMLκαι πολλά άλλα.

Για να το λύσετε, πρέπει να μειώσετε το μέγεθος αυτού του ίδιου του πίνακα ή να τον μετατρέψετε σε έκδοση SQL. Πώς να αγοράσετε λοιπόν Διακομιστής SQLΕίναι αρκετά ακριβό, αναζητούμε αυτόν τον πίνακα εμπειρικά. Συνήθως πρόκειται για «βαριά έγγραφα» με μεγάλο μέρος σε πίνακα, ογκώδεις καταλόγους, ιδιαίτερα συχνά μητρώα συσσώρευσης. Πρώτα απ 'όλα, αφαιρέστε όλα τα στοιχεία που έχουν επισημανθεί για διαγραφή από τη βάση δεδομένων. Στη συνέχεια, υπολογίστε ξανά τα σύνολα (αν υπάρχει πρόβλημα στο μητρώο συσσώρευσης, τότε μερικές φορές βοηθάει). Τα μητρώα υπολοίπων ενδέχεται να έχουν κλείσει εσφαλμένα, γεγονός που οδηγεί σε απότομη αύξηση των συνολικών πινάκων. Η διαγραφή «κολλημένων» υπολοίπων μπορεί να ελευθερώσει έως και αρκετά GB.

Συμβαίνει ότι όλοι οι πίνακες είναι μικρότεροι από 4 GB, αλλά το σφάλμα εξακολουθεί να εμφανίζεται. Αυτή η κατάστασηπολύ πιο δύσκολο. Εδώ βρίσκεται το πρόβλημα στη δομή των matdata της διαμόρφωσης, δηλαδή στην ευρετηρίαση. Κατά τη φόρτωση της βάσης πληροφοριών από το αρχείο dt, φορτώνονται πρώτα τα δεδομένα όλων των πινάκων και μετά τα ευρετήρια. Σε κάποιο σημείο κατά τη δημιουργία ευρετηρίου, παρουσιάζεται ένα σφάλμα και δεν δημιουργούνται επόμενα ευρετήρια, γεγονός που σταματά τη φόρτωση και προκαλεί σφάλμα. Για να μάθετε ποιος πίνακας αποτυγχάνει κατά τη δημιουργία ενός ευρετηρίου, κάντε τα εξής:

• Ενεργοποιήστε το περιοδικό τεχνολογίας
• Δημιουργούμε κενό αρχείο ogcfg.xml με το ακόλουθο περιεχόμενο για παράδειγμα

και βάλτε το στον κατάλογο conf, για παράδειγμα C:\Program Files\1cv82\8.2.19.130\bin\conf

• ελέγχουμε ότι έχουν δημιουργηθεί τα αρχεία καταγραφής και τα αρχεία και επανεκκινούμε το πρόγραμμα διαμόρφωσης και ξεκινάμε ξανά τη λήψη. αφού παρουσιαστεί ένα σφάλμα, μεταβείτε στο αρχείο καταγραφήςστον φάκελο μας C:\log\error, ανοίξτε τον και αναζητήστε σε ποιο ευρετήριο εμφανίστηκε το σφάλμα.
• Στη συνέχεια, χρησιμοποιώντας το πρόγραμμα Database Table Storage Structure, αναζητούμε το ίδιο το αντικείμενο μεταδεδομένων.
• Λοιπόν, τότε αναζητούμε εμπειρικά είτε τα μακρά χαρακτηριστικά αυτού του αντικειμένου είτε την ιδιότητα που οδηγεί στην αποτυχία της κατασκευής του ευρετηρίου και συνεχίζουμε να προσπαθούμε, να προσπαθούμε και να προσπαθούμε μέχρι να καταλήξουμε σε μια λύση.
• Μετά από επιτυχημένους χειρισμούς ξεκινάμε τη δοκιμή και τη διόρθωση. Ως αποτέλεσμα, όλα τα ευρετήρια θα αναδημιουργηθούν και η βάση δεδομένων θα είναι πλήρως λειτουργική. Καλή τύχη!

Ας υποθέσουμε ότι έχετε δημιουργήσει ένα αρχείο βάσης δεδομένων και τώρα προσπαθείτε να το κατεβάσετε ως αρχείο. Στην αρχή όλα πάνε καλά, αλλά κάποια στιγμή εμφανίζεται ένα σφάλμα:

"Σφάλμα κατά τη φόρτωση της βάσης πληροφοριών. Δεν φορτώθηκαν όλα τα δεδομένα στη βάση πληροφοριών λόγω: Σφάλμα DBMS: Έχει γίνει υπέρβαση του μέγιστου επιτρεπόμενου μεγέθους εσωτερικού αρχείου"D:\1CBASES\NewDB/1Cv8.1CD" "

Προσωπικά αφιέρωσα πολύ χρόνο ψάχνοντας για μια λύση σε αυτό το πρόβλημα και τελικά τη βρήκα, κάτι που μας επέτρεψε να δημιουργήσουμε ένα αντίγραφο αρχείου της βάσης δεδομένων μεγέθους 18 GB και τελικά εξοικονομήσαμε περίπου μια εβδομάδα χρόνου (μπορώ να σας πω στο σχολιάζει πώς ήταν, αλλά τώρα δεν μιλάμε για όγκο).

Έτσι, μπορεί να υπάρχουν διάφοροι λόγοι για αυτό το σφάλμα:

1. Το μέγεθος οποιουδήποτε πίνακα στη βάση δεδομένων υπερβαίνει το όριο μεγέθους για έκδοση αρχείου(4 GB). Για να είμαστε ειλικρινείς, για να αποφύγουμε τέτοιες υπερβολές, ελέγξαμε εκ των προτέρων τα μεγέθη των πινάκων της βάσης δεδομένων χρησιμοποιώντας " " επεξεργασία (ή ανάλογα).
2. Το σφάλμα σχετίζεται με ένα σφάλμα στις δυνατότητες της πλατφόρμας και προκαλείται από μια συγκεκριμένη δομή των μεταδεδομένων της μεταφορτωμένης διαμόρφωσης.

Στην πρώτη περίπτωση, όλα είναι ξεκάθαρα - εάν ο μετρητής βάσης δείχνει ότι το όριο έχει ξεπεραστεί για ορισμένους από τους πίνακες της βάσης δεδομένων, τότε αυτοί οι πίνακες πρέπει να καθαριστούν. Αν μιλάμε γιασχετικά με έναν κατάλογο ή μη περιοδικό μητρώο πληροφοριών, τότε πρέπει να προσπαθήσετε να αφαιρέσετε τα περιττά στοιχεία/εγγραφές από εκεί. Το ίδιο ισχύει για τα «βαριά» έγγραφα με τα μέρη τους σε πίνακα. Το πρώτο πράγμα που πρέπει να κάνετε είναι να αφαιρέσετε τα επισημασμένα αντικείμενα, φυσικά.

Μητρώα συσσώρευσης - ξεχωριστό θέμα. Το μέγεθος των συνολικών πινάκων μπορεί να υπερβαίνει το μέγεθος των πινάκων καταχώρισης του μητρώου, συχνά σημαντικά. Μερικές φορές ακόμη και ένας απλός επανυπολογισμός των αποτελεσμάτων μπορεί να βοηθήσει.

Τα μητρώα υπολοίπων ενδέχεται να έχουν κλείσει εσφαλμένα (όχι για όλες τις διαστάσεις), γεγονός που οδηγεί σε ΠΟΛΥ σημαντική και ταχεία αύξηση των συνόλων πινάκων. Η διαγραφή των «κολλημένων» υπολοίπων του μητρώου συσσώρευσης μπορεί, κατά τον επόμενο επανυπολογισμό των συνόλων, να δώσει εξοικονόμηση έως και πολλών GB, δοκιμασμένη για δική σας εμπειρίααπό "απρόσεκτους" πελάτες.))

Τι πρέπει να κάνετε εάν κάθε πίνακας στη βάση δεδομένων σας έχει μέγεθος μικρότερο από 4 GB, αλλά το σφάλμα εξακολουθεί να εμφανίζεται;

Αυτό σημαίνει ότι έχετε τη δεύτερη περίπτωση - μια προβληματική δομή μεταδεδομένων διαμόρφωσης. Πιθανότατα, το σφάλμα παρουσιάζεται στο στάδιο δημιουργίας ευρετηρίου.

Με λίγα λόγια, θα περιγράψω την κατάσταση στο σύνολό της, ώστε να είναι ξεκάθαρη, σύμφωνα με τα λόγια του Viktor Sosnovsky από το 1C. Παρακάτω είναι ένα απόσπασμα από ένα φόρουμ συνεργατών:

"Κατά τη φόρτωση μιας βάσης πληροφοριών στην έκδοση αρχείου, πρώτα φορτώνονται τα δεδομένα όλων των πινάκων και στη συνέχεια δημιουργούνται ευρετήρια. Ένα σφάλμα στη δημιουργία ενός ευρετηρίου οδηγεί στο γεγονός ότι το ευρετήριο που δημιουργήθηκε με ένα σφάλμα και όλα τα επόμενα ευρετήρια δεν δημιουργούνται. Εάν υπάρχουν πολλά δεδομένα στη βάση δεδομένων, αυτό θα οδηγήσει σε σημαντική μείωση της παραγωγικότητας. Πλήρης απασχόλησημε μια τέτοια βάση θα είναι αδύνατο».

Πρέπει να μάθετε ποιος πίνακας προκαλεί το σφάλμα κατά τη δημιουργία του ευρετηρίου.

Συμπεριλάβετε το τεχνολογικό περιοδικό - στον φάκελο " C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\(ή παρόμοια __PlatformVersionNumber__εισάγετε το δικό σας) βάλτε το αρχείο logcfg.xmlπερίπου ως εξής:

Διασφαλίζουμε προσεκτικά ότι οι κατάλογοι για χωματερές και αρχεία καταγραφής είναι:

1. Υπήρχαν
2. Διαφορετικά
3. Ήταν ευανάγνωστα και εγγράψιμα χρήστης των Windows, για λογαριασμό του οποίου εκτελείτε το πρόγραμμα διαμόρφωσης.

Κάνουμε επανεκκίνηση του διαμορφωτή (αυτό ενεργοποιεί το τεχνολογικό αρχείο καταγραφής) και προσπαθούμε να φορτώσουμε ξανά το .DT μας.Αφού παρουσιαστεί ένα σφάλμα, πηγαίνουμε στον κατάλογο καταγραφής, βρίσκουμε εκεί το αρχείο καταγραφής που περιέχει το σφάλμα μας και το διαβάζουμε προσεκτικά.

Η πρώτη κιόλας εμφάνιση του EXCPCNTX στο αρχείο καταγραφής στην περίπτωσή μου έδειξε την εντολή που προκάλεσε το σφάλμα: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR(το όνομα του ευρετηρίου σας θα είναι διαφορετικό).

Χρησιμοποιώντας τους αριθμούς από το όνομα του ευρετηρίου, χρησιμοποιώντας " " επεξεργασία (ή ανάλογα που μπορούν να εμφανίζουν ευρετήρια), βρίσκουμε σε ποιον πίνακα ανήκει αυτό το ευρετήριο. Για μένα αποδείχθηκε ότι ήταν ένας πίνακας περιστροφών ενός από τους μη τυπικούς καταχωρητές συσσώρευσης.

Πρώτα απ 'όλα, θα πρέπει να εξετάσετε ποια πεδία περιλαμβάνονται στο ευρετήριο. Όπως αποδεικνύεται, στην πλατφόρμα ΠΡΑΓΜΑΤΙΚΑ δεν αρέσει όταν το συνολικό μέγεθος των βασικών πεδίων ευρετηρίου γίνεται σημαντικό. Συγκεκριμένα, δεν της αρέσει η ευρετηρίαση μακριές ουρές- έτσι, στην περίπτωσή μου, μια ιδιότητα με τύπο STRING (500) μπήκε στο ευρετήριο και προκάλεσε σφάλμα. Ένας άλλος εκπρόσωπος της εταιρείας 1C μίλησε σε ένα φόρουμ συνεργατών το 2007:

"Εάν το μήκος του κλειδιού αποδειχθεί ότι είναι κοντά στα 2K, τότε αρχίζει μια απότομη αύξηση του μεγέθους των δεικτών με μια σειρά από δυσάρεστες συνέπειες."

Και πράγματι, τίποτα δεν έχει αλλάξει το 2013 - μέσα παρόμοιες περιπτώσειςυπάρχει μια χιονοστιβάδα αύξηση στο μέγεθος του δείκτη κατά βάση δεδομένων αρχείων. Και όταν ο πίνακας ευρετηρίου υπερβαίνει το όριο των 4 GB, το loading.DT σταματά με ένα σφάλμα.

Προσωπικά, με βοήθησε να απενεργοποιήσω το πλαίσιο ελέγχου "Χρήση σε σύνολα" για την προβληματική ιδιότητα, επειδή Στην πραγματικότητα, δεν απαιτήθηκαν αποτελέσματα. Δεν εμφανίζεται πλέον στον ίδιο τον πίνακα περιστροφών και, ως εκ τούτου, στο ευρετήριο του πίνακα περιστροφών. Υπάρχουν και άλλοι τρόποι - για να περιορίσετε πιο αυστηρά το μέγεθος της γραμμής, για παράδειγμα. Διάβασα ότι βοήθησε κάποιους.

Αυτές οι αλλαγές πρέπει να εφαρμοστούν βάση πληροφοριών, αυτό θα αναδιαρθρώσει το τραπέζι σας.

Εάν γίνουν αλλαγές στα αντίγραφα SQL της βάσης δεδομένων, τότε μετά από αυτό θα πρέπει να επαναφορτώσετε το .DT και να προσπαθήσετε να το φορτώσετε ξανά στην έκδοση αρχείου.

Εάν το αντίγραφο SQL δεν είναι διαθέσιμο, τότε μπορείτε να προσπαθήσετε να το διορθώσετε απευθείας στο υποφορτωμένο αντίγραφο του αρχείου σας. Αφού αποδεχτείτε τις αλλαγές, εκτελέστε το "Test and Fix" σε λειτουργία αναδιάρθρωσης πίνακα βάσης δεδομένων. Τα ευρετήρια θα δημιουργηθούν εκ νέου από την πλατφόρμα και, ελπίζουμε, χωρίς σφάλματα.

Όσοι είναι ιδιαίτερα άτυχοι και το σφάλμα εμφανίζεται ξανά θα πρέπει πρώτα να επαναλάβουν ολόκληρη τη διαδικασία, ξεκινώντας με την ανάλυση των αρχείων καταγραφής. Ίσως υπήρχαν περισσότεροι από ένας προβληματικοί πίνακες ή δεν μπορέσατε να λύσετε το πρόβλημα με τα μεγέθη των πεδίων που περιλαμβάνονται στο ευρετήριο.

Ας υποθέσουμε ότι έχετε δημιουργήσει ένα αρχείο βάσης δεδομένων και τώρα προσπαθείτε να το κατεβάσετε ως αρχείο. Στην αρχή όλα πάνε καλά, αλλά κάποια στιγμή εμφανίζεται ένα σφάλμα:

"Σφάλμα κατά τη φόρτωση της βάσης πληροφοριών. Δεν φορτώθηκαν όλα τα δεδομένα στη βάση πληροφοριών λόγω: Σφάλμα DBMS: Έχει γίνει υπέρβαση του μέγιστου επιτρεπόμενου μεγέθους εσωτερικού αρχείου"D:\1CBASES\NewDB/1Cv8.1CD" "

Προσωπικά αφιέρωσα πολύ χρόνο ψάχνοντας για μια λύση σε αυτό το πρόβλημα και τελικά τη βρήκα, κάτι που μας επέτρεψε να δημιουργήσουμε ένα αντίγραφο αρχείου της βάσης δεδομένων μεγέθους 18 GB και τελικά εξοικονομήσαμε περίπου μια εβδομάδα χρόνου (μπορώ να σας πω στο σχολιάζει πώς ήταν, αλλά τώρα δεν μιλάμε για όγκο).

Έτσι, μπορεί να υπάρχουν διάφοροι λόγοι για αυτό το σφάλμα:

1. Το μέγεθος ΟΠΟΙΟΥΔΗΠΟΤΕ πίνακα στη βάση δεδομένων υπερβαίνει το όριο έκδοσης αρχείου (4 GB). Για να είμαστε ειλικρινείς, για να αποφύγουμε τέτοιες υπερβολές, ελέγξαμε εκ των προτέρων τα μεγέθη των πινάκων της βάσης δεδομένων χρησιμοποιώντας " " επεξεργασία (ή ανάλογα).
2. Το σφάλμα σχετίζεται με ένα σφάλμα στις δυνατότητες της πλατφόρμας και προκαλείται από μια συγκεκριμένη δομή των μεταδεδομένων της μεταφορτωμένης διαμόρφωσης.

Στην πρώτη περίπτωση, όλα είναι ξεκάθαρα - εάν ο μετρητής βάσης δείχνει ότι το όριο έχει ξεπεραστεί για ορισμένους από τους πίνακες της βάσης δεδομένων, τότε αυτοί οι πίνακες πρέπει να καθαριστούν. Εάν μιλάμε για έναν κατάλογο ή ένα μη περιοδικό μητρώο πληροφοριών, τότε πρέπει να προσπαθήσετε να αφαιρέσετε περιττά στοιχεία/εγγραφές από εκεί. Το ίδιο ισχύει για τα «βαριά» έγγραφα με τα μέρη τους σε πίνακα. Το πρώτο πράγμα που πρέπει να κάνετε είναι να αφαιρέσετε τα επισημασμένα αντικείμενα, φυσικά.

Τα μητρώα συσσώρευσης αποτελούν ξεχωριστό θέμα. Το μέγεθος των συνολικών πινάκων μπορεί να υπερβαίνει το μέγεθος των πινάκων καταχώρισης του μητρώου, συχνά σημαντικά. Μερικές φορές ακόμη και ένας απλός επανυπολογισμός των αποτελεσμάτων μπορεί να βοηθήσει.

Τα μητρώα υπολοίπων ενδέχεται να έχουν κλείσει εσφαλμένα (όχι για όλες τις διαστάσεις), γεγονός που οδηγεί σε ΠΟΛΥ σημαντική και ταχεία αύξηση των συνόλων πινάκων. Η διαγραφή «κολλημένων» υπολοίπων του μητρώου συσσώρευσης μπορεί, με τον επόμενο επανυπολογισμό των συνόλων, να αποφέρει εξοικονόμηση έως και πολλών GB, που ελέγχεται από τη δική μας εμπειρία με «απρόσεκτους» πελάτες.))

Τι πρέπει να κάνετε εάν κάθε πίνακας στη βάση δεδομένων σας έχει μέγεθος μικρότερο από 4 GB, αλλά το σφάλμα εξακολουθεί να εμφανίζεται;

Αυτό σημαίνει ότι έχετε τη δεύτερη περίπτωση - μια προβληματική δομή μεταδεδομένων διαμόρφωσης. Πιθανότατα, το σφάλμα παρουσιάζεται στο στάδιο δημιουργίας ευρετηρίου.

Με λίγα λόγια, θα περιγράψω την κατάσταση στο σύνολό της, ώστε να είναι ξεκάθαρη, σύμφωνα με τα λόγια του Viktor Sosnovsky από το 1C. Παρακάτω είναι ένα απόσπασμα από ένα φόρουμ συνεργατών:

"Κατά τη φόρτωση μιας βάσης πληροφοριών στην έκδοση αρχείου, πρώτα φορτώνονται τα δεδομένα όλων των πινάκων και στη συνέχεια δημιουργούνται ευρετήρια. Ένα σφάλμα στη δημιουργία ενός ευρετηρίου οδηγεί στο γεγονός ότι το ευρετήριο που δημιουργήθηκε με ένα σφάλμα και όλα τα επόμενα ευρετήρια δεν δημιουργούνται. Εάν υπάρχουν πολλά δεδομένα στη βάση δεδομένων, αυτό θα οδηγήσει σε σημαντική μείωση της παραγωγικότητας Η πλήρης εργασία με μια τέτοια βάση δεδομένων θα είναι αδύνατη».

Πρέπει να μάθετε ποιος πίνακας προκαλεί το σφάλμα κατά τη δημιουργία του ευρετηρίου.

Συμπεριλάβετε το τεχνολογικό περιοδικό - στον φάκελο " C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\(ή παρόμοια __PlatformVersionNumber__εισάγετε το δικό σας) βάλτε το αρχείο logcfg.xmlπερίπου ως εξής:

Διασφαλίζουμε προσεκτικά ότι οι κατάλογοι για χωματερές και αρχεία καταγραφής είναι:

1. Υπήρχαν
2. Διαφορετικά
3. Ήταν αναγνώσιμα και εγγράψιμα από τον χρήστη των Windows για λογαριασμό του οποίου εκτελείτε το πρόγραμμα διαμόρφωσης.

Κάνουμε επανεκκίνηση του διαμορφωτή (αυτό ενεργοποιεί το τεχνολογικό αρχείο καταγραφής) και προσπαθούμε να φορτώσουμε ξανά το .DT μας.Αφού παρουσιαστεί ένα σφάλμα, πηγαίνουμε στον κατάλογο καταγραφής, βρίσκουμε εκεί το αρχείο καταγραφής που περιέχει το σφάλμα μας και το διαβάζουμε προσεκτικά.

Η πρώτη κιόλας εμφάνιση του EXCPCNTX στο αρχείο καταγραφής στην περίπτωσή μου έδειξε την εντολή που προκάλεσε το σφάλμα: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR(το όνομα του ευρετηρίου σας θα είναι διαφορετικό).

Χρησιμοποιώντας τους αριθμούς από το όνομα του ευρετηρίου, χρησιμοποιώντας " " επεξεργασία (ή ανάλογα που μπορούν να εμφανίζουν ευρετήρια), βρίσκουμε σε ποιον πίνακα ανήκει αυτό το ευρετήριο. Για μένα αποδείχθηκε ότι ήταν ένας πίνακας περιστροφών ενός από τους μη τυπικούς καταχωρητές συσσώρευσης.

Πρώτα απ 'όλα, θα πρέπει να εξετάσετε ποια πεδία περιλαμβάνονται στο ευρετήριο. Όπως αποδεικνύεται, στην πλατφόρμα ΠΡΑΓΜΑΤΙΚΑ δεν αρέσει όταν το συνολικό μέγεθος των βασικών πεδίων ευρετηρίου γίνεται σημαντικό. Συγκεκριμένα, δεν του αρέσει να ευρετηριάζει μακριές συμβολοσειρές - έτσι, στην περίπτωσή μου, μια διάσταση τύπου STRING (500) μπήκε στο ευρετήριο και προκάλεσε σφάλμα. Ένας άλλος εκπρόσωπος της εταιρείας 1C μίλησε σε ένα φόρουμ συνεργατών το 2007:

"Εάν το μήκος του κλειδιού αποδειχθεί ότι είναι κοντά στα 2K, τότε αρχίζει μια απότομη αύξηση του μεγέθους των δεικτών με μια σειρά από δυσάρεστες συνέπειες."

Και πράγματι, τίποτα δεν έχει αλλάξει το 2013 - σε τέτοιες περιπτώσεις, παρατηρείται μια ανάπτυξη σαν χιονοστιβάδα στο μέγεθος του ευρετηρίου στη βάση του αρχείου. Και όταν ο πίνακας ευρετηρίου υπερβαίνει το όριο των 4 GB, το loading.DT σταματά με ένα σφάλμα.

Προσωπικά, με βοήθησε να απενεργοποιήσω το πλαίσιο ελέγχου "Χρήση σε σύνολα" για την προβληματική ιδιότητα, επειδή Στην πραγματικότητα, δεν απαιτήθηκαν αποτελέσματα. Δεν εμφανίζεται πλέον στον ίδιο τον πίνακα περιστροφών και, ως εκ τούτου, στο ευρετήριο του πίνακα περιστροφών. Υπάρχουν και άλλοι τρόποι - για να περιορίσετε πιο αυστηρά το μέγεθος της γραμμής, για παράδειγμα. Διάβασα ότι βοήθησε κάποιους.

Αυτές οι αλλαγές πρέπει να εφαρμοστούν στη βάση πληροφοριών, η οποία θα αναδιαρθρώσει τον πίνακά σας.

Εάν γίνουν αλλαγές στα αντίγραφα SQL της βάσης δεδομένων, τότε μετά από αυτό θα πρέπει να επαναφορτώσετε το .DT και να προσπαθήσετε να το φορτώσετε ξανά στην έκδοση αρχείου.

Εάν το αντίγραφο SQL δεν είναι διαθέσιμο, τότε μπορείτε να προσπαθήσετε να το διορθώσετε απευθείας στο υποφορτωμένο αντίγραφο του αρχείου σας. Αφού αποδεχτείτε τις αλλαγές, εκτελέστε το "Test and Fix" σε λειτουργία αναδιάρθρωσης πίνακα βάσης δεδομένων. Τα ευρετήρια θα δημιουργηθούν εκ νέου από την πλατφόρμα και, ελπίζουμε, χωρίς σφάλματα.

Όσοι είναι ιδιαίτερα άτυχοι και το σφάλμα εμφανίζεται ξανά θα πρέπει πρώτα να επαναλάβουν ολόκληρη τη διαδικασία, ξεκινώντας με την ανάλυση των αρχείων καταγραφής. Ίσως υπήρχαν περισσότεροι από ένας προβληματικοί πίνακες ή δεν μπορέσατε να λύσετε το πρόβλημα με τα μεγέθη των πεδίων που περιλαμβάνονται στο ευρετήριο.