Svi znaju razliku između unaprijed definiranih elemenata i običnih: "Unaprijed definirani elementi se kreiraju u načinu konfiguratora i ne mogu se izbrisati u načinu 1C:Enterprise." U korisničkom modu možete razlikovati unaprijed definirani element od onih koje su dodali korisnici pomoću posebne ikone (pogledajte sljedeći snimak ekrana).
U osnovi, unaprijed definirane elemente kreiraju programeri kako bi za njih povezali algoritme u različitim konfiguracijskim objektima. Na primjer, u konfiguraciji “Manufacturing Enterprise Management” u direktoriju “Quality”, programeri su dodali unaprijed definirani element “New”.
Ovaj element se koristi u mnogim konfiguracijskim modulima. Tako se u dokumentu „Prijem robe i usluga“ prilikom knjiženja u sve registre gdje postoji dimenzija „Kvalitet“ zamjenjuje vrijednost unaprijed definisanog elementa. Slijedi popis popunjavanja tabele knjiženja za registar "Roba organizacija":
// PROIZVODI PREMA REGISTERU ProductsOrganizations. MoveSet = Pokreti. ProductsOrganizations; Ako je Vrsta računa = Transferi. Vrste prijema robe. Onda u skladište // Dobivamo tablicu vrijednosti koja odgovara strukturi skupa zapisa registra. MotionTable = MotionSet. Unload() ; // Popuni tabelu kretanja. Opće namjene. LoadValueTable(ProductTable, MovementTable) ; // Nedostajuća polja. Movement Table. FillValues(Organizacija, "Organizacija") ; Movement Table. FillValues(Nedefinirano, "Agent za proviziju"); Movement Table. FillValues(Directories. Quality. New, "Quality") ; // Ispuniti kvalitetu iz unaprijed definiranog elementaDakle, karakteristike unaprijed definiranih elemenata i njihova namjena su prilično jednostavne. Pogledajmo način na koji su pohranjeni u tabelama baze podataka i po čemu se razlikuju od običnih elemenata.
Razlike
U probnoj konfiguraciji kreiran je direktorij "Proizvodi". U njemu je kreirana grupa "Elementi testa". Sadržaj grupe možete vidjeti na snimku ekrana na početku članka. Za direktorij "Proizvodi", SQL baza podataka ima odgovarajuću tablicu "_Reference37" sa sljedećom strukturom:
Ali kako možemo odrediti da li detalji odgovaraju stablu konfiguracije i poljima u SQL tabeli?
Koristit ćemo standardnu globalnu kontekstualnu metodu „GetDatabaseStorageStructure()“, koja će nam vratiti tablicu vrijednosti s opisom strukture tablice.
U tabeli 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 osnovu tabele sa strukturom skladištenja direktorijuma u bazi podataka, definitivno možemo reći da polje „Predefinisano” odgovara polju „IsMetadata”. Ako pogledamo sadržaj tabele "_Reference37" u SQL bazi podataka, vidjet ćemo sljedeće:
U unosu za unaprijed definirani element, vrijednost polja "IsMetadata" je postavljena na "0x01", što odgovara zastavici TRUE. Za normalne elemente vrijednost je postavljena na "0x00". Ovo je glavna razlika između unaprijed definiranih elemenata i običnih. Sva ostala polja se pohranjuju u bazi podataka na isti način kao i polja u redovnim stavkama koje dodaju korisnici.
Unaprijed definirani elementi mogu imati vrlo zanimljivu upotrebu. Uz njihovu pomoć možete spriječiti brisanje/označavanje grupa elemenata za brisanje u direktoriju i drugim objektima gdje se mogu dodati. Ako pokušamo da obrišemo ili označimo za brisanje grupu "Elementi testa". tada dobijamo sljedeće greške:
Dakle, unaprijed definirani elementi čine grupu u koju su smješteni također "predefiniranom".
Završetak
Unaprijed definirani elementi su sastavni dio većine konfiguracija. Njihova upotreba pojednostavljuje razvoj i čini konstrukciju funkcionalnosti logično „skladnijom“ i integralnijom.
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 VRIJEDNOST
Funkcija ZNAČENJE namenjeno za promet u tijelu zahtjeva na sistemske vrijednosti nabrajanja I unapred definisani podaci.
Šta su još ove enumeracije i unapred definisani podaci, pitate se. Hajde da pričamo o svemu po redu.
Transferi
Transferi- ovo je aplikacijski objekat (sjećate se da postoje i Imenici I Dokumentacija). Zašto je bio potreban?
Poenta je da je nabrajanje poseban objekat. Za razliku od priručnika i dokumenata sve moguće vrijednosti nabrajanja su specificirane u fazi konfiguracije i ne može se dalje mijenjati u korisničkom načinu rada.
Nepromjenjivost je njihov glavni adut. Ovo su neke vrste konstanti baze podataka.
A ako je programer u konfiguracijskom modu kreirao nabrajanje s imenom Kat i značenja Muško I Žensko, 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 ovim vrijednostima iz koda.
Zamislite što će se dogoditi ako pokuša koristiti direktorij u ove svrhe?
Prvo, neki korisnik će to uzeti i dodati neku vrstu “marsovskog poda”.
Drugo, drugi korisnik će ići naprijed i izbrisati jedan od postojećih spolova ili promijeniti svoje ime.
I program će zbog toga pokvariti, jer da bi funkcionisao potrebno je da postoje tačno dva roda i to upravo sa nazivima “Muški” i “Ženski”.
Za takve slučajeve postoje enumeracije: da se jednom (u fazi konfiguracije) rigidno definiraju sve moguće varijante vrijednosti i zatim se koriste u programskom kodu.
Pogledajmo primjer takvog nabrajanja u našoj bazi podataka "Gastronom". Čitate probnu verziju lekcije, dostupne su pune lekcije.
Evo našeg nabrajanja sa 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 ovu enumeraciju u budućnosti? Pa, naravno, u imeniku Klijenti. Imajte na umu da se novi rekvizit sa imenom pojavio na njegovoj listi Kat i tip Enumeration.Gender:
Dakle, prilikom popunjavanja kartice klijenta već u korisničkom modu, moći ćemo odabrati samo dvije vrijednosti kao spol klijenta: Muški i Ženski:
Sada kreirajmo 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 dobijamo nista:
Zato što se vrijednostima nabrajanja ne može pristupiti na ovaj način. Treba im pristupiti pomoću funkcije ZNAČENJE:
Dakle, jedan od zadataka funkcije ZNAČENJE- korištenje vrijednosti nabrajanja u upitima.
Predefinisani podaci
Bolje da na primjeru pokažem šta su unaprijed definirani podaci za direktorije. Čitate probnu verziju lekcije, dostupne su pune lekcije.
U našoj bazi podataka "Gastronom" (u korisničkom modu) otvorite direktorij "Jedinice mjerenja":
Pogledajte bliže njegove elemente. Vidite žute krugove pored nekih elemenata? Ovi elementi (koji imaju krugove) jesu unapred definisani podaci.
Općenito, ako je bilo koji element direktorija unaprijed definiran (to jest, na njemu je žuti krug), onda je to poseban element.
Prvo, to znači da je element kreiran u fazi konfiguracije od strane programera (u našem slučaju to su elementi sa 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 podataka vezan za nju (ili bolje rečeno za njeno predefinirano ime).
Zato jednostavno brisanje takvog elementa neće raditi. Pokušajte ga označiti za brisanje:
Idemo sada u konfiguracijski mod i vidimo gdje se kreiraju ovi unaprijed definirani elementi (u ovom slučaju za direktorij jedinica mjere):
Ovdje su svi naši unaprijed definirani elementi za referentnu knjigu mjernih jedinica. Imajte na umu da svi unaprijed definirani elementi imaju posebno ime koje se ne prikazuje u korisničkom modu.
Za element sa kodom 1 ovo ime je tona, sa kodom 2 - gram i tako dalje. Ovo ime se zove unaprijed definirano ime elementa i upravo pod tim imenom možete mu pristupiti iz koda (ili iz zahtjeva u našem slučaju).
Možete pitati zašto mjerne jedinice nije bilo moguće napraviti jednostavno kao popis sa elementima Tona, Gram i Pakovanje? A 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 pakovanje), ali u isto vrijeme ne želimo zabraniti korisniku da doda neke svoje elementi (kilogram, komad i tako dalje). Čitate probnu verziju lekcije, dostupne su pune lekcije.
Stoga su unaprijed definirani elementi ovdje definitivno prikladniji od nabrajanja.
I možemo pristupiti našim unaprijed definiranim elementima iz zahtjeva koristeći funkciju koja nam je već poznata ZNAČENJE:
Uradite test
Pokreni test
1. Vrijednosti nabrajanja su postavljene
2. Za pohranjivanje liste skladišta u kompaniji, tip
3. Za pohranjivanje liste mjernih jedinica u skladištu, tip
4. Za pohranjivanje poreskih stopa čiju listu korisnik ne treba mijenjati, vrstu
5. Za pristup vrijednosti nabrajanja u zahtjevu, koristite funkciju
6. Za pohranjivanje poreskih stopa, čiju listu će mijenjati korisnik, vrstu
7. Unaprijed definirani podaci dolaze s
Dobar dan.
Danas ćemo govoriti o inovaciji u platformi 8.3 u vezi s unaprijed definiranim elementima.
Uvod
Dozvolite mi da vas podsjetim da sam ranije u praksi vrlo često želio pogledati element direktorija kako bih saznao njegovo unaprijed definirano ime. Na primjer, kreirali ste dvije unaprijed definirane ugovorne strane i nazvali ih IPSidorov i OOOMeteor. I prišili su im neku logiku.
Kada je sve bilo otklonjeno i razrađeno, ispostavilo se da je zadatak postavljen obrnuto i da je za DOO potrebna logika za individualnog preduzetnika, a za individualnog preduzetnika logika DOO. „Nema problema“, kažemo, a u poslovnom modu preimenujemo elemente. Na kraju krajeva, ulazak u kod je mnogo teži. Prođe godina i dobijete novi zadatak: da postavite još malo logike za IP Sidorova. Uđeš u konfigurator, napišeš logiku, počneš provjeravati i ništa ne radi, jer... u konfiguratoru IPSidorov, au preduzeću - OOOMeteor. Mozak je slomljen i želim da uništim ovu grabulju. Najjednostavnija i najočitija stvar je prikazati naziv unaprijed definiranog elementa u obliku liste. Evo kvake: možete dobiti samo ime unaprijed definiranog u 8.2 koristeći metodu. Ali metoda ima svoje neugodnosti, ne može se dobiti u zahtjevu. One. Prva neugodnost je da dobijete ime unaprijed definiranog iz reference na direktorij.
Druga neugodnost je kada već imamo element direktorija i moramo ga unaprijed definirati. Kreiramo unaprijed definirani element i dobivamo dva elementa u direktoriju. Jedan je unapred definisan, drugi je operativan, što se pominje u svim našim dokumentima. Zamjena linkova svakako pomaže, ali ako je baza podataka velika, onda je teško.
Sada na stvar
Prvi je da direktorij sada ima svojstvo "Ažuriranje unaprijed definiranih podataka".
Šta nam ovo polje daje? Ako je postavljeno na "Ne ažuriraj automatski", dodavanjem unaprijed definiranog elementa nećemo ga odmah vidjeti u direktoriju. One. metapodaci nemaju nikakve veze sa podacima. A ako ga ne kreirate u direktoriju, onda će mu pristup po imenu preko upravitelja direktorija uzrokovati sintaksičku grešku.
Vrlo zanimljivo, ali zašto? Kako možemo kreirati element u direktoriju? Možete ga kreirati kako god želite ili ga možete povezati s postojećim. Sada direktorij ima atribut "Naziv unaprijed definiranih podataka". Kreiramo element direktorija programski kao i obično kroz “Directories.Contractors.CreateElement()” i popunjavamo njegov atribut “PredefinedDataName” jednakim imenu unaprijed definiranog elementa. Ili ako element već postoji, dobijamo njegov objekat i ponovo popunjavamo „Naziv unapred definisanih podataka“. Sve.
I na kraju malo sirupa
Ovaj novi atribut nije samo čitljiv i upisiv, već je dostupan i u zahtjevima. Na ovaj način možete mu nametnuti uslove u upitima, odrediti da li je unaprijed definiran ili ne.
Hvala vam na pažnji.
Kada radite na platformi 1C:Enterprise 8.x, često postoji potreba da se u programskom kodu povežete sa običnim (ne unaprijed definiranim) elementima direktorija. 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, ostvaruje ili škripanjem po kodu u direktoriju, ili po imenu elementa, u najgorem slučaju.
Bio sam svjedok kako se u izvještajima, da bi se dobila tražena cijena, koristila selekcija po vrsti cijene u zahtjevu po nazivu (pogledajte sljedeći screenshot).
Osim toga, ako se povežete s imenom ili kodom elemenata direktorija, onda kada dobijete vezu do elementa, pretraga će se uvijek izvršiti u tabeli direktorija. Uprkos činjenici da standardne sistemske detalje indeksira DBMS, njihovo traženje u nekim slučajevima može zauzeti značajne resurse. Osim toga, bilo bi racionalnije ne izvršiti upit za pretraživanje pomoću referentne tablice ako je, recimo, veza do elementa već "unaprijed poznata".
Kao izlaz, možete pohraniti vezu do svakog često korištenog elementa direktorija "Vrste cijena artikla" u zasebne konstante i dobiti vrijednosti od njih u zahtjevu. Međutim, u ovom slučaju programer će morati dodati posebnu konstantu za svaki takav element. Situacija će se znatno zakomplikovati ako se takvi elementi nalaze ne samo u imeniku „Vrste cijena artikala”, već iu drugim imenicima („Kategorije objekata”, „Kvalitet”, „Nomenklatura” i drugi). Tada se broj konstanti u sistemu može povećati nekoliko puta!
Naravno, bilo bi moguće dodati unaprijed definirane elemente u svaki od direktorija i pristup bi im postao mnogo lakši. Međutim, promjena zadanih objekata bi otežala ažuriranje konfiguracije iz paketa dobavljača.
Postoji optimalniji pristup kako u pogledu razvoja strukture metapodataka konfiguracije tako iu smislu performansi sistema. To je ono o čemu ćemo danas razgovarati.
Univerzalno rješenje
Suština univerzalnog rješenja bit će sljedeća: kreirat će se direktorij u koji će programer dodati unaprijed definirane elemente. Pronalaženju je dodat atribut "Vrijednost", čiji tip ovisi o vrijednostima za koje će se kreirati korespondencija "Unaprijed definirani element pretraživanja -> Pridružena vrijednost". Struktura metapodataka direktorija izgleda ovako (pogledajte sljedeći snimak ekrana).
Da biste dobili unaprijed definirani element, najbolja opcija je korištenje globalne metode "PredefinedValue(<Имя>)" . Puna putanja do unaprijed definiranog elementa se prosljeđuje kao parametar metodi. Sintaksa je slična funkciji jezika upita VALUE().
Radi lakšeg razvoja, preporučujem postavljanje funkcije za dobivanje vrijednosti povezane s unaprijed definiranim elementom u zajednički modul. U test konfiguraciji, dostupnoj za preuzimanje putem linka na kraju članka, kreiran 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" koristeći zahtjev. Sljedeći snimak ekrana prikazuje kompletan popis funkcija.
Kao što vidimo, funkcija generiše zahtjev za atributom “Value” unaprijed definiranog elementa koji se prosljeđuje kao parametar. Parametar funkcije je niz s imenom unaprijed definiranog elementa.
Da bi kreirani mehanizam ispravno funkcionisao, potrebno je da povežete unapred definisani element u korisničkom režimu sa regularnim elementom direktorijuma tako što ćete izabrati odgovarajući element u atributu „Vrednost“. Pređimo na pitanje uticaja na performanse.
Performance Impact
Proveo sam test brzine za obje opcije pretraživanja: po imenu i po linku iz unaprijed definiranog elementa. Pretraga je obavljena u imeniku "Proizvodi" sa 20.000 unosa. Prilikom provođenja testova na bazi podataka dobijeni su sljedeći rezultati:
Rezultati su pokazali da je za verziju fajla rad korišćenje unapred definisanih elemenata za dobijanje često korišćenih elemenata drugih direktorijuma skoro 4 puta sporije!
U verziji klijent-server rada, rezultati testa pokazuju potpuno drugačiju sliku. Brzina dobijanja veze do željenog elementa nije značajno smanjena (jedan od testova je pokazao 0,002 sekunde za pretragu po imenu i 0,0008 sekundi za rad kroz unapred definisani element), ali je pouzdanost programa značajno porasla!
zaključci
U slučajevima kada je često potrebno povezati se na obične elemente direktorija, preporučujem da ne koristite vezivanje po kodu ili imenu. Ovaj pristup smanjuje pouzdanost i performanse sistema.
Tokom svog rada sa platformom, više puta sam se susreo sa situacijama kada je, nakon promjene imena, na primjer, elementa direktorija „Tipovi nomenklature cijena“, rad većine nestandardnih izvještaja propao.
Što je više algoritama povezano s običnim elementima direktorija putem koda ili imena, manje je stabilan sistem.
Osim toga, ovaj pristup će vam omogućiti da ne mijenjate standardne konfiguracijske objekte ako im trebate dodati unaprijed definirani element. Ovo će u budućnosti donekle olakšati proces ažuriranja konfiguracije.
Fajlovi za preuzimanje:
- Prijenos testne baze podataka s primjerima iz članka.
Sama ideja programskog rada sa unapred definisanim elementima, po mom mišljenju, veoma je ispravna. Jednostavno postoje nijanse koje treba uzeti u obzir prilikom rada.
Prvo, morate jasno shvatiti za sebe da postoje unaprijed definirani elementi u konfiguraciji i da postoje unaprijed definirani elementi u informacijskoj bazi (IS). Tehnički, unaprijed definirani elementi sigurnosti informacija su najčešći elementi direktorija, u kojima atribut “Naziv unaprijed definiranih podataka” označava kojem unaprijed definiranom elementu konfiguracije odgovaraju. Ne razlikuju se od običnih elemenata. Shodno tome, bilo koji obični element sigurnosti informacija može se učiniti unaprijed definiranim, bilo koji unaprijed definirani element može se učiniti običnim. Da biste to učinili, samo unesite željenu vrijednost u atribut "PredefinedDataName".
S vremena na vrijeme, ovo svojstvo sadrži vrijednost koja nije ona koju je programer namjeravao. Kao rezultat toga, pojavljuju se greške u radu 1C. Od kritičnog, u kojem je rad u osnovi nemoguć, do nekritičnog, u kojem je logika algoritama poremećena.
Uslovno možemo razlikovati tri vrste grešaka:
1. "Unaprijed definirani element nije u podacima";
3. Neispravna specifikacija unapred definisanog elementa;
1. "Unaprijed definirani element nije u podacima" - o odsustvo unaprijed definiranog elementa opisanog u konfiguraciji u podacima o sigurnosti informacija.
Ovo je najlakši tip greške za otklanjanje grešaka i ispravljanje. Njegova jednostavnost je u tome što platforma sasvim korektno izveštava o ovoj situaciji „Nedostaje unapred definisani element u podacima“ i sasvim je jasno kako to popraviti.
Prilikom pristupa elementu koji nedostaje u kodu "Direktoriji.Vrste kontakt informacija.E-mail osobe za kontakt" prikazuje se poruka
Prilikom pristupa elementu u zahtjevu "VALUE(Directory.Types of Contact Information.Email of the Contact person)" prikazuje se sljedeća poruka:
Ova greška se javlja ako je element opisan u konfiguraciji, ali element nije povezan s njim u bazi podataka.
Za početak, razjasnimo da ova situacija nije uvijek pogrešna. Sasvim je moguće koristiti unaprijed definirane podatke u nekoj vrsti programske logike, koja se za većinu korisnika možda neće koristiti. U ovom slučaju, kako se direktorij ne bi zatrpao za sve korisnike konfiguracije, logično je definirati unaprijed definirane elemente u konfiguraciji, ali ih ne kreirati u svim sistemima informatičke sigurnosti, već samo za one sisteme informacijske sigurnosti u kojima koristi se potrebna logika konfiguracije. U ovom slučaju, programer može specificirati svojstvo “Ne ažuriraj unaprijed definirane podatke” za direktorij i kreirati elemente programski kada pristupa funkcionalnosti modula. Ili dopustite korisniku da samostalno veže unaprijed definirane elemente modula za postojeće regularne elemente.
Takođe, automatsko kreiranje unapred definisanih elemenata se ne koristi kada se radi u RIB modu. Budući da se novi elementi moraju prenijeti iz centralne baze podataka, a ne kreirati u čvorovima s različitim UID-ovima.
One. Ponekad je greška referenca na neusklađeni element, a ne prisustvo samog takvog elementa.
Potrebno je analizirati zašto element nije kreiran. Možda bi ga trebalo kreirati kada se izvrši neki programski mod. Na primjer, nakon završetka razmjene u RIB-u. Ili je možda samo slučajno obrisana.
Ako logika predviđa popunjavanje unaprijed definiranih elemenata ne automatski, već u zasebnom načinu, onda prije korištenja pristupa po imenu " Imenici.Vrste kontakt informacija.E-mail osobe za kontakt"Da bismo spriječili izvanrednu situaciju, preporučljivo je provjeriti da li je element već u bazi podataka. Ako element nedostaje, o tome obavijestiti korisnika i objasniti koji način treba izvršiti da bi element ispunio. Za takvu provjeru , možete pokrenuti upit za podatke.
Zahtjev = Novi zahtjev; Request.Text = "ODABIR | Vrste kontakt informacija. Link | OD | Imenik. Tipovi kontakt informacija KAKO Tipovi kontakt informacija | GDJE | Vrste kontakt informacija. Naziv unaprijed definiranih podataka = "" EmailContactPerson"""; Stavka je MissingInData = Query.Execute().Empty();
Ako je to i dalje greška u podacima baze podataka, onda je potrebno vezati se za unaprijed definirani element elementa sigurnosti informacija. One. potrebno je objasniti sistemu kojem elementu informacione sigurnosti programski kod treba pristupiti ovim imenom. Tehnički, povezivanje je jednostavno specificiranje imena unaprijed definiranog elementa u svojstvu "PredefinedDataName" elementa IS. Da biste ga instalirali, samo pokrenite kod:
2. "Unaprijed definirani element nije jedinstven" - h dvostruko unaprijed definirani elementi:
Ova situacija je da je nekoliko elemenata sigurnosti informacija vezano za jedan unaprijed definirani element. U tom slučaju, kada se pristupa unaprijed definiranom imenu, 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činju da rade pogrešno.
Platforma će prijaviti grešku "Unaprijed definirani element nije jedinstven" samo kada pokušate urediti duplirani element.
Sve dok niko ne treba da uređuje element, niko neće znati za grešku.
Takvi duplikati se mogu kreirati, na primjer, ako se RIB koristi za direktorij i ako je način “Ažuriraj automatski” naveden u svojstvima za unaprijed definirane podatke. U ovom slučaju, prilikom obavljanja razmjene, jedna instanca predefiniranih podataka će biti kreirana kada se konfiguracija ažurira. Druga instanca unapred definisanih elemenata sa istim imenom biće prebačena iz centralne baze podataka tokom razmene.
Također, ovi duplikati će se pojaviti kada se koristi obrada razmjene između konfiguracija ako različiti elementi sigurnosti informacija odgovaraju unaprijed definiranim elementima u različitim bazama podataka. U ovom slučaju, jedna kopija predefiniranih podataka već postoji u bazi podataka, druga će doći prilikom učitavanja podataka s drugim UID-om. Ako izvodite prijenos podataka, morate odlučiti koji elementi baze podataka se smatraju primarnim 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 greške u bazi podataka mogu se identifikovati upitom kao što je:
ODABIR Vrste kontakt informacija.Naziv unaprijed definisanih podataka, KOLIČINA (RAZLIČITIH tipova informacija o kontaktu.Link) KAO broj unaprijed definiranih iz imenika.Vrste kontakt informacija KAO vrste kontakt informacija GRUPA PREMA vrstama kontakt informacija.Naziv unaprijed definiranih podataka KOJI IMAJU KOLIČINU (RAZLIČITI tipovi kontakt noInformation.Link) > 1
Ovaj upit će vratiti listu unaprijed definiranih elemenata s kojima je povezano više od jednog elementa sigurnosti informacija.
Ako takvi elementi postoje, potrebno je za jedan od njih ukloniti vezu sa predefiniranim. One. Potrebno je nedvosmisleno odrediti za sistem na koji element informacione sigurnosti treba da se odnosi programski kod kada se koristi ovaj naziv. Da biste to učinili, samo pokrenite kod.
3. Netočna specifikacija unaprijed definiranog elementa.
Greška je u tome što unaprijed definirani element odgovara elementu koji nije predviđen programskom logikom. Takve greške je najteže dijagnosticirati. Za razliku od prva dva tipa, konfiguracija se ne može automatski provjeriti za ove greške. One se mogu identifikovati samo analizom logike rada. Ako ste u nedoumici, možete provjeriti da li se koristi ispravan element.
Da biste to učinili, samo pokrenite jednu od naredbi.
//Definiranje elementa sigurnosti informacija koji je povezan sa željenim unaprijed definiranim Obavijesti (Direktoriji.Vrste kontakt informacija.E-mail osobe za kontakt) //Definiranje unaprijed definiranog elementa na koji je prikačeno odabrano Obavijesti (veza na element.Naziv unaprijed definiranih podataka) )
Ako se takve greške uoče, potrebno je ukloniti pogrešnu vezu sa starim elementom i dodati vezu sa novim elementom. Operativni kod je sličan kodu za ispravljanje prve dvije vrste grešaka.
Pa, ukratko o greškama tokom rada programa ili u modu konfiguratora:
"Unaprijed definirani element ne pripada<Имя справочника>" - javlja se greška pri pokušaju pisanja unaprijed definiranog elementa s imenom koje ne odgovara imenu u konfiguratoru.
"Ne-predefinirani objekti ne mogu imati unaprijed definirane zapise subconto pregleda" - dolazi do greške kada se pokuša učiniti nedefiniranim element unaprijed definiranog kontnog plana. Da bi se eliminisale greške, potrebno je ukloniti oznaku “Predefined” sa svake podkontaktne linije elementa.
"Ne-predefinirani objekti ne mogu imati unaprijed definirane zapise vodećih tipova proračuna"- dolazi do greške pri pokušaju da se unaprijed definirani element plana obračunskih tipova učini nepredefiniranim. Da biste eliminisali greške, potrebno je ukloniti potvrdni okvir „Predefinirano“ za svaki red vodećeg tipa proračuna elementa.
"Unaprijed definirani elementi nisu jedinstveni"- generira se greška u konfiguratoru prilikom ažuriranja baze podataka za konfiguracijsko izdanje bez načina kompatibilnosti sa 8.3.4. Prije ažuriranja potrebno je provjeriti ima li duplikata i ukloniti ih.
"Ime unapred definisanog elementa nije jedinstveno" - greška se javlja kada postoji nekoliko predefiniranih elemenata istog imena u konfiguraciji prilikom ažuriranja na platformu8.3.6.2332 i više. Potrebno je ukloniti duplikate u konfiguraciji.
Za rad s unaprijed definiranim podacima, preporučujem obradu. Može izvoditi bilo koje radnje sa unaprijed definiranim podacima, a može i provjeriti konfiguraciju u cjelini na prisustvo grešaka prve dvije vrste (duplicirani i nedostajući elementi) u svim objektima informacione sigurnosti (direktoriji, kontni planovi, PVC, PVR) .
