ПредишенСледващото

Поради факта, че на функционална платформа сепаратори на разработчиците е била значително ревизирани работа с предварително определени стойности на обекти. Ще опиша тези моменти, които ние трябваше да се изправят.

Основната промяна е, че създаването на предварително определени елементи сега може да се контролира самостоятелно.
В допълнение, това е възможно да добавите и премахване на елементи от предварително избрания режим на предприятия в България. Но - не можете да създадете произволен предварително определен елемент. Можете да го зададете само за всеки съществуващ елемент в една от предварително определен имена Конфигуратора.

За да се контролира за създаване на предварително определени елементи, следните механизми:
1) конфигуратора за обекта на метаданни, можете да определите как да се актуализира от предварително зададените данни - Auto Update автоматично, не се актуализира автоматично.
2) може да се създаде набор от предварително определен метод чрез режим за предоставяне на информация като цяло:
UstanovitObnovleniePredopredelennyhDannyhInformatsionnoyBazy (ObnovleniePredopredelennyhDannyh), където
ObnovleniePredopredelennyhDannyh - трансфер система с възможности за автоматично Auto Update, не се актуализира автоматично
3) Можете да зададете режим за създаване на предварително определен от ръководството чрез метода за конкретна база данни таблица:
UstanovitObnovleniePredopredelennyhDannyh (ObnovleniePredopredelennyhDannyh), например
Spravochniki.Nomenklatura.UstanovitObnovleniePredopredelennyhDannyh (ObnovleniePredopredelennyhDannyh.ObnovlyatAvtomaticheski);
4) за създаване на предварително определени елементи също са засегнати от вида на информационна база - основен възел ребро (не подлежи на план обмен които RIB) или периферен блок RIB.

Цитирам от доклада:
Режим Действително Тя се определя в следната последователност:
  • Ако метаданните за обект в режим на набор от данни, актуализация, различна от Auto. се използва тази стойност. (§ 3 от списъка по-горе)
  • В противен случай, ако обектът на метаданни в конфигурацията работи в режим на обслужване, различна от Auto. се използва тази стойност. (Точка 1 от списъка по-горе)
  • В противен случай, ако на информационна база за работа в режим на обслужване, различна от Auto. се използва тази стойност. (Точка 2 от списъка по-горе)
  • В противен случай, ако това е периферен възел RIB, на предварително определена информация не е актуален. Ако тестът се извършва за централния възел RIB или база, която не е RIB, ще се извършва предварително определена актуализация на данните.

Нека да видим няколко стандартни случаи:
1) Ние имаме един вид информационна база без RIB.
В този случай, всичко трябва да се оправи - ако метаданните за конфигурация изложени начин за актуализиране на предварително определен = "Auto" и програмен режим не е бил обект на изключение за базата от знания като цяло или индивидуална маса, ще бъдат създадени предварително дефинираните елементи \ обновяват преструктуриране на базата от знания (това може да да бъде най създаване на IB CF, инсталирането на нова конфигурация или освобождаване на преструктуриране чрез тестване и корекция).

2) Ние имаме определена информация, база с помощта на реброто.
В този случай, няма да бъде създаден по подразбиране в периферната основата на предварително определени елементи за всички обекти метаданни.
Ако обектът на метаданни влиза реброто, са създадени на предварително определени елементи или когато създавате началното изображение, или когато комуникацията с основния модул, но не и по време на конфигурация, ъпгрейд, и по време на четенето на обмен на съобщения.
Ако обект метаданни не е включена в реброто, на предварително определени елементи са създадени няма да бъде, съответно, на база няма да бъде подходящ за използване.

Какво можете да направите:
- да изложи начин за актуализиране на метаданни за обект в конфигурацията = "Автоматично актуализиране" не е съвсем правилно, ако има няколко различни планове за споделяне конфигурация RIB с различни композиции и обектът се появява само в някои от тях. Ако това бъде направено, в тази конкретна ситуация ще бъде фиксирана - в периферните възли предварително определени елементи ще бъдат създадени. Но когато създавате RIB други планове за споделяне на (където е включен обекта) zadubliruyutsya елементи - в периферната възел идват от предварително определен главен възел.

- използвате метод за инсталиране на метода за актуализация за всички IB също погрешно - ще бъдат създадени още нещо, което трябва да дойде с обмена на майстор възел, и се появява един куп дубликати.

- тя остава само да се създаде метод за актуализиране на таблиците за специфична информация база. Предписва обекти някъде в началото на системата и да получите достъп до предварително определени елементи, които не са били създадени. По принцип, този код може да се направи и еднократна такса за информационната база през външен процес, но в този случай, в основата на периферната единица дори да отидете не може да се дължи на факта, че предварително дефинираните елементи, не мигрират и от апарата, е имало жалба в началото на работата на системата :

Друго не много приятен момент - ако вече сте тече периферен възел, а след актуализацията е била преглеждана за първи път на масите (дори и само да отворите списък на директорията, например), а след това по-късно добавя код, за да инсталирате метода на актуализация, изпълнението на този код няма да доведе до създаването на предварително зададен елементи.
За да коригирате това преструктуриране ще трябва да се извърши информационна база чрез тестване и корекция.
Един метод, който би позволил на сила, за да предизвика създаването на предварително определено, не.

Предварително определени елементи могат да създават ръце, но бъдете внимателни, ако използвате клиент-сървър режим и платформа 8.3.4 а - след добавяне елементи ръчно в които е вероятно да влязат в базата данни вече няма да работи - да, когато работи "на Фатална грешка на сървъра 1C" и само в технологични дневници може да се види, че системата се опита да вмъкнете два екземпляра стойност GUID на масата.

3) Създаване на нова периферна възел без разтоварване на първоначалното изображение.
Не съм сигурен колко този метод се удължава, но аз вече се използва 7.7 ​​отклонение за създаване на нов сайт, но няма да блокира монопол главен възел за дълго време. В 8-KE всичко става много по-лесно и по-пълно реализира типичните средства.
Обикновено, за да създадете нов възел се разтоварва първоначалното изображение в същото време той ще бъде изпълнен с цялата информация, която е вярна, включително мигриращите предварително зададени стойности. Но това изисква изключително заключване на базата, че просто не е приемливо за големи обеми.
Друг вариант - въз основа на конфигурацията на основния модул за създаване на празна база данни, след това да създадете двете бази данни възли прикрепят към основния периферен възел за регистрация на обекти за обмен, и да чака края на борсата. И всичко това в тих режим, без изключително заключване база. Но с нов подход към създаването на предварително определен, в този случай ще получим проблем - когато създавате нова база данни, те все още няма да бъде обвързана с основния модул, съответно, системата ще създаде всички предварително определени елементи, а след това техните двойници идват от основното устройство.
За да разрешите този проблем, разработчиците препоръчват следните платформи:
  • След като изтеглите и актуализиране на периферна конфигурация възел, за да стартирате конфигуратора в групов режим с командата "/ SetPredefinedDataUpdate -DoNotUpdateAutomatically"
  • следвайте стъпките за създаване на звена
  • Конфигуратор тичам в групов режим с командата "/ SetPredefinedDataUpdate -Auto"
  • Периферният блок е готов за работа. Предварително зададени данни ще идват от централния възел. Двойки няма.

Свързани статии

Подкрепете проекта - споделете линка, благодаря!