Svatko zna razliku između predefiniranih elemenata i običnih: "Unaprijed definirani elementi stvaraju se u konfiguracijskom načinu rada i ne mogu se izbrisati u 1C:Enterprise načinu." U korisničkom načinu možete razlikovati unaprijed definirani element od onih koje su dodali korisnici pomoću posebne ikone (pogledajte sljedeću sliku zaslona).
U osnovi, unaprijed definirane elemente stvaraju programeri kako bi na njih vezali algoritme u različitim konfiguracijskim objektima. Na primjer, u konfiguraciji "Manufacturing Enterprise Management" u direktoriju "Quality", programeri su dodali unaprijed definirani element "New".
Ovaj se element koristi u mnogim konfiguracijskim modulima. Tako se u dokumentu „Primitak robe i usluga“ kod knjiženja u svim očevidnicima gdje postoji dimenzija „Kvaliteta“ zamjenjuje vrijednost unaprijed definiranog elementa. Slijedi popis popunjavanja tablice knjiženja za upisnik "Roba organizacija":
// PROIZVODI PREMA REGISTRU ProductsOrganizations. MoveSet = Pomicanje. Proizvodi Organizacije; Ako je Vrsta primitka = Prijenosi. Vrste potvrda o primitku robe. Onda u skladište // Dohvatite tablicu vrijednosti koja odgovara strukturi skupa zapisa registra. MotionTable = MotionSet. Istovar() ; // Ispunite tablicu kretanja. Opća namjena. LoadValueTable(ProductTablica, MovementTablica) ; // Nedostaju polja. Tablica kretanja. FillValues(Organizacija, "Organizacija" ) ; Tablica kretanja. FillValues(Nedefinirano, "Komisionar"); Tablica kretanja. FillValues(Directories. Quality. New, "Quality" ) ; // Ispunite kvalitetu iz unaprijed definiranog elementaStoga su karakteristike unaprijed definiranih elemenata i njihova namjena vrlo jednostavne. Pogledajmo na koji su način pohranjeni u tablicama baze podataka i kako se razlikuju od običnih elemenata.
Razlike
U testnoj konfiguraciji kreiran je direktorij "Proizvodi". U njemu je stvorena grupa "Test Elements". Sadržaj grupe mogli ste vidjeti na snimci zaslona na početku članka. Za direktorij "Proizvodi", SQL baza podataka ima odgovarajuću tablicu "_Reference37" sa sljedećom strukturom:
Ali kako možemo utvrditi odgovaraju li detalji konfiguracijskom stablu i poljima u SQL tablici?
Koristit ćemo standardnu metodu globalnog konteksta “GetDatabaseStorageStructure()”, koja će nam vratiti tablicu vrijednosti s opisom strukture tablice.
U tablici vrijednosti "Polja" vidimo korespondenciju između polja SQL tablice i detalja objekta u stablu metapodataka. U našem primjeru razmatramo strukturu direktorija "Proizvodi". Svi direktoriji imaju standardni atribut "Predefined" tipa Boolean, koji je postavljen na TRUE za unaprijed definirane elemente:
Na temelju tablice sa strukturom pohranjivanja direktorija u bazi podataka možemo sa sigurnošću reći da polje “Predefined” odgovara polju “IsMetadata”. Ako pogledamo sadržaj tablice "_Reference37" u SQL bazi podataka, vidjet ćemo sljedeće:
U unosu za unaprijed definirani element, vrijednost polja "IsMetadata" postavljena je na "0x01", što odgovara zastavi TRUE. Za normalne elemente vrijednost je postavljena na "0x00". Ovo je glavna razlika između unaprijed definiranih elemenata i običnih. Sva ostala polja pohranjuju se u bazi podataka na isti način kao i polja u uobičajenim stavkama koje dodaju korisnici.
Unaprijed definirani elementi mogu imati vrlo zanimljive namjene. Uz njihovu pomoć možete spriječiti brisanje/označavanje grupa elemenata za brisanje u imeniku i drugim objektima u koje se mogu dodati. Ako pokušamo izbrisati ili označiti za brisanje grupu "Test Elements". tada dobivamo sljedeće pogreške:
Dakle, unaprijed definirani elementi čine grupu u kojoj su smješteni također "predefiniranom".
Završetak
Unaprijed definirani elementi sastavni su dio većine konfiguracija. Njihova uporaba pojednostavljuje razvoj i čini konstrukciju funkcionalnosti logički "skladnijom" i cjelovitom.
Pažnja! Ovo je uvodna verzija lekcije, čiji materijali mogu biti nepotpuni.
Prijavite se na stranicu kao student
Prijavite se kao učenik za pristup školskim materijalima
Jezik upita 1C 8.3 za programere početnike: funkcija VALUE
Funkcija ZNAČENJE namijenjen cirkulaciji u tijelu zahtjeva na sustavne numeracijske vrijednosti I unaprijed definirani podaci.
Što su još ta nabrajanja i unaprijed definirani podaci, pitate se. Razgovarajmo o svemu redom.
Transferi
Transferi- ovo je objekt aplikacije (sjećate se da postoje i Imenici I Dokumentacija). Zašto je on bio potreban?
Poanta je da je enumeracija poseban objekt. Za razliku od priručnika i dokumenata sve moguće vrijednosti nabrajanja navedene su u fazi konfiguracije i ne može se dalje mijenjati u korisničkom načinu rada.
Nepromjenjivost im je glavni adut. To su neke vrste konstanti baze podataka.
A ako je programer u načinu konfiguracije stvorio enumeraciju s imenom Kat i značenja Muški I Žena, tada prilikom pisanja programa može biti siguran da se vrijednosti ovog nabrajanja neće promijeniti u budućnosti. Stoga on može sigurno pristupiti tim vrijednostima iz koda.
Zamislite što će se dogoditi ako pokuša koristiti imenik u te svrhe?
Prvo će neki korisnik to uzeti i dodati nekakav “marsovski pod”.
Drugo, drugi korisnik će ići naprijed i izbrisati jedan od postojećih spolova ili promijeniti svoje ime.
I program će se zbog toga pokvariti, jer da bi funkcionirao potrebno je da postoje točno dva spola i to baš s imenima “Muški” i “Ženski”.
Upravo za takve slučajeve postoje nabrajanja: kako bi se jednom (u fazi konfiguracije) strogo definirale sve moguće varijante vrijednosti, a zatim ih upotrijebile u programskom kodu.
Pogledajmo primjer takvog nabrajanja u našoj bazi podataka "Gastronom". Čitate probnu verziju lekcije, dostupne su cijele lekcije.
Evo našeg nabrajanja s imenom Kat. Koje vrijednosti može poprimiti?
Postoje samo dva značenja. Sa imenima "Muško" i "Žensko". Baš ono što nam treba.
Gdje možemo koristiti ovo nabrajanje u budućnosti? Pa, naravno, u imeniku Klijenti. Imajte na umu da se novi rekvizit s imenom pojavio na popisu Kat i tip Nabrajanje.Spol:
Dakle, prilikom ispunjavanja kartice klijenta već u korisničkom načinu rada, moći ćemo odabrati samo dvije vrijednosti kao spol klijenta: Muški i Ženski:
Kreirajmo sada upit koji odabire klijente i njihov spol iz baze podataka:
Sada promijenimo upit tako da ostanu samo muškarci. Ako pokušamo napisati nešto poput:
onda ne dobivamo ništa:
Budući da se vrijednostima nabrajanja ne može pristupiti na ovaj način. Potrebno im je pristupiti pomoću funkcije ZNAČENJE:
Dakle, jedan od zadataka funkcije ZNAČENJE- korištenje vrijednosti nabrajanja u upitima.
Unaprijed definirani podaci
Bolje da na primjeru pokažem što su predefinirani podaci za direktorije. Čitate probnu verziju lekcije, dostupne su cijele lekcije.
U našoj bazi podataka "Gastronom" (u korisničkom načinu) otvorite direktorij "Mjerne jedinice":
Pogledajte pobliže njegove elemente. Vidite li žute krugove pored nekih elemenata? Ovi elementi (koji imaju krugove) su unaprijed definirane podatke.
Općenito, ako je bilo koji element imenika unaprijed definiran (to jest, na njemu postoji žuti krug), onda je to poseban element.
Prvo, to znači da je element kreirao programer u fazi konfiguracije (u našem slučaju to su elementi s kodovima 1, 2 i 3).
I, drugo, to znači da je ovaj element vrlo važan za funkcioniranje programa. Da je neki kod u bazi vezan za njega (ili bolje rečeno za njegov predefinirani naziv).
Zato jednostavno brisanje takvog elementa neće uspjeti. Pokušajte ga označiti za brisanje:
Idemo sada u način konfiguracije i pogledajmo gdje se stvaraju ovi predefinirani elementi (u ovom slučaju za direktorij mjernih jedinica):
Ovdje su svi naši unaprijed definirani elementi za referentnu knjigu mjernih jedinica. Imajte na umu da svi unaprijed definirani elementi imaju poseban naziv koji se ne prikazuje u korisničkom načinu rada.
Za element s kodom 1 to je ime Ton, s kodom 2 - Gram i tako dalje. Ovo ime se zove unaprijed definirani naziv elementa i pod tim imenom mu možete pristupiti iz šifre (ili iz zahtjeva u našem slučaju).
Možete se zapitati zašto nije bilo moguće mjerne jedinice jednostavno ispisati s elementima tona, gram i pakiranje? I sve zato što nam je u ovom slučaju važno da referentna knjiga mjernih jedinica uvijek sadrži neke specifične elemente (tona, gram i paket), ali u isto vrijeme ne želimo zabraniti korisniku da doda neke svoje elementi (kilogram, komad i tako dalje). Čitate probnu verziju lekcije, dostupne su cijele lekcije.
Stoga su unaprijed definirani elementi ovdje definitivno prikladniji od nabrajanja.
I možemo pristupiti našim unaprijed definiranim elementima iz zahtjeva pomoću funkcije koja nam je već poznata ZNAČENJE:
Riješite test
Započni test
1. Vrijednosti nabrajanja su postavljene
2. Za pohranu popisa skladišta u tvrtki, tip
3. Za pohranu popisa mjernih jedinica u skladište, tip
4. Za pohranjivanje poreznih stopa, čiji popis korisnik ne smije mijenjati, vrste
5. Za pristup vrijednosti enumeracije u zahtjevu, koristite funkciju
6. Za pohranjivanje poreznih stopa, čiji će popis mijenjati korisnik, vrsta
7. Predefinirani podaci dolaze s
Dobar dan.
Danas ćemo govoriti o inovacijama u platformi 8.3 u vezi s unaprijed definiranim elementima.
Uvod
Dopustite mi da vas podsjetim da sam ranije u praksi vrlo često želio pogledati element imenika kako bih saznao njegov predefinirani naziv. Na primjer, stvorili ste dvije unaprijed definirane druge ugovorne strane i nazvali ih IPSidorov i OOOMeteor. I prišili su im neku logiku.
Kad je sve otklonjeno i razrađeno, pokazalo se da je zadatak postavljen obrnuto i da je za LLC potrebna logika za individualnog poduzetnika, a za individualnog poduzetnika potrebna je logika LLC-a. "Nema problema", kažemo iu poslovnom načinu preimenujemo elemente. Uostalom, ulazak u šifru je puno teži. Prođe godina dana i dobijete novi zadatak: postaviti još neke logike za IP Sidorova. Uđeš u konfigurator, napišeš logiku, počneš provjeravati i ništa ne radi, jer... u konfiguratoru IPSidorov, au poduzeću - OOOMeteor. Mozak je slomljen i želim uništiti ovu grablju. Najjednostavnije i najočiglednije je prikazati naziv predefiniranog elementa u obliku liste. Evo kvake: pomoću metode možete dobiti samo naziv unaprijed definiranog u 8.2. Ali metoda ima svoje neugodnosti; ne može se dobiti u zahtjevu. Oni. Prva neugodnost je dobiti naziv unaprijed definiranog iz reference na imenik.
Druga neugodnost je kada već imamo element imenika i moramo ga unaprijed definirati. Kreiramo unaprijed definirani element i dobivamo dva elementa u direktoriju. Jedan je unaprijed definiran, drugi je operativni, što se navodi u svim našim dokumentima. Zamjena poveznica svakako pomaže, ali ako je baza podataka velika, onda je teško.
Sada na stvar
Prvi je da imenik sada ima svojstvo "Ažuriranje unaprijed definiranih podataka".
Što nam ovo polje daje? Ako je postavljeno na "Ne ažuriraj automatski", tada ga dodavanjem unaprijed definiranog elementa nećemo odmah vidjeti u imeniku. Oni. metapodaci nisu ni na koji način povezani s podacima. A ako ga ne stvorite u imeniku, tada će pristup njegovom imenu kroz upravitelja imenika izazvati sintaktičku pogrešku.
Vrlo zanimljivo, ali zašto? Kako možemo stvoriti element u imeniku? Možete ga izraditi kako god želite ili ga možete povezati s postojećim. Sada imenik ima atribut "Naziv unaprijed definiranih podataka". Element direktorija stvaramo programski kao i obično putem “Directories.Contractors.CreateElement()” i ispunjavamo njegov atribut “PredefinedDataName” jednak nazivu unaprijed definiranog elementa. Ili ako element već postoji, dobivamo njegov objekt i ponovno ispunjavamo "Ime unaprijed definiranih podataka". Svi.
I na kraju malo sirupa
Ovaj novi atribut nije dostupan samo za čitanje i pisanje, već je dostupan iu zahtjevima. Na taj način možete nametnuti uvjete za njega u upitima, odrediti je li predefiniran ili ne.
Hvala vam na pažnji.
Kada radite na platformi 1C:Enterprise 8.x, često postoji potreba za vezanjem programskog koda na obične (ne unaprijed definirane) elemente imenika. Na primjer, organizacija može imati pet vrsta cijena koje se koriste u gotovo svim mehanizmima. U ovom slučaju, programski pristup određenoj cijeni se, u najboljem slučaju, provodi ili škripanjem koda u imeniku ili imenom elementa, u najgorem slučaju.
Svjedočio sam kako je u izvješćima, za dobivanje tražene cijene, odabir korišten prema vrsti cijene u zahtjevu prema njegovom nazivu (pogledajte sljedeću sliku zaslona).
Osim toga, ako se povežete s nazivom ili kodom elemenata imenika, tada kada primite vezu na element, pretraživanje će se uvijek provoditi u tablici imenika. Unatoč činjenici da su standardni detalji sustava indeksirani od strane DBMS-a, traženje istih u nekim slučajevima može oduzeti značajne resurse. Osim toga, bilo bi racionalnije ne izvoditi upit za pretraživanje pomoću referentne tablice ako je, recimo, poveznica na element već "unaprijed poznata".
Kao izlaz, možete pohraniti vezu na svaki često korišteni element direktorija "Vrste cijena artikla" u zasebne konstante i dobiti vrijednosti od njih u zahtjevu. Međutim, u ovom slučaju programer će morati dodati zasebnu konstantu za svaki takav element. Situacija će postati znatno kompliciranija ako se takvi elementi ne nalaze samo u imeniku „Vrste cijena artikala“, već iu drugim imenicima („Kategorije objekata“, „Kvaliteta“, „Nomenklatura“ i drugi). Tada se broj konstanti u sustavu može povećati nekoliko puta!
Naravno, bilo bi moguće dodati predefinirane elemente u svaki od direktorija i pristup bi im postao puno lakši. Međutim, promjena zadanih objekata otežala bi ažuriranje konfiguracije iz paketa dobavljača.
Postoji optimalniji pristup kako u smislu razvoja strukture metapodataka konfiguracije tako iu smislu performansi sustava. O tome ćemo danas govoriti.
Univerzalno rješenje
Suština univerzalnog rješenja bit će sljedeća: kreirat će se direktorij u koji će programer dodavati predefinirane elemente. Pretraživanju je dodan atribut "Vrijednost", čija vrsta ovisi o vrijednostima za koje će se stvoriti korespondencija "Unaprijed definirani element pretraživanja -> Pridružena vrijednost". Struktura metapodataka direktorija izgleda ovako (pogledajte sljedeću sliku zaslona).
Da biste dobili unaprijed definirani element, najbolja opcija je korištenje globalne metode "Unaprijed definirana vrijednost(<Имя>)" . Puni put do unaprijed definiranog elementa prosljeđuje se kao parametar metode. Sintaksa je slična funkciji jezika upita VALUE().
Radi lakšeg razvoja, preporučujem postavljanje funkcije za dobivanje vrijednosti pridružene unaprijed definiranom elementu u zajednički modul. U testnoj konfiguraciji, dostupnoj za preuzimanje putem poveznice na kraju članka, stvoren je zajednički modul "Vrijednosti unaprijed definiranih elemenata" s funkcijom izvoza "GetValue of PredefinedElement(<ИмяПредопределенногоЭлемента>)" . Programski kod funkcije prima referencu na unaprijed definirani element, a zatim prima vrijednosti atributa "Vrijednost" pomoću zahtjeva. Sljedeća snimka zaslona prikazuje potpuni popis funkcija.
Kao što vidimo, funkcija generira zahtjev za atribut "Vrijednost" unaprijed definiranog elementa proslijeđenog kao parametar. Parametar funkcije je niz s nazivom unaprijed definiranog elementa.
Da bi stvoreni mehanizam ispravno radio, potrebno je povezati unaprijed definirani element u korisničkom načinu rada s običnim elementom imenika odabirom odgovarajućeg elementa u atributu "Vrijednost". Prijeđimo na pitanje utjecaja na izvedbu.
Utjecaj na izvedbu
Proveo sam test brzine za obje opcije pretraživanja: po imenu i po poveznici iz unaprijed definiranog elementa. Pretraživanje se odvijalo u imeniku "Proizvodi" s 20.000 unosa. Prilikom provođenja testova na bazi podataka datoteka dobiveni su sljedeći rezultati:
Rezultati su pokazali da je za datotečnu verziju rada korištenje predefiniranih elemenata za dobivanje često korištenih elemenata drugih direktorija gotovo 4 puta sporije!
U klijent-poslužiteljskoj verziji rada rezultati testa pokazuju potpuno drugačiju sliku. Brzina dobivanja poveznice na željeni element nije značajno smanjena (jedan od testova pokazao je 0,002 sekunde za pretraživanje po imenu i 0,0008 sekundi kada se radi kroz unaprijed definirani element), ali je pouzdanost programa značajno porasla!
zaključke
U slučajevima kada je često potrebno povezati se s običnim elementima imenika, preporučujem da ne koristite vezanje kodom ili imenom. Ovaj pristup smanjuje pouzdanost i performanse sustava.
Tijekom rada s platformom više sam se puta susreo sa situacijama u kojima je nakon promjene naziva, na primjer, elementa imenika "Vrste cjenovne nomenklature", većina nestandardnih izvješća otkazala.
Što je više algoritama povezano s običnim elementima direktorija preko koda ili naziva, to je sustav manje stabilan.
Osim toga, ovaj pristup će vam omogućiti da ne mijenjate objekte standardne konfiguracije ako im trebate dodati unaprijed definirani element. To će ubuduće donekle olakšati proces ažuriranja konfiguracije.
Datoteke za preuzimanje:
- Učitavanje testne baze podataka s primjerima iz članka.
Sama ideja programskog rada s predefiniranim elementima po meni je vrlo ispravna. Postoje jednostavno nijanse koje treba uzeti u obzir pri radu.
Prvo, sami morate jasno razumjeti da postoje unaprijed definirani elementi u konfiguraciji i da postoje unaprijed definirani elementi u informacijskoj bazi (IS). Tehnički gledano, predefinirani elementi informacijske sigurnosti najčešći su elementi imenika, u kojima atribut “Naziv predefiniranih podataka” označava kojem predefiniranom konfiguracijskom elementu odgovaraju. Ne razlikuju se od običnih elemenata. U skladu s tim, bilo koji obični informacijski sigurnosni element može biti unaprijed definiran, svaki unaprijed definirani element može biti običan. Da biste to učinili, samo unesite željenu vrijednost u atribut "Unaprijed definirani naziv podataka".
S vremena na vrijeme ovo svojstvo sadrži vrijednost koja nije ona koju je programer namjeravao. Kao rezultat toga, pojavljuju se pogreške u radu 1C. Od kritičnih, u kojima je rad načelno nemoguć, do nekritičnih, u kojima je poremećena logika algoritama.
Uvjetno možemo razlikovati tri vrste grešaka:
1. "Unaprijed definirani element nije u podacima";
3. Neispravna specifikacija unaprijed definiranog elementa;
1. "Unaprijed definirani element nije u podacima" - o nepostojanje unaprijed definiranog elementa opisanog u konfiguraciji u podacima o informacijskoj sigurnosti.
Ovo je vrsta pogreške koju je najlakše otkloniti i ispraviti. Njegova jednostavnost je u tome što platforma prilično ispravno prijavljuje ovu situaciju "U podacima nedostaje unaprijed definirani element" i sasvim je jasno kako to popraviti.
Prilikom pristupa elementu koji nedostaje u kodu "Imenici. Vrste kontakt podataka. E-mail osobe za kontakt" prikazuje se poruka
Prilikom pristupa elementu u zahtjevu "VALUE(Imenik.Vrste podataka za kontakt.E-mail osobe za kontakt)" prikazuje se sljedeća poruka:
Ova se pogreška pojavljuje ako je element opisan u konfiguraciji, ali element nije povezan s njim u bazi podataka.
Za početak, pojasnimo da ova situacija nije uvijek pogrešna. Sasvim je moguće koristiti unaprijed definirane podatke u nekoj vrsti programske logike, što se većini korisnika možda neće koristiti. U tom slučaju, kako ne bi došlo do zatrpavanja imenika za sve korisnike konfiguracije, logično je definirati predefinirane elemente u konfiguraciji, ali ne kreirati ih u svim sustavima informacijske sigurnosti, već samo za one sustave informacijske sigurnosti u kojima koristi se potrebna konfiguracijska logika. U tom slučaju programer može odrediti svojstvo "Ne ažuriraj unaprijed definirane podatke" za direktorij i programski kreirati elemente prilikom pristupa funkcionalnosti modula. Ili dopustite korisniku da samostalno veže predefinirane elemente modula na postojeće regularne elemente.
Također, automatsko kreiranje predefiniranih elemenata se ne koristi kada se radi u RIB modu. Budući da se novi elementi moraju prenijeti iz središnje baze podataka, a ne stvarati u čvorovima s različitim UID-ovima.
Oni. Ponekad je pogreška referenca na neupareni element, a ne prisutnost samog takvog elementa.
Potrebno je analizirati zašto element nije stvoren. Možda bi ga trebalo kreirati kada se izvršava neki programski mod. Na primjer, nakon obavljene razmjene u RIB-u. Ili je možda samo slučajno izbrisano.
Ako logika predviđa popunjavanje unaprijed definiranih elemenata ne automatski, već u zasebnom načinu rada, tada prije korištenja pristupa po imenu " Imenici. Vrste podataka za kontakt. E-pošta osobe za kontakt"Da bi se spriječila iznimna situacija, preporučljivo je provjeriti je li element već u bazi podataka. Ako element nedostaje, obavijestite korisnika o tome i objasnite koji način mora izvršiti da popuni element. Za takvu provjeru , možete pokrenuti upit podataka.
Zahtjev = Novi zahtjev; Request.Text = "SELECT | Vrste podataka za kontakt. Veza | FROM | Imenik. Vrste podataka za kontakt KAKO Vrste podataka za kontakt | GDJE | Vrste podataka za kontakt. Naziv unaprijed definiranih podataka = "" Kontakt osoba e-pošte"""; Stavka nedostaje u podacima = Query.Execute().Empty();
Ako se i dalje radi o pogrešci u podacima baze podataka, tada je potrebno vezati se na unaprijed definirani element elementa informacijske sigurnosti. Oni. potrebno je objasniti sustavu kojem informacijskom sigurnosnom elementu programski kod treba pristupiti pod tim nazivom. Tehnički gledano, vezanje je jednostavno specificiranje imena unaprijed definiranog elementa u svojstvu "PredefinedDataName" elementa IS. Da biste ga instalirali, samo pokrenite kôd:
2. "Unaprijed definirani element nije jedinstven" - h dvostruki predefinirani elementi:
Ova situacija je da je nekoliko elemenata informacijske sigurnosti pridruženo jednom unaprijed definiranom elementu. U tom slučaju, prilikom pristupa unaprijed definiranom nazivu, element će biti odabran nasumično. Ova situacija je uvijek pogrešna. Njegova poteškoća je u tome što platforma to ni na koji način ne prijavljuje. Algoritmi jednostavno počnu raditi neispravno.
Platforma će prijaviti pogrešku "Unaprijed definirani element nije jedinstven" samo kada pokušate urediti duplicirani element.
Sve dok nitko ne treba uređivati element, nitko neće znati za pogrešku.
Takvi se duplikati mogu stvoriti, na primjer, ako se za imenik koristi RIB, a način rada "Automatsko ažuriranje" naveden je u svojstvima za unaprijed definirane podatke. U tom slučaju, prilikom izvođenja razmjene, jedna instanca unaprijed definiranih podataka bit će stvorena kada se konfiguracija ažurira. Druga instanca unaprijed definiranih elemenata s istim imenom bit će prebačena iz središnje baze podataka tijekom razmjene.
Također, ti će se duplikati pojaviti prilikom korištenja obrade razmjene između konfiguracija ako različiti elementi informacijske sigurnosti odgovaraju unaprijed definiranim elementima u različitim bazama podataka. U ovom slučaju, jedna kopija unaprijed definiranih podataka već postoji u bazi podataka, druga će doći prilikom učitavanja podataka s drugim UID-om. Ako obavljate prijenos podataka, trebate odlučiti koji se elementi baze podataka smatraju primarnima i koristiti ih u podređenoj bazi podataka. U podređenoj bazi podataka potrebno je zamijeniti korištenje starih elemenata elementima glavne baze podataka.
Takve pogreške u bazi podataka mogu se identificirati upitom poput:
ODABERITE Vrste podataka o kontaktu. Naziv unaprijed definiranih podataka, KOLIČINA (RAZLIČITE Vrste podataka o kontaktu. Referenca) KAO Broj unaprijed definiranih FROM imenika. Vrste podataka o kontaktu KAO Vrste podataka o kontaktu GRUPIRAJ PO Vrstama podataka o kontaktu. Naziv unaprijed definiranih podataka IMAJU KOLIČINU (RAZLIČITE vrste taktnih informacija. Link) > 1
Ovaj će upit vratiti popis unaprijed definiranih elemenata s kojima je povezano više od jednog elementa informacijske sigurnosti.
Ako su takvi elementi prisutni, potrebno je ukloniti vezu s predefiniranim za jedan od njih. Oni. Sustavu je potrebno nedvosmisleno odrediti na koji se element informacijske sigurnosti treba odnositi programski kod pri korištenju ovog naziva. Da biste to učinili, samo pokrenite kod.
3. Netočna specifikacija unaprijed definiranog elementa.
Pogreška je u tome što unaprijed definirani element odgovara elementu koji nije predviđen logikom programa. Takve pogreške najteže je dijagnosticirati. Za razliku od prve dvije vrste, konfiguracija se ne može automatski provjeriti za ove pogreške. Oni se mogu identificirati samo analizom logike rada. Ako ste u nedoumici, možete provjeriti koristi li se ispravan element.
Da biste to učinili, samo pokrenite jednu od naredbi.
//Definiranje informacijskog sigurnosnog elementa koji je povezan sa željenim unaprijed definiranim Notify (Directories.Tips of Contact Information.Email of the ContactPerson) //Definiranje unaprijed definiranog elementa na koji je odabrano Notify priloženo (Veza na Element.Name unaprijed definiranih podataka )
Ako se takve pogreške uoče, potrebno je ukloniti neispravnu vezu sa starim elementom i dodati vezu s novim elementom. Kod operacije je sličan kodu za ispravljanje prve dvije vrste grešaka.
Pa, ukratko o pogreškama tijekom rada programa ili u načinu rada konfiguratora:
"Unaprijed definirani element ne pripada<Имя справочника>" - javlja se greška prilikom pokušaja upisa predefiniranog elementa s nazivom koji ne odgovara nazivu u konfiguratoru.
"Nepredefinirani objekti ne mogu imati unaprijed definirane zapise pregleda podkonto" - javlja se pogreška pri pokušaju dedefiniranja elementa unaprijed definiranog kontnog plana. Da biste uklonili pogreške, potrebno je ukloniti oznaku "Unaprijed" sa svakog retka podkontakta elementa.
"Nepredefinirani objekti ne mogu imati unaprijed definirane zapise vodećih vrsta izračuna"- javlja se greška prilikom pokušaja dedefiniranja predefiniranog elementa plana obračunskih vrsta. Da biste uklonili pogreške, potrebno je ukloniti potvrdni okvir "Unaprijed" za svaki red vodeće vrste izračuna elementa.
"Unaprijed definirani elementi nisu jedinstveni"- generira se pogreška u konfiguratoru prilikom ažuriranja informacijske baze za izdanje konfiguracije bez načina kompatibilnosti s 8.3.4. Potrebno je provjeriti duplikate i ukloniti ih prije ažuriranja.
"Naziv unaprijed definiranog elementa nije jedinstven" - greška se javlja kada postoji nekoliko predefiniranih elemenata istog naziva u konfiguraciji prilikom ažuriranja na platformu8.3.6.2332 i novije. Potrebno je eliminirati duplikate u konfiguraciji.
Za rad s unaprijed definiranim podacima preporučujem obradu. Može izvoditi bilo koje radnje s unaprijed definiranim podacima, a također može provjeriti konfiguraciju u cjelini na prisutnost pogrešaka prve dvije vrste (duplicirani i nedostajući elementi) u svim objektima informacijske sigurnosti (imenici, kontni planovi, PVC, PVR) .
