20.09.2014

Ekziston një direktivë "Lejohet" në gjuhën e pyetjes. Ai synohet të përdoret nga korniza për të filtruar të dhënat për të cilat përdoruesi nuk ka të drejta kur vendos një kufi të nivelit të regjistrimit të bazës së të dhënave.

Duket se në pyetje është më mirë të përdoret gjithmonë kjo direktivë. Unë do të argumentoj se nuk është kështu. Gjithashtu, unë do të argumentoj se nëse është e mundur, duhet të shmangni përdorimin e tij, prandaj.

Le të themi se bëjmë një raport për marrëveshjet e ndërsjella të individëve. Përdoruesi ka të drejta për një organizatë, dhe ka më shumë se një organizatë në bazën e të dhënave, dhe kufizimi i nivelit të regjistrimit është i aktivizuar në bazën e të dhënave. Gjithashtu, baza e të dhënave ka një regjistër “Bashkime të ndërsjella” me përmasat “Organizata” dhe “Individual”. Nëse ka një kërkesë në sistem

"Zgjidhni

Organizimi,

Individual

dhe do të ekzekutohet në emër të një përdoruesi me leje për një organizatë, atëherë pyetja do të dështojë nëse ka regjistrime të organizatave të tjera në këtë regjistër. Do të ndodhë një gabim dhe përshkrimi i gabimit do të jetë "Përdoruesi nuk ka të drejta të mjaftueshme për të plotësuar kërkesën!" dhe kjo është e vërtetë, platforma nuk mashtron, pasi nuk ka të drejta për të dhënat e organizatave të tjera në këtë regjistër.

Çfarë duhet të bëni në këtë rast, përdorni direktivën "E lejuar"? Nuk ia vlen për mendimin tim. Thjesht duhet të vendosni përzgjedhjen sipas organizatës dhe përdoruesi do të jetë në gjendje të gjenerojë një raport. Kërkesa për një raport me përbërjen e të dhënave do të duket kështu

"Zgjidhni

Organizimi,

Individual

(Zgjidhni

Organizimi

individual)

Nga Regjistri i Akumulimit

(ku

Organizimi

individual)

Nëse përdoruesi ekzekuton një pyetje në tabelë pa përzgjedhje, atëherë raporti nuk do të gjenerohet dhe përdoruesi nuk do të njohë të dhënat për organizatat e tjera dhe nëse vendos përzgjedhjen për organizatën e tij, ai do të gjenerojë të dhënat e sakta.

Mund të pyesni përsëri - "Pse nuk duhet të përdorni direktivën e lejuar", kjo menjëherë imponon një përzgjedhje, kursen përdoruesin nga mesazhet që nuk i nevojiten!

Përgjigja për këtë pyetje do të jetë si vijon - si në këtë rast përdoruesi do të dijë se të gjitha të dhënat e nevojshme janë përfshirë në raport. Supozoni, më parë, ky përdorues ka punuar me të drejta të plota dhe ka bërë një gabim dhe ka zgjedhur një individ nga një organizatë tjetër në dokument. Mund të ketë gjithashtu një situatë, të dhënat po ngarkoheshin - dhe një nënndarje e një organizate tjetër u regjistrua në dokumentet e organizatës (në ZUP, kufizimet për pronarin vendosen gjithashtu ndaj tyre). Në këtë rast, direktiva "E lejuar" do të ndërpresë të dhënat e ndaluara pa asnjë mesazh për përdoruesin dhe ai nuk do ta dijë se nuk është përfshirë gjithçka që duhet të përfshihet në raport.

Prandaj, nuk është e nevojshme që kjo direktivë të futet masivisht në kërkesat për konfigurime tipike, duke e konsideruar këtë një gabim. Është shumë e dekurajuar të bëhet kjo në kërkesat e rregulluara të raportimit. Gjithashtu, mos e bëni këtë në raporte dhe dokumente të tjera ku nevojitet saktësia e informacionit.

Por si mund të shmangni përsëri gabimin e "rënies" së programit me mungesë të drejtash?

Po, është shumë e thjeshtë, duhet të përdorni komandën "Try", këtu është një shembull:

Përpjekje

Kërkesë.Ekzekutoj();

Përjashtim

Raporti(Përshkrimi i Gabimit());

Fundi i Përpjekjes;

Në raportet që përdorin ACS, kodi i programit për ekzekutimin e raportit duhet të shkruhet manualisht, gjithashtu përmes një përpjekjeje.

Si rezultat, përdoruesi nuk do të marrë të dhëna të pasakta dhe do të marrë një mesazh të arsyeshëm gabimi.

Ju mund të njiheni me nuancat e vendosjes së RLS në ndarje të veçanta në artikullin tonë.

). Përdorimi i kësaj fjale kyçe shmang një gabim gjatë marrjes së regjistrimeve për të cilat përdoruesi nuk ka të drejta.

Problem: Në disa raste, rezultati i kufizimeve të aksesit të të dhënave në 1C 8.3 mund të varet nga plani i pyetjes DBMS. Ky artikull diskuton situatat e mundshme dhe jep rekomandime se si ta shmangni atë.

Problemi i varësisë së mundshme të rezultatit të kufizimeve të aksesit të të dhënave në planin e pyetjes DBMS mund të lindë kur një pyetje e bazës së të dhënave ekzekutohet pa fjalën kyçe LEJOHET nëse ka kufizime për aksesin e të dhënave për përdoruesin aktual dhe pyetja përmban një ose më shumë krahasime të formularit:

• <Выражение над полями>(NE|JO NE) (<Вложенный запрос>)
• (<Выражение над полями 1>, …, <Выражение над полями N>) (NE|JO NE) (<Вложенный запрос>)

Nëse në këtë rast < > (pyetja në një pyetje) përdor tabelat e bazës së të dhënave që i nënshtrohen kufizimeve të aksesit, atëherë është e mundur që pyetja të ekzekutohet me sukses në disa DBMS dhe një mesazh do të lëshohet në të tjera, me kusht që të dhënat në bazat e informacionit të jenë plotësisht identike. .

Merrni mësime video 267 1C falas:

Arsyeja e dallimeve

Dallimi i mundshëm në sjellje është për shkak të zbatimit të kufizimeve të aksesit të të dhënave pa fjalën kyçe LEJOHET në Ndërmarrjen 1C 8.3.

Pyetje pa një fjalë kyçe LEJOHET do të ekzekutohet me sukses vetëm nëse gjatë ekzekutimit të tij nuk ka qasje në të dhënat e ndaluara. Për ta bërë këtë, i shtohet një fushë e veçantë sinjali, e cila merr vlerën E vërtetë për ato rekorde në formimin e të cilave kanë marrë pjesë vetëm të dhënat e lejuara, dhe vlera Gënjeshtra për të gjitha hyrjet e tjera. Nëse të paktën një rekord i përzgjedhjes përmban vlerën Gënjeshtra në fushën e sinjalit, atëherë pyetja përfundon në mënyrë jonormale.

E njëjta fushë sinjali u shtohet rezultateve të pyetjeve të vendosura në krahasim. NË/JO NË. Për më tepër, kontrolli i vlerës së kolonës së sinjalit në këtë rast kryhet me anë të DBMS. Kështu, nëse në procesin e ekzekutimit të një pyetjeje të mbivendosur ka pasur një akses në të dhënat e ndaluara, atëherë ekzekutimi i pyetjes duhet të përfundojë me një gabim Përdoruesi nuk ka të drejta të mjaftueshme për të kryer një operacion në bazën e të dhënave.

Megjithatë, kur ndërtohet një plan pyetjesh, DBMS mund të mos marrë përzgjedhjen e plotë <Вложенным запросом> , dhe merrni vetëm ato regjistrime që nevojiten në të vërtetë për të kontrolluar gjendjen NË/JO NË. Në këtë rast, pyetja mund të ketë sukses edhe nëse <Вложенного запроса> qasja në të dhënat e ndaluara mund të ndodhë si një kërkesë e pavarur.

Le të shqyrtojmë një shembull të thjeshtë. Lëreni në tryezë Drejtoria.Individët kufizimet e aksesit të të dhënave. Në këtë rast kërkesa është:

Tabela.Individi AS Individ

do të ekzekutohet me një gabim për shkak të një përpjekjeje për të hyrë në të dhënat e ndaluara. Nëse kjo pyetje përfshihet në krahasim, për shembull:

Tabela.Individi AS Individ

Drejtoria.Tabela e individëve AS)

atëherë, në varësi të planit të pyetësorit të zgjedhur nga DBMS, pyetja mund të ekzekutohet ose me sukses ose me një gabim. Kjo sjellje e kërkesës nuk është e gabuar, pasi qasja në të dhënat e ndaluara gjatë ekzekutimit të kësaj kërkese mund të ndodhë ose jo. Për të marrë një rezultat më të parashikueshëm, është e nevojshme të ndërtohet një pyetje në mënyrë të tillë që pyetja e ndërthurur të garantohet të mos kryejë qasje në të dhëna dukshëm të panevojshme. Në veçanti, nëse pyetja e mëparshme rishkruhet si kjo:

Kontrata për kryerjen e punës me një individ.Punonjës.Individ

Dokument Kontrata për kryerjen e punës me një individ AS një marrëveshje për kryerjen e punës me një individ

Kontratë për kryerjen e punës me një individ.Punonjës.Individi B (

Tabela.Individi AS Individ

Drejtoria.Individët AS Tabela

Gjuha e pyetjes është një nga mekanizmat themelorë të 1C 8.3 për zhvilluesit. Me ndihmën e pyetjeve, ju mund të merrni shpejt çdo të dhënë të ruajtur në bazën e të dhënave. Sintaksa e tij është shumë e ngjashme me SQL, por ka disa dallime.

Përparësitë kryesore të gjuhës së pyetjeve 1C 8.3 (8.2) ndaj SQL:

• çreferencimi i fushave të referencës (duke kthyer një ose më shumë pika në atribute të objektit);
• puna me rezultatet është shumë e përshtatshme;
• aftësia për të krijuar tabela virtuale;
• kërkesa mund të shkruhet si në anglisht ashtu edhe në rusisht;
• aftësia për të bllokuar të dhënat për të shmangur bllokimet.

Disavantazhet e gjuhës së pyetjes në 1C:

• ndryshe nga SQL, në pyetjet 1C nuk ju lejojnë të ndryshoni të dhënat;
• mungesa e procedurave të ruajtura;
• pamundësia e shndërrimit të vargut në numër.

Konsideroni mini-tutorialin tonë mbi ndërtimet bazë të gjuhës së pyetjeve 1C.

Për shkak të faktit se kërkesat në 1C ju lejojnë vetëm të merrni të dhëna, çdo kërkesë duhet të fillojë me fjalën "SELECT". Pas kësaj komande, tregohen fushat nga të cilat dëshironi të merrni të dhëna. Nëse specifikoni "*", atëherë do të zgjidhen të gjitha fushat e disponueshme. Vendi nga ku do të përzgjidhen të dhënat (dokumentet, regjistrat, drejtoritë, etj.) shënohet pas fjalës "NGA".

Në shembullin e mëposhtëm, emrat e të gjithë nomenklaturës janë zgjedhur nga libri i referencës "Nomenklatura". Pas fjalës "SI", tregohen pseudonimet (emrat) për tabelat dhe fushat.

ZGJIDHNI
Nomenklatura.Emri AS EmriNomenklatura
NGA
Nomenklatura AS Nomenklature

Pranë komandës "SELECT", mund të specifikoni fjalë kyçe:

• TË NDRYSHME. Kërkesa do të zgjedhë vetëm rreshta që ndryshojnë në të paktën një fushë (pa dublikatë).
• E PARË n, Ku n– numri i rreshtave nga fillimi i rezultatit që do të zgjidhet. Më shpesh, ky ndërtim përdoret së bashku me renditjen (ORDER BY). Për shembull, kur ju duhet të zgjidhni një numër të caktuar të dokumenteve më të fundit sipas datës.
• LEJOHET. Ky dizajn ju lejon të zgjidhni nga baza e të dhënave vetëm ato regjistrime që janë në dispozicion të përdoruesit aktual. Nëse përdoret kjo fjalë kyçe, përdoruesi do të marrë një mesazh gabimi nëse përpiqet të kërkojë regjistrime në të cilat nuk kanë akses.

Këto fjalë kyçe mund të përdoren të gjitha së bashku ose veçmas.

PËR NDRYSHIM

Kjo klauzolë bllokon të dhënat për të shmangur konfliktet. Të dhënat e kyçura nuk do të lexohen nga një lidhje tjetër deri në fund të transaksionit. Në këtë klauzolë, ju mund të specifikoni tabela specifike që dëshironi të kyçni. Përndryshe, të gjitha do të bllokohen. Dizajni është i rëndësishëm vetëm për mënyrën e bllokimit automatik.

Më shpesh, klauzola "PER NDRYSHIM" përdoret kur merren bilancet. Në të vërtetë, kur disa përdorues punojnë në program në të njëjtën kohë, ndërsa njëri merr bilancet, tjetri mund t'i ndryshojë ato. Në këtë rast, bilanci që rezulton nuk do të jetë më i saktë. Nëse bllokoni të dhënat me këtë propozim, atëherë derisa punonjësi i parë të marrë bilancin e saktë dhe të kryejë të gjitha manipulimet e nevojshme me të, punonjësi i dytë do të duhet të presë.

ZGJIDHNI
Marrëveshjet e ndërsjella.Punonjës,
Shlyerjet e ndërsjella Shuma e shlyerjeve të ndërsjella Bilanci
NGA
Regjistri i Akumulimit.Vlerësimet e ndërsjella ME Punonjësit.Banancat AS Rregullime të ndërsjella
PËR NDRYSHIM

KU

Ndërtimi është i nevojshëm për të imponuar çdo përzgjedhje në të dhënat e shkarkuara. Në disa raste të marrjes së të dhënave nga regjistrat, është më e arsyeshme të përshkruhen kushtet e përzgjedhjes në parametrat e tabelave virtuale. Kur përdorni "WHERE", të gjitha regjistrimet merren së pari dhe vetëm atëherë aplikohet përzgjedhja, e cila ngadalëson ndjeshëm pyetjen.

Më poshtë është një shembull i një kërkese për të marrë persona kontaktues me një pozicion specifik. Parametri i përzgjedhjes ka formatin e mëposhtëm: &ParameterName (emri i parametrit është arbitrar).

PËRZGJEDHJA (RASTI)

Konstrukti ju lejon të specifikoni kushtet drejtpërdrejt në trupin e kërkesës.

Në shembullin e mëposhtëm, "Fusha Shtesë" do të përmbajë tekst në varësi të faktit nëse dokumenti është postuar apo jo:

ZGJIDHNI
PranimiT&U.Link,
ZGJEDHJA
KUR
PASTAJ "Dokumenti u postua!"
TJETER "Dokumenti nuk është postuar..."
FUND AS Fushë shtesë
NGA
Dokumenti.Marrja e MallraveShërbimet AS PranimiT&C

BASHKOHU

Bashkon lidhjen e dy tabelave sipas një kushti të caktuar lidhjeje.

BASHKOHUNI ME Majtas/Djathtas

Thelbi i bashkimit LEFT është që tabela e parë e specifikuar të merret plotësisht dhe e dyta t'i bashkëngjitet asaj nga kushti i lidhjes. Nëse nuk ka regjistrime që korrespondojnë me tabelën e parë në të dytën, atëherë NULL zëvendësohet si vlera e tyre. E thënë thjesht, tabela kryesore është tabela e parë e specifikuar dhe të dhënat e tabelës së dytë (nëse ka) tashmë janë zëvendësuar për të dhënat e saj.

Për shembull, ju duhet të merrni artikujt nga dokumentet "Pranimi i mallrave dhe shërbimeve" dhe çmimet nga regjistri i informacionit "Çmimet e artikujve". Në këtë rast, nëse çmimi i ndonjë pozicioni nuk gjendet, zëvendësoni në vend të tij NULL. Të gjithë artikujt nga dokumenti do të zgjidhen pavarësisht nëse kanë një çmim apo jo.

ZGJIDHNI
Marrja e nomenklaturës T&U,
Çmimet.Çmimi
NGA
Dokumenti.Marrja e MallraveShërbimet.Mallrat AS PranimT&C
BASHKIMI I BRENDSHËM
MBI Marrjen e Pyetje dhe Përgjigje.Nomenklatura = Çmimet.Nomenklatura

Në të DREJTË, gjithçka është pikërisht e kundërta.

LIDHJE E PLOTË

Ky lloj bashkimi ndryshon nga ato të mëparshmet në atë që të gjitha regjistrimet e tabelës së parë dhe të dytë do të kthehen si rezultat. Nëse nuk gjenden regjistrime në tabelën e parë ose të dytë për kushtin e specifikuar të lidhjes, në vend të kësaj do të kthehet NULL.

Kur përdorni bashkimin e plotë në shembullin e mëparshëm, do të zgjidhen të gjithë artikujt nga dokumenti i marrjes së mallrave dhe shërbimeve dhe të gjitha çmimet më të fundit nga regjistri i Çmimeve të Artikujve. Vlerat e rekordeve të pa gjetura, si në tabelën e parë ashtu edhe në tabelën e dytë, do të jenë NULL.

BASHKIMI I BRENDSHËM

Dallimi midis një bashkimi INNER dhe një bashkimi FULL është se nëse një rekord nuk gjendet të paktën në njërën nga tabelat, atëherë pyetja nuk do ta shfaqë fare. Si rezultat, do të zgjidhen vetëm ato artikuj nga dokumenti i faturës së mallrave dhe shërbimeve për të cilët ka regjistrime në regjistrin e informacionit të Çmimeve të Artikujve, nëse në shembullin e mëparshëm zëvendësojmë FULL me INTERNAL.

GRUP NGA

Grupimi në pyetjet 1C ju lejon të kolapsoni rreshtat e tabelës (fushat e grupimit) sipas një veçorie të caktuar të përbashkët (fushat e grupimit). Fushat e grupimit mund të shfaqen vetëm duke përdorur funksionet e përgjithshme.

Rezultati i pyetjes tjetër do të jetë një listë e llojeve të artikujve me çmimet e tyre maksimale.

ZGJIDHNI
,
MAX (Çmimi.Çmimi) SI Çmimi
NGA

GRUP NGA
Çmimet.Nomenklatura.TipiNomenklatura

REZULTATET

Ndryshe nga grupimi, kur përdorni totalet, të gjitha regjistrimet shfaqen dhe rreshtat totale janë shtuar tashmë në to. Grupimi shfaq vetëm regjistrime të përgjithësuara.

Rezultatet mund të përmblidhen për të gjithë tabelën (duke përdorur fjalën kyçe "TË PËRGJITHSHME"), për disa fusha, për fusha me strukturë hierarkike (fjalë kyçe "HIERARKI", "VETËM HIERARKI"). Kur përmbledhni, nuk është e nevojshme të përdorni funksione agregate.

Konsideroni një shembull të ngjashëm me shembullin e mësipërm duke përdorur grupimin. Në këtë rast, rezultati i pyetjes do të kthejë jo vetëm fushat e grupuara, por edhe regjistrime të detajuara.

ZGJIDHNI
Çmimet.Nomenklatura.Lloji i nomenklaturës AS Lloji i nomenklaturës,
Çmimet.Çmimi SI Çmimi
NGA
RegjistroInformacion.Nomenklatura e Çmimeve.Fetë e Fundit AS Çmimet
REZULTATET
MAXIMUM (Çmimi)
NGA
Nomenklatura e tipit

DUKE

Ky operator është i ngjashëm me operatorin WHERE, por përdoret vetëm për funksionet agreguese. Fushat e tjera nga ato të përdorura nga ky operator duhet të grupohen. Operatori "WHERE" nuk është i zbatueshëm për funksionet agregate.

Në shembullin e mëposhtëm, çmimet maksimale të artikujve zgjidhen nëse tejkalojnë 1000, të grupuara sipas llojit të artikullit.

ZGJIDHNI

MAX (Çmimi.Çmimi) SI Çmimi
NGA
RegjistroInformacion.Nomenklatura e Çmimeve.Fetë e Fundit AS Çmimet
GRUP NGA
Çmimet.Nomenklatura.TipiNomenklatura
DUKE
MAX (Çmimet.Çmimi) > 1000

NDAJ SIPAS

Operatori "ORDER BY" rendit rezultatin e pyetjes. Për të siguruar që të dhënat dalin në një rend të qëndrueshëm, përdoret AUTO-ORDER. Llojet primitive renditen sipas rregullave të zakonshme. Llojet e referencës renditen sipas GUID.

Një shembull i marrjes së një liste punonjësish të renditur sipas emrit:

ZGJIDHNI
Punonjësit.Emri AS Emri
NGA
Employees AS Employees
NDAJ SIPAS
Emri
AUTO POROSI

Ndërtime të tjera të gjuhës së pyetjeve 1C

• BASHKOHUNI- rezultatet e dy pyetjeve në një.
• BASHKONI TË GJITHA– e ngjashme me JOIN, por pa grupuar rreshta identikë.
• TABELA E zbrazur- përdoret ndonjëherë kur bashkohen pyetjet për të specifikuar një tabelë bosh të mbivendosur.
• VENDOSJE- krijon një tabelë të përkohshme për të optimizuar pyetjet komplekse 1C. Kërkesa të tilla quhen kërkesa grupore.

Karakteristikat e gjuhës së pyetjes

• SUBSTRING shkurton një varg nga një pozicion i caktuar me numrin e caktuar të karaktereve.
• VITI… I DYTI ju lejon të merrni vlerën e zgjedhur të llojit numerik. Parametri i hyrjes është një datë.
• FILLIMI I PERIUDHËS DHE FUNDIMI I PERIUDHËS përdoren kur punohet me data. Lloji i periudhës (DITA, MUAJ, VIT, etj.) është specifikuar si një parametër shtesë.
• SHTO ju lejon të shtoni ose zbritni nga data kohën e specifikuar të një lloji të caktuar (SECOND, MINUTE, DAY, etj.).
• DIFERENCA DATA përcakton diferencën midis dy datave, duke specifikuar llojin e vlerës së prodhimit (DITA, VITI, MUAJ, etj.).
• ËSHTË NULL zëvendëson vlerën që mungon me shprehjen e specifikuar.
• PARAQITJA dhe LIDHJA E PREZANTIMIT merrni paraqitjen e vargut të fushës së specifikuar. Ato përdoren për çdo vlerë dhe vetëm vlera referuese, respektivisht.
• LLOJI, LLOJI I VLERËS përdoren për të përcaktuar llojin e parametrit të hyrjes.
• LIDHJEështë një operator logjik i krahasimit për llojin e vlerës së atributit.
• EXPRESS përdoret për të kthyer vlerën në llojin e dëshiruar.
• DATA KOHA merr një vlerë të tipit "Data" nga vlerat numerike (viti, muaji, dita, ora, minuta, sekonda).
• KUPTIMI në një kërkesë 1C, përdoret për të specifikuar vlerat e paracaktuara - drejtoritë, numërimet, planet për llojet e karakteristikave. Shembull përdorimi: " Ku LegalIndividual = Vlera (Enumeration.LegalIndividual.Individual)«.

Ndërtues i pyetjeve

Për të krijuar pyetje me 1C, ekziston një mekanizëm i integruar shumë i përshtatshëm - projektuesi i pyetjeve. Ai përmban skedat kryesore të mëposhtme:

• "Tabelat dhe fushat" - përmban fushat që do të zgjidhen dhe burimet e tyre.
• "Links" - përshkruan kushtet për konstruktin LIDHJE.
• "Grupimi" - përmban një përshkrim të ndërtimeve të grupimeve dhe fushave të përmbledhura sipas tyre.
• "Kushtet" - është përgjegjës për përzgjedhjen e të dhënave në kërkesë.
• "Advanced" - parametra shtesë të pyetjes, si fjalët kyçe të komandës "SELECT", etj.
• "Bashkimet / pseudonimet" - tregohen mundësitë e bashkimit të tabelave dhe vendosen pseudonimet (konstrukti "SI").
• "Urdhri" - është përgjegjës për renditjen e rezultatit të pyetjeve.
• "Totals" - e ngjashme me skedën "Grupimi", por përdoret për ndërtimin "TOTALS".

Vetë teksti i kërkesës mund të shihet duke klikuar në butonin "Kërkesë" në këndin e poshtëm të majtë. Në këtë formë, ai mund të korrigjohet me dorë ose të kopjohet.

Konsola e pyetjeve

Për të parë shpejt rezultatin e një pyetjeje në modalitetin "Enterprise" ose për të korrigjuar pyetjet komplekse, përdorni . Teksti i pyetjes shkruhet në të, vendosen parametrat dhe shfaqet rezultati i tij.

Ju mund ta shkarkoni konsolën e pyetjeve në diskun ITS ose nga .

Objekti i konfigurimit "role" jep një grup të drejtash për operacionet (veprimet) në objektet e konfigurimit.

Roli "Të drejta të plota".

Ky është vetëm një rol (jo i paracaktuar) që ka kuti kontrolli për të gjitha llojet e të drejtave në të gjitha objektet e konfigurimit.

Dallimi i tij nga rolet e tjera është prania e së drejtës së “Administratës”.

Nëse krijohet të paktën një përdorues, sistemi fillon të kontrollojë për të drejtën "Administrim" - të paktën një përdorues duhet ta ketë atë.

Kufizoni aksesin në nivel rekord

Siguria e nivelit të rreshtit (RLS) - Kufizim në nivel rekord.

Mekanizmi i kufizimeve të aksesit të të dhënave ju lejon të menaxhoni të drejtat e aksesit jo vetëm në nivelin e objekteve të meta të dhënave, por edhe në nivelin e objekteve të bazës së të dhënave. Objektet e mëposhtme mund të përdoren për të kufizuar aksesin në të dhëna:

• rolet,
• opsionet e sesionit,
• opsionet funksionale,
• module të përbashkëta të privilegjuara,
• fjala kyçe LEJOHET në gjuhën e pyetjes.

Mekanizmi është krijuar për të kufizuar hyrjen në të dhënat e tabelës së objekteve të meta të dhënave sipas kushteve arbitrare të vendosura në vlerat e fushave të rreshtave të këtyre tabelave. Për shembull, për të parë të dhënat vetëm për palët, organizatat "tuaja", etj.

Zbatimi teknik i kufizimeve të hyrjes në 1C

1C gjeneron një kërkesë për DBMS. Grupimi i serverit shton një seksion WHERE në kërkesë, i cili përmban tekstin e kushtit për kufizimin e aksesit nga RLS, më pas kjo kërkesë dërgohet në DBMS, të dhënat e nxjerra i kthehen klientit 1C.

Ky mekanizëm do të funksionojë për çdo kërkesë nga klienti:

• në raportet
• në listat dinamike dhe format e listave të rregullta
• në kërkesa të rastësishme.

Një zbatim i tillë i mekanizmit ndikon shumë në performancën.

Mënyrat për të anashkaluar kufizimet e aksesit.

Në operacione të mëdha me burime intensive (për shembull, përpunimi i ripostimit të dokumenteve), një pjesë e kodit mund të zhvendoset në module të privilegjuara.

A) modul i privilegjuar është një modul i përbashkët me flamurin "I privilegjuar" në prona.

E veçanta e tij qëndron në faktin se kodi në të ekzekutohet pa asnjë kontroll aksesi, përfshirë RLS.

B) gjithashtu të privilegjuar modaliteti mund të aktivizohet për modulet e objektit të dokumentit. Kjo bëhet në pronat e dokumentit, flamuri

• Modaliteti i privilegjuar kur mbani
• Modaliteti i privilegjuar kur anuloni planin

C) Metoda SetPrivilegedMode()

Një komandë sistemi që ju lejon të bëni një pjesë të kodit të çdo moduli të privilegjuar.

Nga rreshti tjetër i kodit, mënyra e privilegjuar e ekzekutimit do të jetë në fuqi.

Ai do të veprojë deri në vijën për çaktivizimin e këtij modaliteti ose deri në fund të procedurës / funksionit

(E vërtetë);

// çdo kod këtu do të ekzekutohet pa kontroll të të drejtave dhe RLS

SetPrivilegedMode(Gënjeshtra); // ose fundi i procedurës / funksionit

Numri i aktivizimeve të modalitetit të privilegjuar duhet të përputhet me numrin e çaktivizimeve. Megjithatë, nëse modaliteti i privilegjuar është aktivizuar (një ose më shumë) brenda një procedure ose funksioni, por nuk është çaktivizuar, sistemi do të kryejë automatikisht mbylljen aq herë sa ka pasur aktivizime në pritje në procedurë ose funksion që braktiset.

Nëse në një procedurë ose metodë funksioni thërret SetPrivilegedMode(E rreme) më shumë se thirrjet e bëra me metodë SetPrivilegedMode(e vërtetë) atëherë do të hidhet një përjashtim

Funksioni Modaliteti i privilegjuar() kthen True nëse modaliteti i privilegjuar është ende i aktivizuar dhe False nëse modaliteti i privilegjuar është plotësisht i çaktivizuar. Ai nuk analizon numrin e cilësimeve të modalitetit të privilegjuar në një funksion të caktuar.

Të gjitha procedurat dhe funksionet e thirrura do të ekzekutohen gjithashtu në modalitetin e privilegjuar.

Është gjithashtu e mundur të filloni një seancë të privilegjuar. Ky është një seancë në të cilën modaliteti i privilegjuar vendoset që në fillim të sistemit. Në të njëjtën kohë, gjatë funksionimit, metoda Modaliteti i privilegjuar() gjithmonë do të kthejë True, dhe aftësia për të çaktivizuar modalitetin e privilegjuar nuk mbështetet. Vetëm një përdorues me të drejta administrative (e drejta e administrimit) mund të fillojë një sesion të privilegjuar. Sesioni mund të fillohet duke përdorur çelësin e linjës së komandës për lëshimin e aplikacionit të klientit UsePrivilegedMode ose parametrin e vargut të lidhjes së bazës së informacionit prmod.

Natyrisht lind pyetja: Pse, atëherë, të vendosen fare kufizime aksesi, nëse ato mund të anashkalohen kaq lehtë?

Modaliteti i sigurt.

Po, është e mundur të shkruhet përpunimi i jashtëm me modalitetin e ekzekutimit të privilegjuar dhe të shkarkohen/korruptohen të dhënat. Për të parandaluar këtë, sistemi ka një metodë të kontekstit global

Cakto SafeMode().

Modaliteti i sigurt, ndër të tjera, injoron modalitetin e privilegjuar.

Duhet të vendoset përpara se të telefononi në mënyrë programore mbajtës të jashtëm ose të eksportoni procedura dhe funksione nga modulet e tyre.

Hedh një përjashtim kur kryen operacione të ndaluara në kohën e ekzekutimit.

Për më tepër, për përdoruesit, mund të çaktivizoni aftësinë për të nisur në mënyrë interaktive raporte të jashtme dhe përpunim në nivelin e cilësimeve të roleve.

Cilësimi i kufizimit të aksesit

RLS mund të konfigurohet vetëm për të drejtat:

• lexim (zgjidh)
• duke shtuar (fut)
• ndryshim (përditësim)
• fshirje (fshij)

Për operacionet e leximit dhe fshirjes, objekti në bazën e të dhënave duhet të përputhet me kufizimin e aksesit të të dhënave.

Për operacionin e shtimit kufizimi i aksesit të të dhënave duhet të korrespondojë me objektin që planifikohet të shkruhet në bazën e të dhënave.

Për operacionin e ndryshimit Kufizimi i aksesit të të dhënave duhet të përputhet me objektin si përpara ndryshimit (që objekti të lexohet) ashtu edhe pas ndryshimit (që objekti të shkruhet).

Për të gjitha të drejtat e tjera, ky opsion nuk është i disponueshëm.

Le të shtojmë një kufizim të ri për të drejtën e "leximit" të librit të referencës "Nomenklatura". Do të hapet një listë e fushave për të cilat mund të konfiguroni kufizimin e shtuar.

Kjo do të thotë që nëse përpiqeni të hyni në fushat me kuti të kontrollit, kufizimi do të funksionojë, dhe nëse përpiqeni të hyni në fushat e pakontrolluara, kufizimi nuk do të funksionojë.

Nëse zgjidhni flamurin Fusha të tjera”, kufizimi do të vendoset për të gjitha fushat e tabelës, me përjashtim të fushave për të cilat kufizimet janë vendosur në mënyrë eksplicite.

*Veçori: për të drejtat për të shtuar, ndryshuar, fshirë:

• Kufizimi mund të konfigurohet vetëm për të gjitha fushat.
• Mund të ketë vetëm një kufi.

Për të drejtën "Lexo", mund të vendosni disa kushte, ato do të kombinohen me operatorin logjik "AND".

Në kufizimet për objektet e bazës së të dhënave të llojeve të mëposhtme, jo të gjitha fushat e objektit kryesor të të dhënave të kufizimit mund të përdoren:

• në regjistrat e akumulimit, kufizimet e aksesit mund të përmbajnë vetëm matje të objektit kryesor të kufizimit;
• në regjistrat kontabël në kufizime, mund të përdorni vetëm matjet e bilancit të objektit kryesor të kufizimit

Nëse, në kushtet e aksesit të kufizuar në të dhënat e regjistrit të qarkullimit të akumulimit, përdoren matje që nuk përfshihen në total, atëherë kur hyni në tabelën e qarkullimit virtual, totalet e ruajtura nuk përdoren dhe pyetja ekzekutohet plotësisht sipas në tryezën e lëvizjes.

Mekanizmi për vendosjen e kufizimeve të aksesit.

Çdo operacion mbi të dhënat e ruajtura në bazën e të dhënave në 1C: Enterprise përfundimisht rezulton në hyrjen në bazën e të dhënave me një kërkesë për të lexuar ose modifikuar të dhënat. Gjatë ekzekutimit të pyetjeve në bazën e të dhënave, mekanizmat e brendshëm të 1C: Enterprise vendosin kufizime aksesi. ku:

• Është formuar lista e të drejtave(lexo, shto, përditëso, fshi), një listë e tabelave të bazës së të dhënave dhe një listë fushash të përdorura nga kjo pyetje.
• Nga të gjitha rolet e përdoruesit aktual zgjidhni kufizimet e hyrjes te të dhënat për të gjitha të drejtat, tabelat dhe fushat e përfshira në kërkesë. Për më tepër, nëse ndonjë rol nuk përmban kufizime aksesi në të dhënat e ndonjë tabele ose fushe, atëherë kjo do të thotë që vlerat e fushave të kërkuara nga çdo rekord janë të disponueshme në këtë tabelë. Me fjalë të tjera, mungesa e një kufizimi të aksesit të të dhënave do të thotë se ekziston një kufizim WHERE True.
• Merrni vlerat aktuale të të gjithë parametrave të sesionit dhe opsioneve funksionale duke marrë pjesë në kufizimet e zgjedhura.

Marrja e vlerës së një parametri sesioni ose opsioni funksional nuk kërkon që përdoruesi aktual të ketë të drejtën për të marrë atë vlerë. Megjithatë, nëse vlera e disa parametrave të sesionit nuk është vendosur, atëherë do të ndodhë një gabim dhe pyetja e bazës së të dhënave nuk do të ekzekutohet.

Kufizimet që rrjedhin nga i njëjti rol kombinohen me një operacion AND.

Kufizimet e marra nga role të ndryshme kombinohen me operacionin OR.

Kushtet e ndërtuara u shtohen pyetjeve SQL me të cilat 1C: Enterprise akseson DBMS. Kur aksesoni të dhënat nga ana e kushteve të kufizimit të aksesit, nuk kryhet asnjë kontroll i të drejtave (as objekteve të meta të dhënave, as objekteve të bazës së të dhënave). Për më tepër, mekanizmi për shtimin e kushteve varet nga mënyra e zgjedhur e funksionimit të kufizimeve "të gjitha" ose "të lejuara".

*Karakteristika: Nëse një përdorues ka akses në disa role me kufizime të konfiguruara në nivelin e regjistrimeve në një objekt, atëherë në këtë rast kushtet e kufizimeve shtohen nga operacioni logjik "OR". Me fjalë të tjera, lejet e përdoruesit janë kumulative.

Kjo çon në përfundimin e mëposhtëm: mos lejoni që kushti i kufizimit të aksesit në një objekt në role të ndryshme të kryqëzohet, sepse në këtë rast teksti i pyetjes do të bëhet shumë më i ndërlikuar dhe kjo do të ndikojë në performancën.

Gjithë rrugës.

Kur vendosen kufizime duke përdorur metodën "të gjitha", kushtet dhe fushat shtohen në pyetjet SQL në mënyrë që 1C: Enterprise të mund të marrë informacion nëse të dhënat që janë të ndaluara për përdoruesin e caktuar janë përdorur në procesin e ekzekutimit të një pyetjeje të bazës së të dhënave apo jo . Nëse janë përdorur të dhëna të ndaluara, atëherë kërkesa ndërpritet për shkak të shkeljes së aksesit.

Vendosja e kufizimeve të aksesit me metodën "të gjithë" tregohet skematikisht në figurë:

Metoda "e lejuar".

Kur vendosen kufizime duke përdorur metodën "e lejuar", kushte të tilla shtohen në pyetjet SQL në mënyrë që hyrjet e ndaluara për përdoruesin aktual të mos ndikojnë në rezultatin e pyetjes. Me fjalë të tjera, kur vendosen kufizime në modalitetin "e lejuar", regjistrimet e ndaluara për këtë përdorues konsiderohen të munguara dhe nuk ndikojnë në rezultatin e operacionit, i cili tregohet skematikisht në figurë:

Kufizimet e aksesit të të dhënave vendosen në objektet e bazës së të dhënave kur 1C: Enterprise hyn në bazën e të dhënave.

Në versionin klient-server të 1C:Enterprise, kufizimet zbatohen në serverin 1C:Enterprise.

Megjithatë, ky opsion (LEJOHET) nuk do të funksionojë nëse i referohemi një tabele në pyetje për të cilën nuk janë konfiguruar kufizimet e aksesit, por në të cilën ka lidhje me rreshtat e tabelës me kufizime të konfiguruara. Në këtë rast, rezultati i pyetjes do të jetë "<Объект не найден>……” në vend të vlerës së fushës së referencës.

Nëse jeni duke zhvilluar një raport ose duke përpunuar duke përdorur pyetje të përgjithshme ose të personalizuara të konfigurimit, kontrolloni gjithmonë flamurin "E lejuar". që raporti të funksionojë nën çdo përdorues me çdo grup të drejtash.

Në rastin e të dhënave të leximit të objekteve nga baza e të dhënave, nuk është e mundur të vendoset flamuri "Lejohet". Prandaj, është e nevojshme konfiguroni zgjedhjet për leximin e objekteve, duke marrë parasysh kufizimet e mundshme në të drejtat e aksesit për përdoruesin. Nuk ka mjete për të marrë vetëm të dhëna të lejuara në teknologjinë e objektit.

Është e rëndësishme që nëse fjala kyçe E LEJUAR nuk është e specifikuar në një pyetje, atëherë të gjithë filtrat e specifikuar në atë pyetje nuk duhet të bien ndesh me asnjë nga kufizimet në leximin e objekteve të bazës së të dhënave të përdorura në pyetje. Për më tepër, nëse në pyetje përdoren tabela virtuale, atëherë filtrat përkatës duhet të vendosen në vetë tabelat virtuale.

Praktika 1. Ndërtuesi i pyetjeve në cilësimet RLS.

Le të kompozojmë tekstin e seksionit "KU" në pyetjen e drejtorisë. Ju mund të përdorni ndërtuesin e pyetjeve.
Konstruktori është i cunguar.

Skeda "Tabelat"

Tabela kryesore do të jetë tabela e objektit për të cilin po konfigurohet kufizimi.

Ju gjithashtu mund të zgjidhni tabela të tjera dhe të vendosni marrëdhënie të ndryshme midis tyre në skedën "Marrëdhëniet".

Skeda e kushteve

Këtu mund të konfiguroni kushtet aktuale për kufizimin e aksesit.

Le të shtojmë kushte për atributin "Çmimi" të drejtorisë së listës së aksioneve për të drejtën për "lexim" në të gjitha fushat e tabelës.

"Nomenklatura WHERE Nomenklatura. Çmimi > 500"

Le të shohim se si funksionon ky rregull i thjeshtë. Tabela e referencës përmban elementët e mëposhtëm:

Pas vendosjes së kufizimit të hyrjes, tabela do të tregojë vetëm elementët që plotësojnë kushtin:

Grupet gjithashtu janë zhdukur. Ndryshoni tekstin e kufizimit

"Nomenklatura WHERE Nomenklatura. Cmimi > 500

OSE Nomenklatura. Ky është një grup"

Epo, tani ja çfarë ju nevojitet.

Nëse hiqni shfaqjen e fushës "kodi" në cilësimet e listës, do të shfaqen të gjithë elementët e drejtorisë, d.m.th. kufizimi nuk funksionoi. Nëse vendosni shfaqjen e fushës "Kodi", kufizimi do të funksionojë.

Në të njëjtën kohë, përkundër faktit se elementi i kërkimit është i dukshëm në fushën e listës, forma e tij nuk mund të hapet, sepse është vendosur një kufizim në atributin. E njëjta gjë në një kërkesë arbitrare: kur përpiqeni të merrni një atribut "të kufizuar", do të ketë një gabim aksesi.

Nëse përpiqeni të merrni në mënyrë programore elementet "të kufizuara", do të shfaqet gjithashtu një gabim aksesi.

Për më tepër, do të jetë e pamundur të qaseni në ndonjë fushë të objektit përmes një lidhjeje, sepse kur merret një lidhje, sistemi lexon të gjithë objektin dhe nëse ka detaje "të kufizuara", objekti nuk do të lexohet.

Prandaj, kur punoni me objekte të bazës së të dhënave në mënyrë programore, duhet të keni parasysh kufizimet e mundshme në nivelin e regjistrimit dhe të merrni të gjitha të dhënat e nevojshme të objektit me një pyetje dhe më pas t'i vendosni ato në një strukturë ose të ekzekutoni një pjesë të kodit në një modul të privilegjuar.

Pas vendosjes së kufizimit të hyrjes, shfaqja e rreshtit në listën e të drejtave ndryshoi - u bë gri dhe u shfaq një ikonë.

Kufizimet e konfigurimit të aksesit (RLS).

• Nuk ka seksion përmbledhës;
• Nuk mund të aksesoni tabelat e regjistrave virtualë;
• Ju nuk mund të përdorni në mënyrë të qartë parametrat;
• Nënpyetjet mund të përdoren any>/span> lehtësirat e gjuhës së pyetjes, përveç:
  • operatori NË HIERARKI;
  • ofron REZULTATET;
  • rezultatet e pyetjeve të ndërlidhura nuk duhet të përmbajë pjesë tabelare>/span>;
  • tabelat virtuale, në veçanti Bilancet dhe Qarkullimet

Praktika 2. Nomenklatura me çmimin aktual.

Bëni një kufizim aksesi nëse keni nevojë të shfaqni një artikull me çmimin aktual më të madh se një vlerë e caktuar, për shembull, 100.

Zgjidhja:

Ne shtojmë një rregull të ri të kufizimit të aksesit për librin e referencës "Nomenklaturë" për të drejtën "lexo".
Zgjidhni "fusha të tjera".
Në konstruktor, shtoni një pyetje të ndërthurur. Në të, zgjidhni tabelën e regjistrit të informacionit "Çmimet e artikujve".
Nuk ka asnjë skedë "porosi" - kjo është një veçori e ndërtuesit të pyetjeve për ndërtimin e një pyetjeje të kufizimit të aksesit.
Në skedën "Advanced", vendosni "first 999999999", skeda "porosia" është shfaqur.
Vendosni renditjen sipas fushës "Periudha" në rend zbritës.
Më pas vendosim lidhjen e tabelës kryesore me nënpyetësin me referencë.

Modelet e kufizimit të aksesit.

Praktika 3. Kufizimi për "kontraktorët" sipas vlerës në një konstante.

Vendosni kufizimin e hyrjes për direktorinë Counterparties sipas vlerës së ruajtur në Constant.

Përveç kësaj, duhet të vendosni një kufizim për të gjitha objektet që përdorin direktorinë "Kontraktorët" në detaje.

Zgjidhje

Për librin e referencës "Llogaritë", për të drejtën "lexo", ne do të vendosim një kufizim duke shtuar një pyetje të ndërthurur në konstante në seksionin "Kushtet". Mos harroni këtë Grup.

Ne e shohim problemin, drejtoria Counterparties është filtruar saktë dhe shfaqen të gjitha dokumentet me atributin "Counterparty", disa me lidhje "të prishura" në atributin "Counterparty".

Tani ju duhet të konfiguroni kufizimin e hyrjes për të gjitha objektet duke përdorur lidhjen te "Llogaritë". Le t'i gjejmë me shërbimin "kërkoni lidhje me një objekt".

Le të kopjojmë dhe modifikojmë pak tekstin e kushtit RLS nga direktoria "Counterparties". Kjo duhet të bëhet aq herë sa gjenden objekte.

Ose përdorni modelin e kufizimit të aksesit për të shmangur problemet e dyfishimit të kodit.

Modelet e kufizimit të aksesit janë konfiguruar në nivelin e rolit dhe mund të përdoren për çdo objekt brenda rolit të redaktuar.

Mund të vendosni çdo pjesë të tekstit të kufizimit të aksesit në shabllon. Modeli thirret përmes simbolit "#". Për shembull, #TemplateContractor.

Nëpërmjet # në 1C, udhëzimet i shkruhen paraprocesorit. Në kontekstin e ekzekutimit të cilësimeve të kufizimit të aksesit, platforma zëvendëson tekstin e thirrjes së shabllonit me tekstin e shabllonit.

Le ta zhvendosim tekstin pas fjalës WHERE në shabllonin "TemplateContractor", përveç tekstit për ThisGroup.

Parametrat në shabllonet e kufizimit të aksesit.

Le të vazhdojmë të zgjidhim problemin 2.

Problemi tani është se tabela kryesore në drejtori quhet "kundërpalë", në dokumentin "Faturë". Fusha e kontrolluar në drejtori quhet "lidhje", në dokument - "Kontraparti".

Ndrysho emrin e tabelës kryesore në tekstin e shabllonit në "#CurrentTable"

"#CurrentTable" është një parametër i paracaktuar.

Dhe përmes pikës tregojmë numrin e parametrit të hyrjes - “.#Parameter(1)

"#Parameter" është gjithashtu një vlerë e paracaktuar. Mund të përmbajë një numër arbitrar parametrash hyrës. Ato referohen me numrin serial.

Në tekstin e kufizimit të hyrjes për drejtorinë, ne tregojmë sa vijon:

Për dokumentin si më poshtë:

“Shitja e mallrave WHERE #TemplateContractor(“Kontraktori”)”

Kur thërrisni shabllonin e kufizimit të aksesit, parametrat duhet t'i kalojnë atij vetëm si varg, d.m.th. në thonjëza.

Tabela kryesore - Nomenklatura

Teksti i shabllonit është:

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

Teksti i shabllonit përmban një pjesë të tekstit në gjuhën e kufizimit të aksesit të të dhënave dhe mund të përmbajë parametra që theksohen me simbolin "#".

Karakteri "#" mund të ndiqet nga:

• Një nga fjalët kyçe:
  • Një parametër i ndjekur nga numri i parametrit në shabllonin në kllapa;
  • CurrentTable - nënkupton futjen në tekst të emrit të plotë të tabelës për të cilën po ndërtohet kufizimi;
  • Emri aktual i tabelës– tregon futjen në tekst të emrit të plotë të tabelës (si vlerë vargu, në thonjëza) në të cilën zbatohet udhëzimi, në versionin aktual të gjuhës së integruar;
  • EmriCurrentPermission– përmban emrin e së drejtës për të cilën kryhet kufizimi aktual: LEXO/LEXO, SHTO/INSERT, MODIFIKO/UPDATE, FSHI/FSHI;
• emri i parametrit shabllon – nënkupton futjen e kufizimit të parametrit përkatës të shabllonit në tekst;
• simboli "#" - tregon futjen e një simboli të vetëm "#" në tekst.

Një shprehje e kufizimit të aksesit mund të përmbajë:

• Modeli i kufizimit të aksesit, i cili specifikohet në format #TemplateName("Vlera e parametrit të shabllonit 1", "Vlera e parametrit të shabllonit 2",...). Çdo parametër shabllon është i mbyllur në thonjëza të dyfishta. Nëse duhet të specifikoni një karakter thonjëza të dyfishtë në tekstin e parametrit, përdorni dy thonjëza të dyfishta.
• Funksioni StrContains (ku po kërkojmë, çfarë po kërkojmë). Funksioni është krijuar për të kërkuar për një ndodhi të WhatLooking for në vargun WhereLooking for. Kthen "E vërtetë" nëse gjendet përputhja, e gabuar përndryshe.
• Operatori + për lidhjen e vargjeve.

Për lehtësinë e redaktimit të tekstit të shabllonit, në skedën Modelet e kufizimit në formën e roleve, klikoni butonin Vendos tekstin e shabllonit. Në dialogun që hapet, futni tekstin e shabllonit dhe klikoni OK.

Ato nuk mund të instalohen duke përdorur setParameter () apo diçka të ngjashme.

Në këtë rast, parametrat janë:

• Opsionet e sesionit
• Opsionet Funksionale

Leximi i parametrave të sesionit në një kërkesë për kufizim aksesi ndodh në një mënyrë të privilegjuar, d.m.th. pa kontroll të të drejtave për të vepruar me to.

Praktika 4. Qasja tek palët “tuaj”.

Është e nevojshme të vendoset kufizimi i aksesit të përdoruesit aktual në palët "e tyre".

Ekziston një direktori "Përdoruesit", një drejtori "Kundërpalët", dokumente me "Kundërpartinë" e nevojshme.

Përdoruesi aktual duhet të shohë të dhëna vetëm për ato palë për të cilat është krijuar një lidhje me të.

Komunikimi gjithashtu duhet të konfigurohet.

Opsionet e mundshme:

Krijimi i lidhjeve përdorues + palë

• Detajet në dosjen e palëve
• Regjistri i informacionit

Zgjidhjet e mundshme për problemin:

• Ruajtja e përdoruesit në një konstante është një opsion i keq, konstanta është e disponueshme për të gjithë përdoruesit.
• Mbajtja e një grupi fiks të palëve të përdoruesit aktual në parametrat e sesionit nuk është një opsion i mirë, mund të ketë shumë palë
• Ruani në parametrat e sesionit të përdoruesit aktual, më pas kërkoni të merrni një listë të palëve "të tij" - një opsion i pranueshëm.
• Opsione të tjera.

Zgjidhje.

Le të krijojmë një parametër të ri sesioni "CurrentUser" dhe të shkruajmë plotësimin e tij në modulin e sesionit.

Le të krijojmë një regjistër informacioni "Korrespondenca e menaxherëve dhe palëve"

Le të krijojmë një rol të ri dhe në të një kufizim të ri aksesi për dokumentin "Fatura e marrjes".

Në tekstin e pyetjes, ne do të lidhim tabelën kryesore me regjistrin e informacionit nga Kontraktori = Kontraktori dhe Menaxheri = &Përdoruesi aktual. Lloji i lidhjes Brendshme.

Nëse është e mundur, është më mirë të shmangni pyetjet e mbivendosura në tekstet e kufizimit të aksesit, sepse ai do të ekzekutohet sa herë që të dhënat nga ky objekt lexohen nga baza e të dhënave.

Ne kontrollojmë - kufizimet funksionojnë

* Veçori: Nëse ndryshoni listën e palëve të tjera të përdoruesit në regjistër, kufizimet e aksesit do të hyjnë në fuqi menjëherë pa rifilluar sesionin e përdoruesit.

Praktika 5. Nuk ka ndryshim datë.

Është e nevojshme të zbatohet kufizimi për redaktimin e të dhënave më herët se data e caktuar për ndalimin e ndryshimeve.
Përdoruesit duhet të jenë të kufizuar.

Le të krijojmë një regjistër informacioni "ChangeBarDateDate" me dimensionin User, RestrictedDate burim.

Le të ndërtojmë logjikën e zgjidhjes në këtë mënyrë:

• nëse përdoruesi nuk është i specifikuar, atëherë ndalimi vlen për të gjithë përdoruesit
• nëse ka një kufizim për të gjithë përdoruesit dhe një kufizim për një përdorues specifik, atëherë ka një kufizim për një përdorues specifik, dhe për pjesën tjetër sipas parimit të përgjithshëm.

Natyrisht, një kufi i tillë mund të konfigurohet për objektet e bazës së të dhënave që kanë një pozicion të caktuar në boshtin e kohës. Ajo mund të jetë

• Dokumentacioni
• Regjistrat e informacionit periodik

Le të krijojmë një rol të ri "RestrictionsBy ChangeProhibitionDate".

Në të, për dokumentin "Faturë Fatura" për "ndryshimin" e duhur do të shtojmë një kufizim të ri aksesi.

Cilësimi është specifikuar për të gjitha fushat.

Teksti i kufizimit është:

Faturë Fatura NGA Dokumenti Faturë Fatura AS Faturë Faturë

Ndrysho Datat e ndalimit.Data e ndalimit AS Data e ndalimit
NGA

BASHKIMI I BRENDSHËM (ZGJEDH
MAXIMUM(ChangeProhibitionDate.User) AS Përdorues
NGA
Regjistri i Informacionit Datat e Ndalimit të Ndryshimeve SI Data e Ndalimit të Ndryshimeve
KU
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS Nënpyetje
Fatura e faturës.Data > NestedRequest.BanDate

Ne kontrollojmë - kufizimi funksionon.

Përdorimi i udhëzimeve të paraprocesorit

#Nëse Kushti 1 #Atëherë

Kërkoni fragmentin 1

#ElseIf Condition2 #Atëherë

Kërkoni fragmentin 2

#Përndryshe

Kërkoni fragmentin 3

#FundNëse

Në kushte, mund të përdorni operacione logjike (dhe. ose, jo, etj.) dhe akses në parametrat e sesionit.

Kjo qasje në kontekstin e kufizimeve të aksesit të ndërtimit është e përshtatshme sepse, në varësi të kushteve, do të përpilohet një tekst më i shkurtër pyetës. Një kërkesë më e thjeshtë e ngarkon sistemin më pak.

Ana negative është se konstruktori i pyetjeve nuk do të funksionojë me tekst të tillë.

* Veçori:

Ndryshe nga udhëzimet për paraprocesorin 1C:Enterprise në tekstet e kufizimit të aksesit, paraprini operatorit Pastaj me një shenjë hash — #Then

Praktikoni 6. Ndërroni "Përdor RLS"

Le të plotësojmë sistemin tonë të kufizimeve me një ndërprerës që mundëson/çaktivizon përdorimin e kufizimeve në nivel rekord.

Për ta bërë këtë, shtoni një konstant dhe një parametër sesioni të quajtur "UseRLS".

Le të shkruajmë në Session Module vendosjen e vlerës së parametrit të sesionit nga vlera e konstantës.

Shtoni kodin e mëposhtëm në të gjitha tekstet e kufizimit të aksesit:

"#If &UseRLS #Atëherë….. #EndNëse"

Ne kontrollojmë - gjithçka funksionon.

Megjithatë, tani pas ndezjes së flamurit "përdor radar", ndryshimet nuk do të hyjnë në fuqi menjëherë. Pse?

Sepse parametri i sesionit vendoset kur fillon sesioni.

Është e mundur të rivendoset parametri i sesionit kur shkruhet një vlerë e re konstante, por kjo do të funksionojë vetëm për sesionin aktual të përdoruesit. Përdoruesve të tjerë duhet t'u kërkohet të rinisin sistemin.

Fundi i pjesës së parë.

   

17 rregulla për përpilimin e një KËRKESË optimale për të dhënat e bazës së të dhënave 1C

Për të formuar dhe ekzekutuar pyetje në tabelat e bazës së të dhënave në platformën 1C, përdoret një objekt i veçantë i gjuhës programuese. Kërkesë. Ky objekt krijohet duke thirrur konstruktin Kërkesë e re. Është i përshtatshëm për të përdorur një pyetje kur ju duhet të merrni një përzgjedhje komplekse të dhënash, të grupuara dhe të renditura sipas nevojës. Një shembull klasik i përdorimit të një pyetësori është marrja e një përmbledhjeje të gjendjes së një regjistri akumulimi në një moment të caktuar kohor. Gjithashtu, mekanizmi i pyetjeve e bën të lehtë marrjen e informacionit në seksione të ndryshme kohore.

Teksti i kërkesës është udhëzimi sipas të cilit duhet të ekzekutohet kërkesa. Trupi i kërkesës përshkruan:

• tabelat e bazës së informacionit të përdorura si burime të të dhënave të pyetjeve;
• fushat e tabelës që duhet të përpunohen në pyetje;
• rregullat e grupimit;
• rezultatet e renditjes;
• etj.

Udhëzimi është përpiluar në një gjuhë të veçantë - gjuha e pyetjes dhe përbëhet nga pjesë të veçanta - seksione, fjali, fjalë kyçe, funksione, operatorë aritmetikë dhe logjikë, komente, konstante dhe parametra.

Gjuha e pyetjeve e platformës 1C është shumë e ngjashme me sintaksën e gjuhëve të tjera SQL, por ka dallime. Përparësitë kryesore të gjuhës së integruar të pyetjeve janë: çreferencimi i fushës, tabelat virtuale, puna e përshtatshme me totalet, fushat e pashtypura në pyetje.

Rekomandime për shkrimin e pyetjeve të bazës së të dhënave në gjuhën e pyetjeve të platformës 1C:

1) Trupi i kërkesës mund të përmbajë të dhëna konfigurimi të paracaktuara si:

• vlerat enum;
• të dhëna të paracaktuara:
• drejtoritë;
• planet e llojeve të karakteristikave;
• skemat e llogarive;
• planet për llojet e llogaritjeve;
• lidhje boshe;
• vlerat e pikave të rrugës së proceseve të biznesit.

Gjithashtu, teksti i kërkesës mund të përmbajë vlera të numërimit të sistemit që mund t'u caktohen fushave në tabelat e bazës së të dhënave: AccumulationMotionType, AccountType dhe AccountingMovementType. Kërkesat i referohen të dhënave të paracaktuara të konfigurimit dhe vlerave të numërimit të sistemit duke përdorur një fjalë për fjalë të llojit të funksionit VALUE. Kjo fjalë për fjalë përmirëson lexueshmërinë e pyetjes dhe zvogëlon numrin e parametrave të pyetjes.

Një shembull i përdorimit të një literal KUPTIMI:

• WHERE City = VALUE (Direktori. Qytetet. Moskë)
• WHERE City = VALUE (Referenca. Qytetet.Referenca e zbrazët)
• WHEREItemType = VALUE (Enumeration.ProductTypes.Service)
• WHEREMovementType = VALUE(MovementTypeAccumulation.Të ardhura)
• WHERE RoutePoint = VALUE(BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Përdorimi i udhëzimeve AUTO POROSI në një pyetje, koha e ekzekutimit të pyetjes mund të jetë shumë e lartë, kështu që nëse renditja nuk kërkohet, atëherë është më mirë të mos e përdorni fare. Në shumicën e rasteve, mënyra më e mirë për të aplikuar renditjen është me deklaratën NDAJ SIPAS.

Rregullimi automatik funksionon sipas parimeve të mëposhtme:

• Nëse klauzola ORDER BY është specifikuar në pyetje, atëherë çdo referencë për tabelën në këtë klauzolë do të zëvendësohet nga fushat me të cilat tabela është renditur si parazgjedhje (për drejtoritë, ky është kodi ose emri, për dokumentet, data të dokumentit). Nëse fusha e renditjes i referohet një drejtorie hierarkike, atëherë do të aplikohet renditja hierarkike sipas kësaj drejtorie.
• Nëse nuk ka klauzolë ORDER BY në pyetje, por ka një klauzolë TOTALS, atëherë rezultati i pyetjes do të renditet sipas fushave të pranishme në klauzolën RESULTS pas fjalës kyçe BY, në të njëjtën sekuencë dhe, nëse totalet janë llogaritur nga fushat - lidhjet, pastaj nga fushat e renditjes sipas parazgjedhjes së tabelave që janë referuar.
• Nëse nuk ka klauzola ORDER BY dhe TOTAL në pyetje, por ka një klauzolë GROUP BY, atëherë rezultati i pyetjes do të renditet sipas fushave të pranishme në fjali në të njëjtën sekuencë dhe, nëse grupimi është kryer sipas fushave - lidhjet, pastaj sipas paracaktimit të renditjes së fushave të tabelave që u referuan.
• Nëse pyetja nuk përmban klauzolat dhe ORDER BY, TOTAL dhe GROUP BY, rezultati do të renditet sipas fushave të renditjes së paracaktuar për tabelat nga të cilat janë zgjedhur të dhënat, sipas renditjes që shfaqen në pyetje.
• Nëse pyetja përmban klauzolën TOTAL, secili nivel i totaleve renditet veçmas.

3) Për të shmangur rikërkimin e bazës së të dhënave kur shfaqni rezultatin e pyetjes tek përdoruesi (për shembull, ndërtimi i një pyetjeje ose shfaqja e rezultatit të pyetjes duke përdorur një dokument spreadsheet), është e dobishme të përdorni udhëzimin LIDHJET E PARAQITJES A që ju lejon të merrni një paraqitje të një vlere referimi. Shembull:

Është gjithashtu e mundur të përdoret udhëzimi PERFORMANCA- projektuar për të marrë një paraqitje të vargut të një vlere të një lloji arbitrar. Dallimi midis këtyre udhëzimeve është se në rastin e parë, nëse udhëzimet kalojnë një referencë, rezultati do të jetë një varg, ndërsa në raste të tjera, rezultati do të jetë vlera e parametrit të kaluar. Në rastin e dytë, rezultati i udhëzimit do të jetë gjithmonë një varg!

4) Nëse pyetja përmban një fushë me një lloj të përbërë, atëherë për fusha të tilla bëhet e nevojshme të hidhni vlerat e fushës në një lloj specifik duke përdorur udhëzimin EXPRESS, i cili do t'ju lejojë të hiqni tabelat e panevojshme nga lidhja e majtë me një fushë të një lloji të të dhënave të përbëra dhe të shpejtoni pyetjen. Shembull:

Ekziston një regjistër për grumbullimin e mbetjeve të mallrave, në të cilin fusha e Regjistrimit ka një tip të përbërë. Në kërkesë zgjidhen Data dhe Numri i dokumenteve të Pranimit të Mallrave, ndërsa qasja në detajet e dokumentit përmes fushës së Regjistruesit nuk rezulton me shumë lidhje të majta të tabelës së regjistrit të akumulimit me tabelat e dokumenteve të regjistrit.

Kodi 1C v 8.x SELECT
EXPRESS(Mbetjet e Mallrave. Dokumenti i Regjistruesit AS. Pranimi i Mallrave).Numri AS Numri i Faturës,
EXPRESS(Mbetjet e Mallrave. Dokumenti i Regjistruesit AS. Pranimi i Mallrave).Data AS Data e pranimit
NGA
Regjistri i Akumulimit.Mbetjet e Mallrave AS Mbetjet e Mallrave

Nëse cast-i konsiderohet jo i realizueshëm, atëherë rezultati i castit është vlera I PAVLEFSHËM.

5) Mos harroni për udhëzimet LEJOHET, që do të thotë se pyetja do të zgjedhë vetëm regjistrimet për të cilat përdoruesi aktual ka leje. Nëse kjo fjalë nuk është e specifikuar, atëherë në rastin kur pyetja zgjedh regjistrime për të cilat përdoruesi nuk ka të drejta, pyetja do të funksionojë me një gabim.

6) Nëse pyetja përdor një bashkim, dhe në disa pjesë të bashkimit ka tabela të mbivendosura (një dokument me një pjesë tabelare), dhe në disa nuk ka nevojë të plotësohet lista e përzgjedhjes me fusha - tabela të mbivendosura bosh. Kjo bëhet duke përdorur fjalën kyçe E Zbrazur, pas së cilës emërtimet e fushave nga të cilat do të përbëhet tabela e vendosur tregohen në kllapa. Shembull:

Kodi 1C v 8.x // Zgjidhni fushat Numri dhe Përbërja
// nga tabela virtuale Dokumenti.Faturë
ZGJIDHni Referencën.Numrin, TABELA E zbrazët.(Num, Tov, Sasia) SI PËRBËRJE
NGA Dokumenti.Fatura
BASHKONI TË GJITHA
ZGJIDH Lidhjen.Numrin, Përbërjen.(Numri i linjës, Produkti, Sasia)
NGA Dokumenti.Dokumenti i faturës.Fatura.Përbërja.*

7) Për të shmangur linjat e dyfishta në rezultatin e pyetjes, duhet të përdorni udhëzimin TË NDRYSHME, sepse është gjithnjë e më i qartë, dhe udhëzimi GRUP NGA përdoret për grupim duke përdorur funksionet agregate. Nga rruga, kur përdorni funksionet agregate, fjalia GRUP NGA mund të mos specifikohet fare, ndërsa të gjitha rezultatet e pyetjeve do të grupohen në një rresht të vetëm. Shembull:

Kodi 1C v 8.x // Është e nevojshme të zbulohet se cilat palë
// mallrat u dërguan për periudhën.
Zgjidhni Të ndryshme
Dokument.Faturë.Kontraktori

8) Udhëzim GRUP NGA ju lejon të aksesoni fushat e nivelit të lartë, pa grupuar rezultatet sipas këtyre fushave, nëse funksionet agregate aplikohen në fushat e një tabele të ndërlidhur. Megjithëse është shkruar në ndihmën 1C, kur gruponi rezultatet e pyetjes, funksionet e përgjithshme duhet të tregohen në listën e fushave të përzgjedhjes, dhe përveç funksioneve agregate, vetëm fushat me të cilat kryhet grupimi mund të tregohen në listën e përzgjedhjes. fusha. Shembull:

Kodi 1C v 8.x SELECT
Pranimi i Mallrave dhe Shërbimeve Mallrat (SHUMË (Sasia), Nomenklatura),
Pranimi i Mallrave dhe Shërbimeve. Link,
Pranimi i Mallrave dhe Shërbimeve
NGA
Dokument Pranimi i Mallrave dhe Shërbimeve SI Marrja e Mallrave dhe Shërbimeve
GRUP NGA
Pranimi i Mallrave dhe Shërbimeve Mallrat (Nomenklatura)

9) Udhëzim ËSHTË NULL synon të zëvendësojë vlerën I PAVLEFSHËM në një vlerë tjetër, por mos harroni se parametri i dytë do të konvertohet në llojin e të parit nëse lloji i parametrit të parë është një varg ose një numër.

10) Kur i referoheni tabelës kryesore, mund t'i referoheni të dhënave të tabelës së varur në kusht. Kjo veçori quhet çreferencimi i fushave të një nën-tabela.

Shembull (kërkoni për dokumente që përmbajnë një produkt të caktuar në seksionin tabelor):

Avantazhi i këtij pyetësori ndaj pyetjes në nëntabelën Incoming.Goods është se nëse ka dublikatë në dokumente, rezultati i pyetjes do të kthejë vetëm dokumente unike pa përdorur fjalën kyçe DISTINCT.

11) Një variant interesant i operatorit B është një kontroll i shfaqjes së një grupi të renditur në grupin e grupeve të tilla (Fusha1, Fusha2, ... , FushaN) B (Fusha1, Fusha2, ... , FushaN).

Kodi 1C v 8.x SELECT
Kontraktorët.Lidhja
KU
(Contractors.Link, Goods.Link)
(SELECT Shitje.Klient, Shitje.Produkt
NGA Regjistri i Akumulimit. Shitjet AS Shitje)
NGA
Drejtoria. Kundërpalët,
Drejtoria.Produktet

12) Përdorni tabelat e pyetjeve virtuale sa herë që është e mundur. Kur krijon një pyetje, sistemi ofron një numër tabelash virtuale si burime të dhënash - këto janë tabela që janë gjithashtu rezultat i një pyetjeje që sistemi gjeneron në kohën e ekzekutimit të seksionit përkatës të kodit.

Zhvilluesi mund të marrë në mënyrë të pavarur të njëjtat të dhëna që sistemi i ofron atij si tabela virtuale, megjithatë, algoritmi për marrjen e këtyre të dhënave nuk do të optimizohet, sepse:

Të gjitha tabelat virtuale janë të parametrizuara, pra zhvilluesit i jepet mundësia të vendosë disa parametra që sistemi do të përdorë kur gjeneron një kërkesë për të krijuar një tabelë virtuale. Në varësi të parametrave të tabelës virtuale të specifikuara nga zhvilluesi, sistemi mund të gjenerojë TË NDRYSHME pyetje për të marrë të njëjtën tabelë virtuale dhe ato do të optimizohen për sa i përket parametrave të kaluar.

Nuk është gjithmonë e mundur që një zhvillues të ketë akses në të dhënat në të cilat sistemi ka qasje.

13) Në mënyrën e funksionimit klient-server, funksioni SUBSTRING() zbatohet duke përdorur funksionin SUBSTRING() të deklaratës përkatëse SQL të kaluar në serverin e bazës së të dhënave SQL Server, i cili llogarit llojin e rezultatit të funksionit SUBSTRING() sipas rregullave komplekse në varësi të llojit dhe vlerave të parametrave të tij, si dhe në varësi të kontekstit në të cilin përdoret. Në shumicën e rasteve, këto rregulla nuk ndikojnë në ekzekutimin e një pyetjeje, por ka raste kur gjatësia maksimale e vargut të rezultatit e llogaritur nga SQL Server është thelbësore për ekzekutimin e pyetjes. Është e rëndësishme të kihet parasysh se në disa kontekste kur përdoret funksioni SUBSTRING(), gjatësia maksimale e rezultatit të tij mund të jetë e barabartë me gjatësinë maksimale të një vargu me gjatësi të kufizuar, që është 4000 karaktere në SQL Server. Kjo mund të çojë në një përplasje të papritur në ekzekutimin e pyetjes:

Ofruesi Microsoft OLE DB për SQL Server: Paralajmërim: Përpunuesi i pyetjeve nuk mund të prodhonte një plan pyetjesh nga optimizuesi sepse gjatësia totale e të gjitha kolonave në klauzolën GROUP BY ose ORDER BY tejkalon 8000 byte.

HRESULT=80040E14, SQLSTATE=42000, vendas=8618

14) Përdoreni me kujdes OSE në ndërtim KU, pasi përdorimi i një kushti me OR mund të "peshojë" ndjeshëm pyetjen. Problemi mund të zgjidhet me dizajn BASHKONI TË GJITHA. Shembull:

Kodi 1C v 8.x SELECT

NGA

KU
_DemoContractors.Lidhja =Lidhja1
BASHKONI TË GJITHA
ZGJIDHNI
_Demo Counterparties.NameFull
NGA
Drejtoria._DemoContractors SI _DemoContractors
KU
_DemoContractors.Lidhja =Lidhja2

15) Gjendja JO IN në ndërtim KU rrit kohën e ekzekutimit të kërkesës, pasi është një lloj JO (OR1 OSE2 ... OSE), kështu që për tavolina të mëdha përpiquni të përdorni LEFT JOIN me kusht IS NULL. Shembull:

Kodi 1C v 8.x SELECT
_DemoContractors.Lidhje
NGA
Drejtoria._DemoContractors SI _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Software _DemoContractors.Link = _BuyerDemoOrder.Contractor
KU
_Urdhërimi i Demontimit të Blerësit. Kundërpartia ËSHTË NULL

16) Kur përdorni Tavolina të përkohshme ju duhet të indeksoni gjendjen dhe të bashkoni fushat në këto tabela, POR, kur përdorni indekset, pyetja mund të funksionojë edhe më ngadalë. Prandaj, është e nevojshme të analizohet çdo pyetje me dhe pa indeks, të matet shpejtësia e ekzekutimit të pyetjes dhe të merret një vendim përfundimtar.

Nëse vendosni të dhëna në një tabelë të përkohshme që fillimisht është indeksuar në disa fusha, atëherë nuk do të ketë më një indeks në këto fusha në tabelën e përkohshme.

17) Nëse nuk e përdorni Menaxheri i tabelës së temperaturës, atëherë nuk ka nevojë të fshihet në mënyrë eksplicite tabela e përkohshme, ajo do të fshihet pasi të përfundojë ekzekutimi i pyetjes së grupit, përndryshe tabela e përkohshme duhet të fshihet në një nga mënyrat e mëposhtme: me komandë SHKATËRRON në kërkesë, thirrni metodën Menaxheri i përkohshëm i tabelës. Mbylle().

Dhe përveç videos nga Evgeny Gilev: Gabime tipike kur shkruani kërkesa për 1C: