20.09.2014

Există o directivă „Permis” în limbajul de interogare. Este destinat să fie utilizat de cadru pentru a filtra înregistrările la care utilizatorul nu are drepturi atunci când stabilește o limită la nivel de înregistrare a bazei de date.

S-ar părea că în interogări este mai bine să folosiți întotdeauna această directivă. Voi argumenta că nu este cazul. De asemenea, voi argumenta că, dacă este posibil, ar trebui să evitați să îl utilizați, de aceea.

Să presupunem că facem un raport asupra așezărilor reciproce ale indivizilor. Utilizatorul are drepturi la o singură organizație și există mai multe organizații în baza de date, iar restricția la nivel de înregistrare este activată în baza de date. De asemenea, baza de date are un registru „Decontări reciproce” cu dimensiunile „Organizare” și „Persoană fizică”. Dacă există o cerere în sistem

"Alege

Organizare,

Individual

și va fi executat în numele unui utilizator cu permisiunea unei organizații, apoi interogarea va eșua dacă există înregistrări ale altor organizații în acest registru. Va apărea o eroare, iar descrierea erorii va fi „Utilizatorul nu are drepturi suficiente pentru a finaliza solicitarea!” și acest lucru este adevărat, platforma nu trișează, deoarece nu are drepturi asupra înregistrărilor altor organizații din acest registru.

Ce să faci în acest caz, folosește directiva „Permis”? Nu merita dupa parerea mea. Trebuie doar să setați selecția în funcție de organizație, iar utilizatorul va putea genera un raport. Interogarea pentru un raport cu compoziția datelor va arăta astfel

"Alege

Organizare,

Individual

(Alege

Organizare

individual)

Din Registrul de acumulare.Decontari reciproce

(Unde

Organizare

individual)

Dacă utilizatorul execută o interogare pe tabel fără selecție, atunci raportul nu va fi generat, iar utilizatorul nu va recunoaște datele pentru alte organizații, iar dacă setează selecția pentru organizația sa, va genera datele corecte.

Puteți întreba din nou - „De ce nu ar trebui să utilizați directiva Permis”, aceasta impune imediat o selecție, salvează utilizatorul de mesajele de care nu are nevoie!

Răspunsul la această întrebare va fi următorul - cum în acest caz utilizatorul va ști că toate datele necesare au fost incluse în raport. Să presupunem că, mai devreme, acest utilizator a lucrat cu drepturi depline și a făcut o greșeală și a ales în document o persoană dintr-o altă organizație. Poate exista și o situație, datele au fost încărcate - și o subdiviziune a unei alte organizații a fost înregistrată în documentele organizației (în ZUP li se impun și restricții asupra proprietarului). În acest caz, directiva „Permis” va tăia datele interzise fără niciun mesaj către utilizator, iar acesta nu va ști că nu a fost inclus tot ce ar trebui să fie inclus în raport.

Prin urmare, nu este necesar să introduceți această directivă în masă în cererile de configurații tipice, considerând aceasta o greșeală. Este foarte descurajat să faceți acest lucru în cererile de raportare reglementate. De asemenea, nu faceți acest lucru în alte rapoarte și documente în care este necesară acuratețea informațiilor.

Dar cum poți evita în continuare eroarea de „cădere” a programului cu lipsă de drepturi?

Da, este foarte simplu, trebuie să utilizați comanda „Încercați”, iată un exemplu:

Atentat, încercare

Request.Execute();

Excepție

Raport(Descrierea erorii());

Sfârșitul încercării;

În rapoartele care utilizează ACS, codul programului pentru executarea raportului trebuie scris manual, tot printr-o încercare.

Ca urmare, utilizatorul nu va primi date incorecte și va primi un mesaj de eroare normal.

Vă puteți familiariza cu nuanțele setării RLS în diviziuni separate în articolul nostru.

). Utilizarea acestui cuvânt cheie evită o eroare la obținerea înregistrărilor pentru care utilizatorul nu are drepturi.

Problemă: În unele cazuri, rezultatul restricțiilor de acces la date din 1C 8.3 poate depinde de planul de interogare DBMS. Acest articol discută situații posibile și oferă recomandări despre cum să le evitați.

Problema posibilei dependențe a rezultatului restricțiilor de acces la date de planul de interogare DBMS poate apărea atunci când o interogare a bazei de date este executată fără cuvântul cheie PERMIS dacă există restricții de acces la date pentru utilizatorul curent și interogarea conține una sau mai multe comparații ale formularului:

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

Dacă în acest caz < > (interogare într-o interogare) folosește tabele de baze de date care sunt supuse restricțiilor de acces, atunci este posibil ca interogarea să fie executată cu succes pe unele SGBD, iar pe altele să fie emis un mesaj, cu condiția ca datele din bazele de informații să fie complet identice .

Obțineți 267 de lecții video 1C gratuit:

Motivul diferențelor

Posibila diferență de comportament se datorează implementării restricțiilor de acces la date fără cuvântul cheie PERMISîn 1C Enterprise 8.3.

Interogare fără un cuvânt cheie PERMIS va fi executat cu succes numai dacă în timpul executării sale nu există acces la date interzise. Pentru a face acest lucru, i se adaugă un câmp de semnal special, care ia valoarea Adevărat pentru acele înregistrări la formarea cărora au participat doar date permise și valoarea Minciună pentru toate celelalte intrări. Dacă cel puțin o înregistrare a selecției conține valoarea Minciunăîn câmpul de semnal, atunci interogarea se termină anormal.

Același câmp de semnal este adăugat la rezultatele interogărilor imbricate în comparație. ÎN/NU ÎN. Mai mult decât atât, verificarea valorii coloanei de semnal în acest caz se realizează prin intermediul SGBD. Astfel, dacă în procesul de executare a unei interogări imbricate a existat un acces la date interzise, ​​atunci executarea interogării ar trebui să se încheie cu o eroare Utilizatorul nu are drepturi suficiente pentru a efectua o operațiune în baza de date.

Cu toate acestea, atunci când se construiește un plan de interogare, este posibil ca SGBD să nu primească selecția completă <Вложенным запросом> și obțineți numai acele înregistrări care sunt de fapt necesare pentru a verifica starea ÎN/NU ÎN. În acest caz, interogarea poate reuși chiar dacă <Вложенного запроса> accesul la datele interzise poate apărea ca o solicitare independentă.

Să luăm în considerare un exemplu simplu. Lasă pe masă Director.Persoane fizice restricții de acces la date. In acest caz cererea este:

Tabel.Individ AS Individ

va fi executat cu o eroare din cauza unei încercări de a accesa date interzise. Dacă această interogare este implicată în comparație, de exemplu:

Tabel.Individ AS Individ

Director. Indivizi AS Tabel)

apoi, în funcție de planul de interogare selectat de SGBD, interogarea poate fi executată fie cu succes, fie cu o eroare. Acest comportament al solicitării nu este eronat, deoarece accesul la date interzise în timpul executării acestei solicitări poate sau nu să apară. Pentru a obține un rezultat mai previzibil, este necesar să construiți o interogare în așa fel încât interogarea imbricată să fie garantată să nu efectueze accesări la date în mod evident inutile. În special, dacă interogarea anterioară este rescrisă astfel:

Contract de prestare a muncii cu o persoană fizică.Salariat.Persoană fizică

Document. Contractul de executare a muncii cu o persoană fizică ca un acord de prestare a muncii cu o persoană fizică

Contract de executare a muncii cu o persoană fizică.Salariat.Persoană fizică B (

Tabel.Individ AS Individ

Director.Individuals AS Tabel

Limbajul de interogare este unul dintre mecanismele fundamentale ale 1C 8.3 pentru dezvoltatori. Cu ajutorul interogărilor, puteți obține rapid orice date stocate în baza de date. Sintaxa sa este foarte asemănătoare cu SQL, dar există unele diferențe.

Principalele avantaje ale limbajului de interogare 1C 8.3 (8.2) față de SQL:

• dereferențiarea câmpurilor de referință (întoarcerea unuia sau mai multor puncte în atributele obiectului);
• lucrul cu rezultatele este foarte convenabil;
• capacitatea de a crea tabele virtuale;
• cererea poate fi scrisă atât în ​​engleză, cât și în rusă;
• capacitatea de a bloca datele pentru a evita blocajele.

Dezavantajele limbajului de interogare în 1C:

• spre deosebire de SQL, interogările în 1C nu vă permit să schimbați datele;
• lipsa procedurilor stocate;
• imposibilitatea conversiei unui șir într-un număr.

Luați în considerare mini tutorialul nostru despre construcțiile de bază ale limbajului de interogare 1C.

Datorită faptului că solicitările din 1C vă permit doar să primiți date, orice solicitare trebuie să înceapă cu cuvântul „SELECT”. După această comandă, sunt indicate câmpurile din care doriți să obțineți date. Dacă specificați „*”, atunci toate câmpurile disponibile vor fi selectate. Locul de unde vor fi selectate datele (documente, registre, directoare etc.) este indicat după cuvântul „DIN”.

În exemplul de mai jos, numele întregii nomenclaturi sunt selectate din cartea de referință „Nomenclatură”. După cuvântul „CUM”, sunt indicate pseudonimele (numele) pentru tabele și câmpuri.

ALEGE
Nomenclatură.Nume AS NumeNomenclatură
DIN
Director.Nomenclatura AS Nomenclatura

Lângă comanda „SELECT”, puteți specifica cuvinte cheie:

• VARIAT. Interogarea va selecta numai rânduri care diferă în cel puțin un câmp (fără duplicate).
• Primul N, Unde n– numărul de rânduri de la începutul rezultatului care urmează să fie selectat. Cel mai adesea, această construcție este utilizată împreună cu sortarea (ORDER BY). De exemplu, atunci când trebuie să selectați un anumit număr de ultimele documente după dată.
• PERMIS. Acest design vă permite să selectați din baza de date numai acele înregistrări care sunt disponibile utilizatorului curent. Dacă se utilizează acest cuvânt cheie, utilizatorul va primi un mesaj de eroare dacă încearcă să interogheze înregistrările la care nu are acces.

Aceste cuvinte cheie pot fi folosite împreună sau separat.

PENTRU SCHIMBARE

Această clauză blochează datele pentru a evita conflictele. Datele blocate nu vor fi citite de la o altă conexiune până la sfârșitul tranzacției. În această clauză, puteți specifica anumite tabele pe care doriți să le blocați. În caz contrar, toate vor fi blocate. Designul este relevant doar pentru modul de blocare automată.

Cel mai adesea, clauza „PENTRU SCHIMBARE” este folosită la primirea soldurilor. Într-adevăr, atunci când mai mulți utilizatori lucrează în program în același timp, în timp ce unul primește soldurile, celălalt le poate schimba. În acest caz, soldul rezultat nu va mai fi corect. Dacă blocați datele cu această propunere, atunci până când primul angajat primește soldul corect și efectuează toate manipulările necesare cu acesta, al doilea angajat va trebui să aștepte.

ALEGE
Acorduri reciproce. Salariat,
Decontari reciproce Suma Decontari reciproce Sold
DIN
Registrul de acumulare Decontari reciproce CU Angajati Solduri AS Decontari reciproce
PENTRU SCHIMBARE

UNDE

Construcția este necesară pentru impunerea oricărei selecții asupra datelor descărcate. În unele cazuri de obținere a datelor din registre, este mai rezonabil să se prescrie condiții de selecție în parametrii tabelelor virtuale. Când utilizați „UNDE”, toate înregistrările sunt obținute mai întâi și abia apoi se aplică selecția, ceea ce încetinește semnificativ interogarea.

Următorul este un exemplu de solicitare de a obține persoane de contact cu o anumită poziție. Parametrul de selecție are următorul format: &ParameterName (numele parametrului este arbitrar).

SELECTARE (CAZ)

Construcția vă permite să specificați condiții direct în corpul cererii.

În exemplul de mai jos, „AdditionalField” va conține text în funcție de dacă documentul este postat sau nu:

ALEGE
AdmitereT&U.Link,
ALEGERE
CÂND
ATUNCI "Document postat!"
ELSE "Documentul nu a fost postat..."
TERMINAȚI CA SuplimentarField
DIN
Document.Reception of GoodsServices AS ReceiptT&C

A TE ALATURA

Unele leagă două tabele printr-o anumită condiție de legătură.

ALĂTURAȚI STÂNGA/DREAPTA

Esența îmbinării LEFT este aceea că primul tabel specificat este luat în întregime, iar al doilea este atașat de condiția conexiunii. Dacă nu există înregistrări care să corespundă primului tabel din al doilea, atunci NULL este înlocuit ca valorile lor. Mai simplu spus, tabelul principal este primul tabel specificat, iar datele celui de-al doilea tabel (dacă există) sunt deja înlocuite cu datele acestuia.

De exemplu, trebuie să obțineți articole din documentele „Recepție de bunuri și servicii” și prețuri din registrul de informații „Prețuri articole”. În acest caz, dacă prețul oricărei poziții nu este găsit, înlocuiți NULL. Toate articolele din document vor fi selectate indiferent dacă au un preț sau nu.

ALEGE
Chitanța Nomenclatorului T&U,
Preturi.Pret
DIN
Document.Receptie of GoodsServices.Goods AS ReceiptT&C
INNER JOIN
ON Primirea Q&A.Nomenclatura = Preturi.Nomenclatura

În DREAPTA, totul este exact invers.

CONEXIUNE COMPLETA

Acest tip de îmbinare diferă de cele anterioare prin faptul că toate înregistrările primului tabel și ale celui de-al doilea vor fi returnate ca rezultat. Dacă nu se găsesc înregistrări în primul sau al doilea tabel pentru condiția de legătură specificată, va fi returnat NULL.

Când utilizați îmbinarea completă în exemplul anterior, vor fi selectate toate articolele din documentul de primire a bunurilor și serviciilor și toate cele mai recente prețuri din registrul prețurilor articolelor. Valorile înregistrărilor negăsite, atât în ​​primul, cât și în cel de-al doilea tabel, vor fi NULL.

INNER JOIN

Diferența dintre o îmbinare INNER și o îmbinare COMPLETĂ este că, dacă o înregistrare nu este găsită în cel puțin unul dintre tabele, atunci interogarea nu o va afișa deloc. Ca urmare, vor fi selectate doar acele articole din documentul de Primire Bunuri și Servicii pentru care există înregistrări în registrul de informații Prețuri Articole, dacă în exemplul anterior înlocuim FULL cu INTERN.

A SE GRUPA CU

Gruparea în interogări 1C vă permite să restrângeți rândurile de tabel (câmpuri de grupare) conform unei anumite caracteristici comune (câmpuri de grupare). Câmpurile de grupare pot fi afișate numai folosind funcții de agregare.

Rezultatul următoarei interogări va fi o listă de tipuri de articole cu prețurile lor maxime.

ALEGE
,
MAX(Preț.Preț) AS Preț
DIN

A SE GRUPA CU
Preturi.Nomenclatura.TipNomenclatura

REZULTATE

Spre deosebire de grupare, atunci când se utilizează totaluri, toate înregistrările sunt afișate și rândurile totale sunt deja adăugate la acestea. Gruparea afișează numai înregistrări generalizate.

Rezultatele pot fi rezumate pentru întregul tabel (folosind cuvântul cheie „GENERAL”), pentru mai multe câmpuri, pentru câmpuri cu structură ierarhică (cuvinte cheie „IERARHIE”, „NUMAI IERARHIE”). Când rezumați, nu este necesar să folosiți funcții agregate.

Luați în considerare un exemplu similar cu cel de mai sus folosind gruparea. În acest caz, rezultatul interogării va returna nu numai câmpuri grupate, ci și înregistrări detaliate.

ALEGE
Prețuri.Nomenclatură.Tip de nomenclatură AS Tip de nomenclatură,
Preturi.Pret AS Pret
DIN
RegisterInformation.PricesNomenclature.SliceLast AS Preturi
REZULTATE
MAXIM (Preț)
DE
Nomenclatură de tip

AVÂND

Acest operator este similar cu operatorul WHERE, dar este folosit doar pentru funcții agregate. Alte câmpuri decât cele utilizate de acest operator trebuie grupate. Operatorul „UNDE” nu este aplicabil pentru funcțiile agregate.

În exemplul de mai jos, prețurile maxime ale articolelor sunt selectate dacă depășesc 1000, grupate după tipul articolului.

ALEGE

MAX(Preț.Preț) AS Preț
DIN
RegisterInformation.PricesNomenclature.SliceLast AS Preturi
A SE GRUPA CU
Preturi.Nomenclatura.TipNomenclatura
AVÂND
MAX(Prețuri. Preț) > 1000

FILTREAZĂ DUPĂ

Operatorul „ORDER BY” sortează rezultatul interogării. Pentru a vă asigura că înregistrările sunt scoase într-o ordine consecventă, se utilizează AUTO-ORDER. Tipurile primitive sunt sortate după regulile obișnuite. Tipurile de referință sunt sortate după GUID.

Un exemplu de obținere a unei liste de angajați sortați după nume:

ALEGE
Angajații.Nume AS Nume
DIN
Director.Angajaţii AS Angajaţii
FILTREAZĂ DUPĂ
Nume
COMANDA AUTOMATA

Alte construcții ale limbajului de interogare 1C

• UNI- rezultatele a două interogări într-una.
• UNIȚI TOȚI– similar cu JOIN, dar fără a grupa rânduri identice.
• MASĂ GOLĂ- folosit uneori la alăturarea interogărilor pentru a specifica un tabel imbricat gol.
• A PUNE- creează un tabel temporar pentru a optimiza interogările complexe 1C. Astfel de solicitări se numesc solicitări în lot.

Caracteristicile limbajului de interogare

• SUBSTRING trunchiază un șir dintr-o poziție specificată cu numărul specificat de caractere.
• AN... AL DOILEA vă permit să obțineți valoarea selectată a tipului numeric. Parametrul de intrare este o dată.
• ÎNCEPUTUL PERIOADEI ȘI sfârșitul perioadei sunt folosite atunci când se lucrează cu date. Tipul perioadei (ZI, LUNA, AN etc.) este specificat ca un parametru suplimentar.
• ADDDATE vă permite să adăugați sau să scădeți de la dată ora specificată de un anumit tip (SECOND, MINUT, DAY etc.).
• DIFERENTA DE DATA determină diferența dintre două date, specificând tipul valorii de ieșire (ZI, AN, LUNA etc.).
• ESTE NULînlocuiește valoarea lipsă cu expresia specificată.
• PREZENTARE și PREZENTARELINK-URI obțineți reprezentarea în șir a câmpului specificat. Ele sunt utilizate pentru orice valoare și, respectiv, numai pentru valori de referință.
• TIP, TIP VALOARE sunt utilizate pentru a determina tipul parametrului de intrare.
• LEGĂTURĂ este un operator logic de comparare pentru tipul de valoare de atribut.
• EXPRES este folosit pentru a converti valoarea în tipul dorit.
• DATA ORA primește o valoare de tip „Data” din valorile numerice (Anul, Luna, Ziua, Ora, Minutul, Secunda).
• SENSîntr-o solicitare 1C, este folosit pentru a specifica valori predefinite - directoare, enumerari, planuri pentru tipuri de caracteristici. Exemplu de utilizare: " Unde LegalIndividual = Valoare(Enumeration.LegalIndividual.Individual)«.

Generator de interogări

Pentru a crea interogări cu 1C, există un mecanism încorporat foarte convenabil - designerul de interogări. Conține următoarele file principale:

• „Tabele și câmpuri” - conține câmpurile care trebuie selectate și sursele acestora.
• „Legături” - descrie condițiile pentru constructul CONEXIUNE.
• „Gruparea” - conține o descriere a construcțiilor grupărilor și câmpurile rezumate după acestea.
• „Condiții” – este responsabil pentru selectarea datelor din cerere.
• „Avansat” - parametri suplimentari de interogare, cum ar fi cuvintele cheie ale comenzii „SELECT” etc.
• „Joins / Aliases” - sunt indicate posibilitățile de îmbinare a tabelelor și sunt setate aliasuri (constructia „CUM”).
• „Comandă” - este responsabil pentru sortarea rezultatului interogărilor.
• „Totale” - similar cu fila „Grupare”, dar este folosit pentru construcția „TOTALURI”.

Textul cererii în sine poate fi vizualizat făcând clic pe butonul „Solicitare” din colțul din stânga jos. În acest formular, poate fi corectat manual sau copiat.

Consola de interogări

Pentru a vizualiza rapid rezultatul unei interogări în modul „Enterprise” sau pentru a depana interogări complexe, utilizați . Textul de interogare este scris în el, parametrii sunt setați și rezultatul acestuia este afișat.

Puteți descărca consola de interogări pe discul ITS sau prin .

Obiectul de configurare „rol” oferă un set de drepturi la operațiuni (acțiuni) asupra obiectelor de configurare.

Rolul „Drepturi depline”.

Acesta este doar un rol (nepredefinit) care are casete de selectare pentru tot felul de drepturi pe toate obiectele de configurare.

Diferența sa față de alte roluri este prezența dreptului de „Administrare”.

Dacă este creat cel puțin un utilizator, sistemul începe să verifice dreptul de „Administrare” - cel puțin un utilizator trebuie să îl aibă.

Restricționați accesul la nivel de înregistrare

Row Level Security (RLS) - Restricție la nivel de înregistrare.

Mecanismul restricțiilor de acces la date vă permite să gestionați drepturile de acces nu numai la nivelul obiectelor metadate, ci și la nivelul obiectelor bazei de date. Următoarele obiecte pot fi utilizate pentru a restricționa accesul la date:

• roluri,
• opțiuni de sesiune,
• opțiuni funcționale,
• module comune privilegiate,
• cuvântul cheie PERMIS în limbajul de interogare.

Mecanismul este conceput pentru a restricționa accesul la înregistrările din tabelul de obiecte de metadate în funcție de condițiile arbitrare impuse valorilor câmpurilor de rând ale acestor tabele. De exemplu, pentru a vedea înregistrările numai pentru contrapărțile „dvs.”, organizații etc.

Implementarea tehnică a restricțiilor de acces în 1C

1C generează o solicitare către SGBD. Clusterul de server adaugă la cerere o secțiune WHERE, care conține textul condiției de restricționare a accesului prin RLS, apoi această solicitare este trimisă la DBMS, datele extrase sunt returnate clientului 1C.

Acest mecanism va funcționa pentru orice solicitare din partea clientului:

• în rapoarte
• în liste dinamice și forme de listă obișnuite
• în cereri aleatorii.

O astfel de implementare a mecanismului afectează foarte mult performanța.

Modalități de a ocoli restricțiile de acces.

În operațiunile mari consumatoare de resurse (procesarea documentelor de repostare, de exemplu), o parte a codului poate fi mutată în module privilegiate.

A) modul privilegiat este un modul partajat cu indicatorul „Privilegiat” în proprietăți.

Particularitatea sa constă în faptul că codul din acesta este executat fără niciun control de acces, inclusiv RLS.

B) De asemenea privilegiat modul poate fi activat pentru modulele obiect document. Acest lucru se face în proprietățile documentului, flag

• Mod privilegiat când țineți apăsat
• Mod privilegiat la anulare programare

C) Metoda SetPrivilegedMode()

O comandă de sistem care vă permite să faceți parte din codul oricărui modul privilegiat.

Din următoarea linie de cod, modul privilegiat de execuție va fi în vigoare.

Va actiona pana la linia de dezactivare a acestui mod sau pana la sfarsitul procedurii/functiei

(Adevărat);

// orice cod aici va fi executat fără controlul drepturilor și RLS

SetPrivilegedMode(Minciună ); // sau sfârșitul procedurii / funcției

Numărul de activări ale modului privilegiat trebuie să se potrivească cu numărul de dezactivări. Cu toate acestea, dacă modul privilegiat a fost activat (o dată sau de mai multe ori) în cadrul unei proceduri sau funcție, dar nu a fost dezactivat, sistemul va efectua automat oprirea de câte ori au existat activări în așteptare în procedura sau funcția abandonată.

Dacă într-o procedură sau o funcție se apelează la metoda SetPrivilegedMode(Fals) mai mult decât apelurile de metodă efectuate SetPrivilegedMode(adevărat) atunci va fi aruncată o excepție

Funcţie Mod privilegiat() returnează True dacă modul privilegiat este încă activat și False dacă modul privilegiat este complet dezactivat. Nu analizează numărul de setări ale modului privilegiat într-o anumită funcție.

Toate procedurile și funcțiile apelate vor fi, de asemenea, executate în modul privilegiat.

De asemenea, este posibil să începeți o sesiune privilegiată. Aceasta este o sesiune în care modul privilegiat este setat încă de la începutul sistemului. În același timp, în timpul funcționării, metoda Mod privilegiat() va returna întotdeauna True , iar capacitatea de a dezactiva modul privilegiat nu este acceptată. Doar un utilizator cu drepturi de administrare (drept de administrare) poate începe o sesiune privilegiată. Sesiunea poate fi pornită folosind comutatorul din linia de comandă pentru lansarea aplicației client UsePrivilegedMode sau a parametrului șir de conexiune la baza de informații prmod .

Întrebarea apare în mod firesc: de ce, atunci, să se stabilească restricții de acces, dacă poate fi ocolită atât de ușor?

Modul sigur.

Da, este posibil să scrieți procesări externe cu modul de execuție privilegiat și să descărcați/corupt date. Pentru a preveni acest lucru, sistemul are o metodă de context global

Setați SafeMode().

Modul sigur, printre altele, ignoră modul privilegiat.

Trebuie setat înainte de a apela programatic handlere externi sau de export a procedurilor și funcțiilor din modulele lor.

Aruncă o excepție atunci când se efectuează operațiuni interzise în timpul execuției.

În plus, pentru utilizatori, puteți dezactiva capacitatea de a lansa interactiv rapoarte externe și de procesare la nivel de setări de rol.

Setare restricție de acces

RLS poate fi configurat numai pentru drepturi:

• citire (selectare)
• adăugarea (inserarea)
• modificare (actualizare)
• ștergere (ștergere)

Pentru operații de citireși ștergere, obiectul din baza de date trebuie să respecte restricția de acces la date.

Pentru operația de adăugare restricția de acces la date trebuie să corespundă obiectului care este planificat să fie scris în baza de date.

Pentru operațiunea de schimbare Restricția de acces la date trebuie să se potrivească cu obiectul atât înainte de modificare (pentru ca obiectul să fie citit), cât și după modificare (pentru ca obiectul să fie scris).

Pentru toate celelalte drepturi, această opțiune nu este disponibilă.

Să adăugăm o nouă restricție pentru dreptul de „citire” al cărții de referință „Nomenclatură”. Se va deschide o listă de câmpuri pentru care puteți configura restricția adăugată.

Aceasta înseamnă că dacă încercați să accesați câmpurile bifate, restricția va funcționa, iar dacă încercați să accesați câmpurile nebifate, restricția nu va funcționa.

Dacă selectați steagul Alte domenii”, restricția va fi stabilită pentru toate câmpurile tabelului, cu excepția câmpurilor pentru care restricțiile sunt stabilite în mod explicit.

* Caracteristică: pentru drepturile de adăugare, modificare, ștergere:

• Restricția poate fi configurată numai pentru toate câmpurile.
• Nu poate exista decât o singură limită.

Pentru dreptul „Citește”, puteți seta mai multe condiții, acestea vor fi combinate cu operatorul logic „ȘI”.

În restricțiile privind obiectele bazei de date de următoarele tipuri, nu pot fi utilizate toate câmpurile obiectului de date principal al restricției:

• în registrele de acumulare, restricțiile de acces pot conține doar măsurători ale obiectului principal de restricție;
• în registrele contabile în restricții, puteți utiliza numai măsurătorile soldului obiectului principal al restricției

Daca in conditiile accesului limitat la datele din registrul cifrei de afaceri de acumulare se folosesc masuratori care nu sunt incluse in totaluri, atunci la accesarea tabelului virtual al cifrei de afaceri nu se folosesc totalurile stocate si interogarea se executa in totalitate conform la masa de mișcare.

Mecanismul de impunere a restricțiilor de acces.

Orice operațiune asupra datelor stocate în baza de date în 1C:Enterprise are ca rezultat accesarea bazei de date cu o solicitare de citire sau modificare a datelor. În timpul executării interogărilor către baza de date, mecanismele interne ale 1C:Enterprise impun restricții de acces. în care:

• Se formează lista drepturilor(citiți, adăugați, actualizați, ștergeți), o listă de tabele de baze de date și o listă de câmpuri utilizate de această interogare.
• Din toate rolurile utilizatorului actual selectați restricțiile de acces la date pentru toate drepturile, tabelele și câmpurile implicate în cerere. Mai mult, dacă vreun rol nu conține restricții de acces la datele niciunui tabel sau câmp, atunci aceasta înseamnă că valorile câmpurilor necesare din orice înregistrare sunt disponibile în acest tabel. Cu alte cuvinte, absența unei restricții de acces la date înseamnă că există o restricție WHERE True.
• Obțineți valorile actuale ale tuturor parametrilor de sesiune și opțiunile funcționale participarea la constrângerile selectate.

Obținerea valorii unui parametru de sesiune sau a unei opțiuni funcționale nu necesită ca utilizatorul actual să aibă dreptul de a obține acea valoare. Cu toate acestea, dacă valoarea unui parametru de sesiune nu a fost setată, atunci va apărea o eroare și interogarea bazei de date nu va fi executată.

Constrângerile derivate din același rol sunt combinate cu o operație AND.

Constrângerile primite de la diferite roluri sunt combinate cu operația SAU.

Condițiile construite sunt adăugate la interogările SQL cu care 1C:Enterprise accesează SGBD. La accesarea datelor din partea condițiilor de restricție de acces, nu se efectuează verificarea drepturilor (nici la obiectele metadate, nici la obiectele bazei de date). Mai mult, mecanismul de adăugare a condițiilor depinde de modul de funcționare ales al restricțiilor „toate” sau „permis”.

*Caracteristică: Dacă un utilizator are acces la mai multe roluri cu restricții configurate la nivel de înregistrări la un obiect, atunci în acest caz condițiile de restricții sunt adăugate prin operația logică „SAU”. Cu alte cuvinte, permisiunile utilizatorului sunt cumulate.

Aceasta duce la următoarea concluzie: nu permiteți trecerea condiției de restricționare a accesului la un obiect cu roluri diferite, deoarece în acest caz textul de interogare va deveni mult mai complicat și acest lucru va afecta performanța.

Toate Direcțiile.

Când sunt impuse restricții folosind metoda „toate”, condițiile și câmpurile sunt adăugate la interogările SQL, astfel încât 1C:Enterprise să poată obține informații despre dacă datele care sunt interzise pentru utilizatorul dat au fost utilizate în procesul de executare a unei interogări de bază de date sau nu. . Dacă au fost folosite date interzise, ​​atunci cererea este anulată din cauza unei încălcări a accesului.

Impunerea restricțiilor de acces prin metoda „toată lumea” este prezentată schematic în figură:

Metoda „permisă”.

Când restricțiile sunt impuse folosind metoda „permisă”, astfel de condiții sunt adăugate la interogările SQL, astfel încât intrările interzise pentru utilizatorul curent să nu afecteze rezultatul interogării. Cu alte cuvinte, atunci când sunt impuse restricții în modul „permis”, înregistrările interzise pentru acest utilizator sunt considerate lipsă și nu afectează rezultatul operațiunii, care este prezentat schematic în figură:

Restricțiile de acces la date sunt impuse obiectelor bazei de date atunci când 1C:Enterprise accesează baza de date.

În versiunea client-server a 1C:Enterprise, restricțiile sunt aplicate pe serverul 1C:Enterprise.

Totuși, această opțiune (PERMISĂ) nu va funcționa dacă ne referim la un tabel din interogare pentru care nu sunt configurate restricții de acces, dar în care există link-uri către rânduri de tabel cu restricții configurate. În acest caz, rezultatul interogării va fi „<Объект не найден>......” în loc de valoarea câmpului de referință.

Dacă dezvoltați un raport sau procesați folosind interogări de configurare generice sau personalizate, verificați întotdeauna marcajul „Permis”. pentru ca raportul să funcționeze sub orice utilizator cu orice set de drepturi.

În cazul citirii datelor de obiect din baza de date, nu este posibilă setarea flag-ului „Permis”. Prin urmare, este necesar configurați selecțiile pentru citirea obiectelor, ținând cont de posibilele restricții privind drepturile de acces pentru utilizator. Nu există mijloace de a obține numai date permise în tehnologia obiectelor.

Este important ca, dacă cuvântul cheie ALLOWED nu este specificat într-o interogare, atunci toate filtrele specificate în acea interogare nu trebuie să intre în conflict cu niciuna dintre restricțiile privind citirea obiectelor bazei de date utilizate în interogare. Mai mult decât atât, dacă în interogare sunt folosite tabele virtuale, atunci filtrele corespunzătoare trebuie impuse tabelelor virtuale în sine.

Practică 1. Generator de interogări în setările RLS.

Să compunem textul secțiunii „UNDE” în ​​interogarea către director. Puteți utiliza generatorul de interogări.
Constructorul este trunchiat.

Fila „Tabele”

Tabelul principal va fi tabelul obiectului pentru care constrângerea este configurată.

De asemenea, puteți selecta alte tabele și puteți configura diverse relații între ele în fila „Relații”.

fila Condiții

Aici puteți configura condițiile reale pentru restricționarea accesului.

Să adăugăm condiții pentru atributul „Preț” din directorul listei de acțiuni pentru dreptul de „citire” la toate câmpurile tabelului.

"Nomenclatură WHERE Nomenclatură. Preț > 500"

Să vedem cum funcționează această regulă simplă. Tabelul de referință conține următoarele elemente:

După setarea restricției de acces, tabelul va afișa doar elementele care îndeplinesc condiția:

Au dispărut și grupuri. Modificați textul constrângerii

„Nomenclator WHERE Nomenclator. Preț > 500

SAU Nomenclatură. Acesta este un grup"

Ei bine, acum iată ce ai nevoie.

Dacă eliminați afișarea câmpului „cod” din setările listei, vor fi afișate toate elementele directorului, adică. restricția nu a funcționat. Dacă setați afișarea câmpului „Cod”, restricția va funcționa.

În același timp, în ciuda faptului că elementul de căutare este vizibil în câmpul listă, forma acestuia nu poate fi deschisă, deoarece este setată o restricție asupra atributului. Același lucru într-o solicitare arbitrară: atunci când încercați să obțineți un atribut „restricționat”, va apărea o eroare de acces.

Dacă încercați să obțineți elementele de recuzită „restricționate” în mod programatic, va apărea și o eroare de acces.

Mai mult, va fi imposibil să accesezi orice câmpuri ale obiectului printr-un link, deoarece atunci când se primește un link, sistemul citește întregul obiect, iar dacă are detalii „limitate”, obiectul nu va fi citit.

Prin urmare, atunci când lucrați cu obiecte de bază de date în mod programatic, trebuie să aveți în vedere posibilele restricții la nivel de înregistrare și să obțineți toate datele necesare despre obiect cu o interogare și apoi să le plasați într-o structură sau să executați o parte a codului într-un modul privilegiat.

După configurarea restricției de acces, afișarea liniei din lista de drepturi s-a schimbat - a devenit gri și a apărut o pictogramă.

Restricții de configurare a accesului (RLS).

• Fără secțiune Rezumat;
• Nu puteți accesa tabelele de registre virtuale;
• Nu puteți utiliza în mod explicit parametrii;
• Subinterogările pot folosi orice>/span> facilități de limbaj de interogare, cu excepția:
  • operator ÎN IERARHIE;
  • ofera REZULTATE;
  • rezultatele interogării imbricate nu trebuie să conțină părți tabulare>/span>;
  • mese virtuale, în special solduri și cifre de afaceri

Practica 2. Nomenclatura cu prețul curent.

Faceți o restricție de acces dacă trebuie să afișați un articol cu ​​prețul curent mai mare decât o anumită valoare, de exemplu, 100.

Soluţie:

Adăugăm o nouă regulă de restricție de acces pentru cartea de referință „Nomenclatură” pentru dreptul de „citire”.
Selectați „alte câmpuri”.
În constructor, adăugați o interogare imbricată. În acesta, selectați tabelul de registru de informații „Prețuri articole”.
Nu există nicio filă „comandă” - aceasta este o caracteristică a generatorului de interogări pentru crearea unei interogări de restricție de acces.
În fila „Avansat”, setați „primul 999999999”, a apărut fila „comanda”.
Configurați ordonarea după câmpul „Perioadă” în ordine descrescătoare.
Apoi am configurat conexiunea tabelului principal cu subinterogarea prin referință.

Șabloane de restricții de acces.

Practica 3. Restricționarea „antreprenorilor” după valoare într-o constantă.

Configurați restricția de acces pentru directorul Counterparties după valoarea stocată în Constant.

În plus, trebuie să configurați o restricție pentru toate obiectele care folosesc directorul „Contractanți” în detalii.

Soluţie

Pentru cartea de referință „Conturi”, pentru dreptul de „citire”, vom stabili o restricție prin adăugarea unei interogări imbricate la constantă la secțiunea „Condiții”. Nu uitați acest grup.

Vedem problema, directorul Counterparties este filtrat corect și toate documentele cu atributul „Counterparty” sunt afișate, unele cu link-uri „rupte” în atributul „Counterparty”.

Acum trebuie să configurați restricția de acces pentru toate obiectele folosind linkul către „Conturi”. Să le găsim cu serviciul „căutare legături către un obiect”.

Să copiem și să modificăm ușor textul condiției RLS din directorul „Contrapărți”. Acest lucru trebuie făcut de câte ori sunt găsite obiecte.

Sau utilizați modelul de restricție de acces pentru a evita problemele de duplicare a codului.

Șabloanele de restricții de acces sunt configurate la nivel de rol și pot fi utilizate pentru orice obiect din cadrul rolului editat.

Puteți pune orice fragment de text cu restricții de acces în șablon. Șablonul este apelat prin simbolul „#”. De exemplu, #TemplateContractor.

Prin # în 1C, instrucțiunile sunt scrise în preprocesor. În contextul executării setărilor de restricție de acces, platforma înlocuiește textul de apel șablon cu textul șablonului.

Să mutăm textul după cuvântul WHERE în șablonul „TemplateContractor”, cu excepția textului despre ThisGroup.

Parametri în șabloanele de restricții de acces.

Să continuăm să rezolvăm problema 2.

Problema acum este că tabelul principal din director se numește „contraparte”, în documentul „Factură”. Câmpul bifat din director se numește „link”, în document - „Contraparte”.

Schimbați numele tabelului principal din textul șablonului în „#CurrentTable”

„#CurrentTable” este un parametru predefinit.

Și prin punct indicăm numărul parametrului de intrare - „.#Parameter(1)

„#Parameter” este, de asemenea, o valoare predefinită. Poate conține un număr arbitrar de parametri de intrare. Acestea sunt menționate prin numărul de serie.

În textul restricției de acces pentru director, indicăm următoarele:

Pentru document, următoarele:

„Vânzarea de bunuri WHERE #TemplateContractor(„Contractant”)”

Când apelați șablonul de restricție de acces, parametrii ar trebui să îi fie transferați numai ca șir, adică între ghilimele.

Tabel principal - Nomenclator

Textul șablonului este:

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

Textul șablonului conține o parte a textului în limba de restricție a accesului la date și poate conține parametri care sunt evidențiați cu simbolul „#”.

Caracterul „#” poate fi urmat de:

• Unul dintre cuvintele cheie:
  • Un parametru urmat de numărul parametrului din șablon între paranteze;
  • CurrentTable - înseamnă inserarea în text a numelui complet al tabelului pentru care se construiește restricția;
  • CurrentTableName– denotă inserarea în text a numelui complet al tabelului (sub formă de valoare șir, între ghilimele) căruia i se aplică instrucțiunea, în versiunea curentă a limbajului încorporat;
  • NameCurrentPermission– conține denumirea dreptului pentru care se efectuează restricția curentă: CITEȘTE/CITIȚI, Adăugați/Inserați, MODIFICA/ACTUALIZARE, ȘTERGE/ȘTERGE;
• nume parametru șablon – înseamnă inserarea în text a restricției parametrului șablon corespunzător;
• simbolul „#” – indică inserarea unui singur simbol „#” în text.

O expresie de restricție de acces poate conține:

• Modelul de restricție de acces, care este specificat în format #TemplateName(„Valoarea parametrului șablonului 1”, „Valoarea parametrului șablonului 2”,...). Fiecare parametru de șablon este inclus între ghilimele duble. Dacă trebuie să specificați un caracter de ghilimele duble în textul parametrului, utilizați două ghilimele duble.
• Funcția StrContains (Unde Căutăm, Ce Căutăm). Funcția este concepută pentru a căuta o apariție a WhatLooking for în șirul WhereLooking for. Returnează True dacă se găsește potrivirea, False în caz contrar.
• Operatorul + pentru concatenarea șirurilor.

Pentru comoditatea editării textului șablonului, în fila Șabloane de restricții din formularul de rol, faceți clic pe butonul Setați textul șablonului. În caseta de dialog care se deschide, introduceți textul șablonului și faceți clic pe OK.

Ele nu pot fi instalate folosind setParameter() sau ceva asemanator.

În acest caz, parametrii sunt:

• Opțiuni de sesiune
• Opțiuni funcționale

Citirea parametrilor de sesiune într-o solicitare de restricție de acces are loc într-un mod privilegiat, adică fără controlul drepturilor de a opera cu aceștia.

Practica 4. Acces la contrapărțile „voastre”.

Este necesar să se stabilească restricționarea accesului utilizatorului actual la contrapărțile „lor”.

Există un director „Utilizatori”, un director „Contrapărți”, documente cu necesarul „Contraparte”.

Utilizatorul actual ar trebui să vadă datele numai pentru acele contrapărți pentru care a fost stabilită o conexiune cu el.

Comunicarea trebuie, de asemenea, configurată.

Opțiuni posibile:

Stabilirea de legături utilizator + contraparte

• Detalii în directorul contrapărților
• Registrul de informații

Soluții posibile la problemă:

• Stocarea utilizatorului într-o constantă este o opțiune proastă, constanta este disponibilă pentru toți utilizatorii.
• Păstrarea unei matrice fixe a contrapărților utilizatorului curent în parametrii de sesiune nu este o opțiune bună, pot exista multe contrapărți
• Stocați parametrii de sesiune ai utilizatorului curent, apoi solicitați obținerea unei liste a contrapărților „lui” - o opțiune acceptabilă.
• Alte optiuni.

Soluţie.

Să creăm un nou parametru de sesiune „CurrentUser” și să scriem completarea acestuia în modulul de sesiune.

Să creăm un registru de informații „Corespondențele managerilor și contrapărților”

Să creăm un nou rol și în el o nouă restricție de acces pentru documentul „Chitanță Factură”.

În textul de interogare, vom conecta tabelul principal cu registrul de informații de către Contractor = Contractor și Manager = &CurrentUser. Tip de conexiune Internă.

Dacă este posibil, este mai bine să evitați interogările imbricate în textele de restricție de acces, deoarece acesta va fi executat de fiecare dată când datele din acest obiect sunt citite din baza de date.

Verificăm - restricțiile funcționează

* Caracteristică: Dacă modificați lista de contrapărți ale utilizatorului din registru, restricțiile de acces vor intra în vigoare imediat, fără a reporni sesiunea utilizatorului.

Practică 5. Fără modificare a datei.

Este necesar să se implementeze restricția privind editarea datelor mai devreme decât data stabilită pentru interzicerea modificărilor.
Utilizatorii trebuie să fie limitati.

Să creăm un registru de informații „ChangeBarDateDate” cu dimensiunea Utilizator, resursa RestrictedDate.

Să construim logica soluției în acest fel:

• dacă utilizatorul nu este specificat, atunci interdicția se aplică tuturor utilizatorilor
• dacă există o restricție pentru toți utilizatorii și o restricție pentru un anumit utilizator, atunci există o restricție pentru un anumit utilizator, iar pentru restul conform principiului general.

Evident, o astfel de limită poate fi configurată pentru obiectele bazei de date care au o anumită poziție pe axa timpului. Poate fi

• Documentație
• Registre periodice de informații

Să creăm un nou rol „RestrictionsBy ChangeProhibitionDate”.

În el, pentru documentul „Chitanță Factură” pentru „schimbarea” corectă vom adăuga o nouă restricție de acces.

Setarea este specificată pentru toate câmpurile.

Textul restricției este:

Chitanță Factură FROM Document.Chitanță Factură AS Factură Factură

ChangeProhibitionDates.ProhibitionDate AS ProhibitionDate
DIN

INNER JOIN (SELECT
MAXIMUM(ChangeProhibitionDate.User) AS Utilizator
DIN
Registrul informațiilor Datele interzicerii modificărilor CA data interzicerii modificărilor
UNDE
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS Subinterogare
Factură Invoice.Date > NestedRequest.BanDate

Verificăm - restricția funcționează.

Folosind instrucțiunile preprocesorului

#Dacă Condiția1 #Atunci

Fragmentul de cerere 1

#ElseIf Condition2 #Atunci

Fragmentul de cerere 2

#In caz contrar

Fragmentul de cerere 3

#EndIf

În condiții, puteți utiliza operațiuni logice (și. sau, nu, etc.) și accesul la parametrii de sesiune.

Această abordare în contextul construirii restricțiilor de acces este convenabilă deoarece, în funcție de condiții, va fi compilat un text de interogare mai scurt. O solicitare mai simplă încarcă sistemul mai puțin.

Dezavantajul este că constructorul de interogări nu va funcționa cu un astfel de text.

* Particularitate:

Spre deosebire de instrucțiunile pentru preprocesorul 1C:Enterprise din textele de restricție de acces, precedați operatorul Then cu un semn hash — #Then

Practica 6. Comutați „Utilizați RLS”

Să completăm sistemul nostru de restricții cu un comutator care activează/dezactivează utilizarea restricției la nivel de înregistrare.

Pentru a face acest lucru, adăugați o constantă și un parametru de sesiune numit „UseRLS”.

Să scriem în Modulul de sesiune setarea valorii parametrului de sesiune din valoarea constantei.

Adăugați următorul cod la toate textele cu restricții de acces:

„#Dacă &UseRLS #Atunci….. #EndIf”

Verificăm - totul funcționează.

Cu toate acestea, acum, după activarea steagului „utilizați radar”, modificările nu vor intra în vigoare imediat. De ce?

Deoarece parametrul sesiunii este setat atunci când începe sesiunea.

Este posibil ca parametrul de sesiune să fie resetat atunci când este scrisă o nouă valoare constantă, dar aceasta va funcționa numai pentru sesiunea curentă a utilizatorului. Alți utilizatori trebuie să fie solicitați să repornească sistemul.

Sfârșitul primei părți.

   

17 reguli pentru compilarea unei CERERI optime la datele bazei de date 1C

Pentru a forma și executa interogări la tabelele bazei de date în platforma 1C, este utilizat un obiect special de limbaj de programare. Cerere. Acest obiect este creat prin apelarea constructului Cerere nouă. Este convenabil să utilizați o interogare atunci când trebuie să obțineți o selecție complexă de date, grupate și sortate după cum este necesar. Un exemplu clasic de utilizare a unei interogări este obținerea unui rezumat al stării unui registru de acumulare la un anumit moment în timp. De asemenea, mecanismul de interogare facilitează obținerea de informații în diferite secțiuni de timp.

Textul cererii este instrucțiunea conform căreia cererea trebuie executată. Corpul cererii descrie:

• tabele din baza de informații utilizate ca surse de date de interogare;
• câmpurile de tabel care trebuie procesate în interogare;
• reguli de grupare;
• sortarea rezultatelor;
• etc.

Instrucțiunea este compilată într-un limbaj special - limbajul de interogare și constă din părți separate - secțiuni, propoziții, cuvinte cheie, funcții, operatori aritmetici și logici, comentarii, constante și parametri.

Limbajul de interogare al platformei 1C este foarte asemănător cu sintaxa altor limbaje SQL, dar există diferențe. Principalele avantaje ale limbajului de interogare încorporat sunt: ​​dereferențierea câmpurilor, tabele virtuale, lucru convenabil cu totaluri, câmpuri netipizate în interogări.

Recomandări pentru scrierea interogărilor bazei de date în limbajul de interogare a platformei 1C:

1) Corpul cererii poate conține date de configurare predefinite, cum ar fi:

• valori de enumerare;
• date predefinite:
• directoare;
• planuri de tipuri de caracteristici;
• planuri de conturi;
• planuri pentru tipuri de calcule;
• link-uri goale;
• valorile punctelor de referință ale proceselor de afaceri.

De asemenea, textul cererii poate conține valori de enumerare a sistemului care pot fi atribuite câmpurilor din tabelele bazei de date: AccumulationMotionType, AccountType și AccountingMovementType. Solicitările se referă la date de configurare predefinite și la valorile de enumerare a sistemului folosind un literal de tipul funcției VALUE. Acest literal îmbunătățește lizibilitatea interogării și reduce numărul de parametri de interogare.

Un exemplu de utilizare a unui literal SENS:

• WHERE City = VALUE(Directory.Cities.Moscow)
• WHERE City = VALUE(Reference.Cities.EmptyReference)
• WHEREItemType = VALUE(Enumeration.ProductTypes.Service)
• WHEREMovementType = VALUE(MovementTypeAccumulation.Income)
• WHERE RoutePoint = VALUE(BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Instrucțiuni de utilizare COMANDA AUTOMATAîntr-o interogare, timpul de execuție a interogării poate fi foarte mare, așa că dacă nu este necesară sortarea, atunci este mai bine să nu o folosiți deloc. În cele mai multe cazuri, cel mai bun mod de a aplica sortarea este cu instrucțiunea FILTREAZĂ DUPĂ.

Auto-aranjarea funcționează conform următoarelor principii:

• Dacă clauza ORDER BY a fost specificată în interogare, atunci fiecare referință la tabel din această clauză va fi înlocuită cu câmpurile după care tabelul este sortat implicit (pentru directoare, acesta este codul sau numele, pentru documente, data a documentului). Dacă câmpul de ordonare se referă la un director ierarhic, atunci se va aplica sortarea ierarhică după acest director.
• Dacă în interogare nu există o clauză ORDER BY, dar există o clauză TOTALS, atunci rezultatul interogării va fi sortat după câmpurile prezente în clauza REZULTATE după cuvântul cheie BY, în aceeași succesiune și, dacă totalurile au fost calculate prin câmpurile - linkuri, apoi după câmpurile de sortare implicit a tabelelor la care s-a făcut referire.
• Dacă nu există clauze ORDER BY și TOTAL în interogare, dar există o clauză GROUP BY, atunci rezultatul interogării va fi sortat după câmpurile prezente în propoziție în aceeași succesiune și, dacă gruparea a fost efectuată pe câmpuri - link-uri, apoi în mod implicit sortarea câmpurilor tabelele la care s-a făcut referire.
• Dacă interogarea nu conține clauzele și ORDER BY, TOTAL și GROUP BY, rezultatul va fi ordonat după câmpurile de sortare implicite pentru tabelele din care sunt selectate datele, în ordinea în care apar în interogare.
• Dacă interogarea conține clauza TOTAL, fiecare nivel de totaluri este ordonat separat.

3) Pentru a evita reinterogarea bazei de date atunci când se afișează utilizatorului rezultatul interogării (de exemplu, construirea unei interogări sau afișarea rezultatului interogării folosind un document de foaie de calcul), este util să folosiți instrucțiunea LEGĂTURI DE PREZENTARE A care vă permite să obțineți o reprezentare a unei valori de referință. Exemplu:

De asemenea, este posibil să utilizați instrucțiunea PERFORMANŢĂ- conceput pentru a obține o reprezentare în șir a unei valori de tip arbitrar. Diferența dintre aceste instrucțiuni este că, în primul caz, dacă instrucțiunile trec o referință, rezultatul va fi un șir, în alte cazuri, rezultatul va fi valoarea parametrului transmis. În al doilea caz, rezultatul instrucțiunii va fi întotdeauna un șir!

4) Dacă interogarea conține un câmp cu un tip compus, atunci pentru astfel de câmpuri devine necesar să turnați valorile câmpului la un anumit tip folosind instrucțiunea EXPRES, care vă va permite să eliminați tabelele inutile din conexiunea din stânga cu un câmp de tip de date compus și să accelerați interogarea. Exemplu:

Există un registru pentru acumularea de resturi de bunuri, în care câmpul Registrator are un tip compus. În cerere se selectează Data și Numărul documentelor de primire a mărfurilor, în timp ce accesarea detaliilor documentului prin câmpul Registrator nu are ca rezultat multe conexiuni la stânga a tabelului registrului de acumulare cu tabelele documentelor de registru.

Cod 1C v 8.x SELECT
EXPRESS(Rămășițe de bunuri.Document de înregistrare AS.Recepție de bunuri).Număr AS Număr de primire,
EXPRESS(Rămășițe de mărfuri. Document de înregistrare AS. Primire de mărfuri).Data AS Data primirii
DIN
Registrul de acumulare. Rămășițe de bunuri AS Rămășițe de bunuri

Dacă distribuția este considerată ca nu este fezabilă, atunci rezultatul turnării este valoarea NUL.

5) Nu uitați de instrucțiuni PERMIS, ceea ce înseamnă că interogarea va selecta doar înregistrările pentru care utilizatorul actual are permisiuni. Dacă acest cuvânt nu este specificat, atunci în cazul în care interogarea selectează înregistrări pentru care utilizatorul nu are drepturi, interogarea va funcționa cu o eroare.

6) Dacă interogarea folosește o uniune, iar în unele părți ale uniunii există tabele imbricate (un document cu o parte tabelară), iar în unele nu este necesară completarea listei de selecție cu câmpuri - tabele imbricate goale. Acest lucru se face folosind cuvântul cheie TABUL GOLIT, după care aliasurile câmpurilor din care va consta tabelul imbricat sunt indicate între paranteze. Exemplu:

Cod 1C v 8.x // Selectați câmpurile Număr și Compoziție
// din tabelul virtual Document.Invoice
ALEGE Număr.Referință, TABEL GOL.(Nom, Tov, Cant.) CA COMPOZIȚIE
DIN Document.Factură
UNIȚI TOȚI
SELECT Link.Number, Composition.(LineNumber, Product, Quantity)
FROM Document.Invoice Document.Invoice.Composition.*

7) Pentru a evita liniile duplicate în rezultatul interogării, ar trebui să utilizați instrucțiunea VARIAT, pentru că este din ce în ce mai clar, iar instrucțiunea A SE GRUPA CU utilizat pentru grupare folosind funcții de agregare. Apropo, atunci când folosiți funcții agregate, propoziția A SE GRUPA CU este posibil să nu fie specificate deloc, în timp ce toate rezultatele interogării vor fi grupate într-o singură linie. Exemplu:

Cod 1C v 8.x // Este necesar să se afle ce contrapărți
// mărfurile au fost expediate pentru perioada respectivă.
Selectați Diverse
Document.Factură.Contractant

8) Instruire A SE GRUPA CU vă permite să accesați câmpuri de nivel superior, fără a grupa rezultatele după aceste câmpuri, dacă funcțiile de agregare sunt aplicate câmpurilor unui tabel imbricat. Deși este scris în ajutorul 1C, la gruparea rezultatelor interogării, în lista câmpurilor de selecție trebuie indicate funcțiile agregate, iar pe lângă funcțiile de agregare, în lista de selecție pot fi indicate doar câmpurile prin care se realizează gruparea. câmpuri. Exemplu:

Cod 1C v 8.x SELECT
Primirea de bunuri și servicii, bunuri (SUMA (cantitate), nomenclatură),
Primirea Bunurilor și Serviciilor. Link,
Primirea Bunurilor și Serviciilor Contraparte
DIN
Document.Reception of Goods and Services AS Primirea Bunurilor si Serviciilor
A SE GRUPA CU
Primirea de bunuri și servicii, bunuri (nomenclatură)

9) Instruire ESTE NUL menite să înlocuiască valoarea NUL la o altă valoare, dar nu uitați că al doilea parametru va fi convertit în tipul primului dacă tipul primului parametru este un șir sau un număr.

10) Când te referi la tabelul principal, te poți referi la datele tabelului subordonat din condiție. Această caracteristică se numește dereferențierea câmpurilor unui sub-tabel.

Exemplu (căutați documente care conțin un anumit produs în secțiunea tabelară):

Avantajul acestei interogări față de interogarea din subtabelul Incoming.Goods este că, dacă există duplicate în documente, rezultatul interogării va returna doar documente unice fără a utiliza cuvântul cheie DISTINCT.

11) O variantă interesantă a operatorului B este o verificare a apariției unei mulțimi ordonate în mulțimea de astfel de mulțimi (Câmp1, Câmp2, ... , CâmpN) B (Câmp1, Câmp2, ... , CâmpN).

Cod 1C v 8.x SELECT
Contractori.Link
UNDE
(Contractors.Link, Buns.Link)
(SELECT Vânzări.Client, Vânzări.Produs
DIN Registrul de acumulare. Vânzări AS Vânzări)
DIN
Director. Contrapărți,
Director.Produse

12) Folosiți tabele de interogări virtuale ori de câte ori este posibil. La crearea unei interogări, sistemul furnizează un număr de tabele virtuale ca surse de date - acestea sunt tabele care sunt și rezultatul unei interogări pe care sistemul o generează în momentul execuției secțiunii de cod corespunzătoare.

Dezvoltatorul poate obține în mod independent aceleași date pe care i le oferă sistemul ca tabele virtuale, cu toate acestea, algoritmul pentru obținerea acestor date nu va fi optimizat, deoarece:

Toate tabelele virtuale sunt parametrizate, adică dezvoltatorului i se oferă posibilitatea de a seta niște parametri pe care sistemul îi va folosi atunci când generează o solicitare pentru a crea un tabel virtual. În funcție de ce parametri ai tabelului virtual sunt specificați de dezvoltator, sistemul poate genera VARIAT interogări pentru a obține același tabel virtual și vor fi optimizate în ceea ce privește parametrii trecuți.

Nu este întotdeauna posibil ca un dezvoltator să obțină acces la datele la care are acces sistemul.

13) În modul de operare client-server, funcția SUBSTRING() implementat folosind funcția SUBSTRING() a instrucțiunii SQL corespunzătoare transmisă serverului de baze de date SQL Server, care calculează tipul de rezultat al funcției SUBSTRING() conform unor reguli complexe în funcție de tipul și valorile parametrilor săi, precum și in functie de contextul in care este utilizat . În majoritatea cazurilor, aceste reguli nu afectează execuția unei interogări, dar există cazuri în care lungimea maximă a șirului rezultat calculat de SQL Server este esențială pentru execuția interogării. Este important de reținut că în unele contexte când se utilizează funcția SUBSTRING(), lungimea maximă a rezultatului acesteia poate fi egală cu lungimea maximă a unui șir de lungime limitată, care este de 4000 de caractere în SQL Server. Acest lucru poate duce la o blocare neașteptată în execuția interogării:

Furnizor Microsoft OLE DB pentru SQL Server: Avertisment: Procesorul de interogări nu a putut produce un plan de interogare de la optimizator deoarece lungimea totală a tuturor coloanelor din clauza GROUP BY sau ORDER BY depășește 8000 de octeți.

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

14) Utilizați cu grijă SAU in constructie UNDE, deoarece utilizarea unei condiții cu SAU poate „pondera” în mod semnificativ interogarea. Problema poate fi rezolvată prin proiectare UNIȚI TOȚI. Exemplu:

Cod 1C v 8.x SELECT

DIN

UNDE
_DemoContractors.Link =Link1
UNIȚI TOȚI
ALEGE
_Demo Counterparties.NameFull
DIN
Director._DemoContractors CUM _DemoContractors
UNDE
_DemoContractors.Link =Link2

15) Stare NU IN in constructie UNDE mărește timpul de execuție al cererii, întrucât este un fel de NU (SAU1 SAU2 ... SAU), deci pentru mese mari încercați să utilizați LEFT JOIN cu condiția IS NULL. Exemplu:

Cod 1C v 8.x SELECT
_DemoContractors.Link
DIN
Director._DemoContractors CUM _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Software _DemoContractors.Link = _BuyerDemoOrder.Contractor
UNDE
_Comanda demonstrativă a cumpărătorului. Contrapartea ESTE NULL

16) Când se utilizează Tabele temporare trebuie să indexați condiția și să uniți câmpurile din aceste tabele, DAR, atunci când utilizați indecși, interogarea poate rula și mai lent. Prin urmare, este necesar să se analizeze fiecare interogare cu și fără un index, să se măsoare viteza de execuție a interogării și să se ia o decizie finală.

Dacă plasați date într-un tabel temporar care este inițial indexat pe unele câmpuri, atunci nu va mai exista un index pentru aceste câmpuri în tabelul temporar.

17) Dacă nu utilizați Manager tabel temporar, atunci nu este nevoie să ștergeți în mod explicit tabelul temporar, acesta va fi șters după finalizarea execuției interogării lot, în caz contrar, tabelul temporar ar trebui șters într-unul din următoarele moduri: prin comandă DISTRUGEîn cerere, apelați metoda TemporaryTable Manager.Close().

Și în plus față de videoclipul de la Evgeny Gilev: Greșeli tipice la scrierea cererilor pentru 1C: