Frågespråket 1C 8 är ett oumbärligt verktyg för en 1C-programmerare; det låter dig skriva mer kortfattad, enkel och begriplig kod och använda färre systemresurser när du arbetar med data. Den här artikeln öppnar en serie lektioner dedikerade till frågespråket 1C 8. I den första lektionen kommer vi att titta på strukturen för huvudoperatören för detta språk - VÄLJA. Med den här operatorn kan du skapa urval från databastabeller. Valda tabelldata kan sorteras, villkor placeras på dem, länkas och kombineras med data från andra tabeller, grupperas efter olika fält och mycket mer.

Frågespråk 1C företag 8 - Operatörsstruktur SELECT

Låt oss titta på strukturen för SELECT-operatorn (valfria delar av operatorn anges inom hakparenteser). Frågespråket 1C tillhandahåller ett brett utbud av verktyg för att skapa dataprover.

VÄLJ [TILLÅTET] [ANNÄRA] [FÖRSTA A] [Fält1] [SOM Alias1], [Fält2] [SOM Alias2], ... [FältM] [SOM AliasB] [PUT TemporaryTableName] [FRÅN Tabell1 SOM AliasTableTable1 [[INNER JOIN] ][LEFT JOIN][FULL JOIN] Table2 AS Alias ​​​​Table2 [[INNER JOIN][LEFT JOIN][FULL JOIN] TableC AS Alias ​​​​TablesC BY Expression1 [Och Expression2]...[Och ExpressionD]] .. ... BY Expression1 [Och Expression2]...[Och ExpressionE]] ... [TabellF SOM TableF Alias] ... ] [GROUP BY GroupingField1[,] ... [GroupingFieldG]] [WHERE Expression1 [AND Expression2] ... [OCH ExpressionH]] [ENA ALLA...] [; ...] [INDEX EFTER Alias1 ... AliasB] [TOTALER [AggregationFunction(Field1)][,] [AggregationFunction(Field2)][,] ... [AggregationFunction(FieldI)] AV [GENERAL][,] [ GroupingField1][,] ... [GroupingFieldj]]

Nyckelord och block för att arbeta med fält

• VÄLJA— Ett nyckelord som anger början av operatorn.
• TILLÅTEN — anger att urvalet bör inkludera tabellposter som har läsbehörighet för den givna användaren;
  
• OLIKA — indikerar att urvalet endast ska inkludera olika (över alla fält) flöden. Med andra ord kommer dubbletter av rader att exkluderas från provet;
  
• FÖRST EN — om du anger detta nyckelord, kommer endast det första A av raderna som valts av frågan att inkluderas i urvalet, där A är ett naturligt tal;
  
• Fältblock— detta block anger de fält som måste inkluderas i urvalet. Dessa fält kommer att vara valda kolumner. I själva enkelt fall fältet ser ut så här: Table Alias.TableFieldName AS Fältalias

  På så sätt anger vi vilken tabell vi tar detta fält från. Frågespråket 1C låter dig ange alla alias, men de bör inte upprepas i samma SELECT-sats. Ett fält kan vara mer komplext och bestå av olika kombinationer av tabellfält, frågespråksfunktioner och aggregerade funktioner, men vi kommer inte att täcka dessa fall i den här handledningen.

Nyckelord och block för att arbeta med tabeller

• PUT TemporaryTableName- nyckelord PLATSär avsedd att skapa en tillfällig tabell med ett specifikt namn, som kommer att lagras i random access minne i denna 1C 8-session tills den slutar eller tills det tillfälliga bordet förstörs. Det bör noteras att namnen på temporära tabeller i en 1C 8-session inte bör upprepas;
• Block av tabeller och relationer— blocket anger alla tabeller som används i denna förfrågan, samt kopplingar mellan dem. Blocket börjar med ett nyckelord FRÅN, följt av den första tabellens namn och alias. Om denna tabell är relaterad till andra tabeller indikeras relationerna. 1C-frågespråket innehåller följande uppsättning anslutningstyper:
  • INRE KOPPLING— En post från den vänstra tabellen inkluderas i urvalet endast om anslutningsvillkoret är uppfyllt, en post från den högra tabellen kommer att inkluderas i urvalet endast om anslutningsvillkoret är uppfyllt;
  • VÄNSTER ANSLUTNING— En post från den vänstra tabellen kommer i alla fall att inkluderas i urvalet, en post från den högra tabellen kommer att inkluderas i urvalet endast om anslutningsvillkoret är uppfyllt;
  • FULL ANSLUTNING— en post från den vänstra tabellen kommer i alla fall att inkluderas i urvalet först, sedan endast om anslutningsvillkoret är uppfyllt, kommer en post från den högra tabellen att ingå i urvalet först i alla fall, sedan endast om anslutningsvillkoret är mött. I detta fall exkluderas de resulterande dubblettraderna från provet.

  Efter anslutningstypen anges namnet och aliaset för den andra tabellen. Därefter kommer nyckelordet FÖRBI följt av kommunikationsförhållanden kopplade till varandra av logiska operatorer OCH, ELLER. Varje uttryck i villkoret måste returnera ett booleskt värde (True, False). Om den första tabellen är ansluten till några andra tabeller än den andra, indikeras anslutningstypen igen, och så vidare. Var och en av tabellerna som deltar i anslutningen kan i sin tur kopplas till andra tabeller, detta visas i frågestrukturdiagrammet. Om tabellen inte är relaterad till den första, indikeras den utan anslutningstyp, sedan kan dess anslutningar följa, och så vidare;

Nyckelord och datakonverteringsblock

• Gruppblock— detta block används för att gruppera tabellrader. Rader kombineras till en om värdena för fälten som anges efter nyckelordet GRUPP AV visa sig vara densamma. I det här fallet summeras, medelvärdes, maximeras eller minimeras alla andra fält med hjälp av aggregerade funktioner. Aggregatfunktioner används i ett fältblock. Exempel: Maximum(TableAlias.TableFieldName) AS FieldAlias
• Konditionsblock- i detta block efter nyckelordet VAR villkorliga uttryck separerade med logiska operatorer indikeras OCH, ELLER, för att någon av de valda raderna ska inkluderas i urvalet, är det nödvändigt att alla villkor i aggregatet har ett värde Sann.
• KOMBINERA ALLT— detta nyckelord används för att kombinera frågor (operatorer VÄLJA). 1C frågespråk låter dig kombinera flera frågor till en. För att frågor ska slås samman måste de ha samma uppsättning fält;
• «;» - semikolon används för att separera påståenden som är oberoende av varandra VÄLJA;
  
• INDEXERA EFTER— Nyckelordet används för att indexera de fält som anges efter det.
  
• Sammanfattningsblock— används för att bygga trädliknande prover. För vart och ett av grupperingsfälten som anges efter nyckelordet FÖRBI, en separat rad skapas i urvalet. På den här raden kommer de totala värdena för de fält som anges efter nyckelordet att beräknas med hjälp av aggregerade funktioner RESULTAT.

Vill du fortsätta lära dig frågespråket 1C 8? Läs sedan nästa artikel.

17 regler för att skapa en optimal QUERY för 1C databasdata

För att generera och köra frågor till databastabeller i 1C-plattformen används ett speciellt programmeringsspråksobjekt Begäran. Detta objekt skapas genom att anropa konstruktionen Ny förfrågan. Frågan är bekväm att använda när du behöver få ett komplext dataprov, grupperat och sorterat efter behov. Ett klassiskt exempel på att använda en fråga är att få en sammanfattning av ackumuleringsregistrets tillstånd vid en viss tidpunkt. Dessutom gör frågemekanismen det enkelt att få information under olika tidsperioder.

Begäran instans är den instruktion enligt vilken begäran ska verkställas. Förfrågningsorganet beskriver:

• infobastabeller som används som frågedatakällor;
• tabellfält som behöver bearbetas i frågan;
• grupperingsregler;
• sorteringsresultat;
• etc.

Instruktionen är sammanställd på ett speciellt språk - frågespråket och består av separata delar - avsnitt, meningar, nyckelord, funktioner, aritmetiska och logiska operatorer, kommentarer, konstanter och parametrar.

Frågespråket för 1C-plattformen är mycket likt syntaxen för andra SQL-språk, men det finns skillnader. De främsta fördelarna med det inbyggda frågespråket är: avreferensfält, närvaron av virtuella tabeller, bekvämt arbete med resultat, oskrivna fält i frågor.

Rekommendationer för att skriva databasfrågor på 1C-plattformens frågespråk:

1) Begäran kan innehålla fördefinierade konfigurationsdata, såsom:

• uppräkningsvärden;
• fördefinierade data:
• uppslagsverk;
• planer för typer av egenskaper;
• kontoplaner;
• planer för typer av beräkningar;
• tomma länkar;
• affärsprocess ruttpunktsvärden.

Begäranstexten kan också innehålla värden för systemuppräkningar som kan tilldelas fält i databastabellerna: Ackumuleringsrörelsetyp, Kontotyp och Redovisningsrörelsetyp. I frågor nås fördefinierade konfigurationsdata och systemuppräkningsvärden med hjälp av en literal av funktionstypen VALUE. Den här bokstaven låter dig förbättra läsbarheten för frågan och minska antalet frågeparametrar.

Exempel på att använda en bokstavlig MENANDE:

• WHERE City = VÄRDE(Directory.Cities.Moskva)
• WHERE City = VÄRDE(Directory.Cities.EmptyLink)
• WHEREProductType = VÄRDE(Enumeration.ProductTypes.Service)
• WHEREMovementType = VÄRDE(MovementTypeAccumulation.Incoming)
• WHERE RoutePoint = VÄRDE(BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Använd instruktionerna AUTO BESTÄLLNING Frågan kan ta lång tid att slutföra, så om sortering inte krävs är det bättre att inte använda den alls. I de flesta fall är det bäst att använda instruktionssortering SORTERA EFTER.

Automatisk beställning fungerar enligt följande principer:

• Om ORDER BY-satsen specificerades i begäran, kommer varje länk till tabellen som finns i denna sats att ersättas av de fält som tabellen sorteras efter som standard (för referensböcker är detta koden eller namnet, för dokument – dokumentdatum). Om fältet som ska sorteras hänvisar till en hierarkisk katalog, kommer hierarkisk sortering efter denna katalog att tillämpas.
• Om frågan inte har en ORDER BY-sats, men har en TOTAL-sats, kommer frågeresultatet att sorteras efter fälten som finns i TOTAL-satsen efter nyckeln ord programvara, i samma ordningsföljd och, om totalsummorna beräknades med referensfält, sedan genom standardsorteringsfälten för de tabeller som det fanns länkar till.
• Om frågan inte innehåller satserna ORDER BY och TOTAL, men det finns en GROUP BY-sats, kommer frågeresultatet att sorteras efter fälten som finns i klausulen i samma sekvens och, om grupperingen utfördes av referensfält , sedan som standard sortering av fälttabeller som refererades till.
• Om frågan inte innehåller ORDER BY-, TOTAL- eller GROUP BY-satser, kommer resultatet att sorteras efter standardsorteringsfälten för de tabeller som data väljs från, i den ordning de visas i frågan.
• Om frågan innehåller en TOTAL-sats beställs varje totalnivå separat.

3) För att undvika att en fråga upprepas till databasen när frågeresultatet visas för användaren (till exempel bygga en fråga eller visa frågeresultatet med hjälp av ett kalkylarksdokument), är det användbart att använda instruktionen INTRODUKTIONSLÄNKAR, vilket gör att du kan få en representation av ett referensvärde. Exempel:

Det är också möjligt att använda instruktioner PRESTANDA- utformad för att erhålla en strängrepresentation av ett värde av en godtycklig typ. Skillnaden mellan dessa instruktioner är att i det första fallet, om instruktionerna passerar en länk, kommer resultatet att vara en sträng. I andra fall blir resultatet värdet av den skickade parametern. I det andra fallet kommer resultatet av instruktionen alltid att vara en sträng!

4) Om begäran innehåller ett fält med en sammansatt typ, blir det för sådana fält nödvändigt att konvertera fältvärdena till en specifik typ med hjälp av en instruktion UTTRYCKA, vilket gör att du kan ta bort onödiga tabeller från den vänstra joinen med ett fält av en komplex datatyp och påskynda exekveringen av frågor. Exempel:

Det finns ett register för ackumulering av återstående gods, där registratorfältet har en sammansatt typ. I förfrågan väljs datum och dokumentnummer för mottagning av varor, medan vid åtkomst till dokumentdetaljerna via Registrar-fältet uppstår många vänsterkopplingar av ackumuleringsregistertabellen med tabellerna över registrardokument.

Kod 1C v 8.x SELECT
EXPRESS(Remaining Goods.Registrar AS Document.Receipt of Goods).Nummer AS-kvittonummer,
EXPRESS(Remaining Goods.Registrar AS Document.Receipt of Goods).Datum AS Mottagningsdatum
FRÅN
Register över ackumuleringar.Restering Goods AS Restering Goods

Om en typgjutning inte anses vara genomförbar kommer resultatet av typcasten att vara värdet NULL.

5) Glöm inte instruktionerna TILLÅTEN, vilket innebär att frågan endast kommer att välja poster som den aktuella användaren har rättigheter till. Om detta ord inte anges, om begäran väljer poster som användaren inte har rättigheter för, kommer begäran att behandlas med ett fel.

6) Om frågan använder en join, och vissa delar av joinen innehåller kapslade tabeller (ett dokument med en tabelldel), och vissa inte gör det, blir det nödvändigt att komplettera urvalslistan med fält - tomma kapslade tabeller. Detta görs med hjälp av ett nyckelord TÖM BORD, varefter aliasen för fälten som kommer att utgöra den kapslade tabellen indikeras inom parentes. Exempel:

Kod 1C v 8.x // Välj fält Antal och sammansättning
// från den virtuella tabellen Document.Expenditure
VÄLJ Link.Number, TEM TABELL.(Nr., Artikel, Kvantitet) SOM komposition
FRÅN Document.Expense Invoice
KOMBINERA ALLT
VÄLJ Link.Number, Contents.(LineNumber, Product, Quantity)
FRÅN Document.Invoice Document.Invoice.Composition.*

7) För att förhindra att dubbletter av rader visas i frågeresultatet bör du använda instruktionen OLIKA, eftersom det är mer visuellt och begripligt, och instruktionerna GRUPP AV används för att gruppera med aggregerade funktioner. Ksati, när du använder aggregerade funktioner, ett förslag GRUPP AV kanske inte specificeras alls, men alla frågeresultat kommer att grupperas på en enda rad. Exempel:

Kod 1C v 8.x // Det är nödvändigt att ta reda på vilka motparter
// varor skickades för perioden.
Välj Diverse
Document.Invoice.Motpart

8) Instruktioner GRUPP AV låter dig komma åt toppnivåfält, utan att gruppera resultaten efter dessa fält, om aggregerade funktioner tillämpas på fälten i en kapslad tabell. Även om 1C-hjälpen säger att vid gruppering av frågeresultat måste aggregerade funktioner anges i listan över urvalsfält, och förutom aggregatfunktioner i listan över urvalsfält är det tillåtet att endast ange de fält som grupperingen utförs av . Exempel:

Kod 1C v 8.x SELECT
Mottagande av varor och tjänster. varor. (SUM (kvantitet), nomenklatur),
Mottagande av varor och tjänster. Länk,
Mottagande av varor och tjänster Motpart
FRÅN
Dokument Mottagande av varor och tjänster HUR Mottagande av varor och tjänster
GRUPP AV
Mottagande av varor och tjänster. Varor. (Nomenklatur)

9) Instruktioner ÄR INGETär avsedd att ersätta värdet NULL till ett annat värde, men glöm inte att den andra parametern kommer att konverteras till typen av den första om typen av den första parametern är en sträng eller ett tal.

10) Vid kontakt huvudbord Du kan komma åt data i den underordnade tabellen. Den här funktionen kallas för avledningsfält för en underordnad tabell.

Exempel (sök efter dokument som innehåller en specifik produkt i tabelldelen):

Fördelen med denna fråga gentemot en fråga på den underordnade tabellen Receipt.Goods är att om det finns dubbletter i dokument, kommer frågeresultatet endast att returnera unika dokument utan att använda nyckelordet DIFFERENT.

11) En intressant variant av operator B är att kontrollera om en beställd uppsättning ingår i uppsättningen av sådana uppsättningar (Fält1, Fält2, ..., FältN) B (Fält1, Fält2, ..., FältN).

Kod 1C v 8.x SELECT
Motparter.Länk
VAR
(Motparter.länk, produkter.länk) B
(VÄLJ Försäljning.Kund, Försäljningsprodukt
FRÅN RegisterAccumulation.Sales AS Sales)
FRÅN
Katalog. Motparter,
Katalog.Produkter

12) Använd virtuella frågetabeller när det är möjligt. När du skapar en fråga tillhandahåller systemet ett antal virtuella tabeller som datakällor - det är tabeller som också är resultatet av en fråga som systemet genererar vid den tidpunkt då motsvarande kodavsnitt exekveras.

Utvecklaren kan självständigt erhålla samma data som systemet tillhandahåller honom som virtuella tabeller, men algoritmen för att erhålla dessa data kommer inte att optimeras eftersom:

Alla virtuella tabeller parametreras, det vill säga utvecklaren ges möjlighet att ställa in några parametrar som systemet kommer att använda när det genererar en begäran om att skapa en virtuell tabell. Beroende på vilka parametrar för den virtuella tabellen som specificeras av utvecklaren kan systemet generera OLIKA frågor för att erhålla samma virtuella tabell, och de kommer att optimeras med avseende på de parametrar som skickas.

Det är inte alltid möjligt för en utvecklare att få tillgång till den data som systemet har tillgång till.

13) I driftsättet klient-server, funktionen SUBSTRING() implementeras med hjälp av SUBSTRING()-funktionen för motsvarande SQL-sats som skickas till SQL Server-databasservern, som beräknar typen av resultatet av SUBSTRING()-funktionen med hjälp av komplexa regler beroende på typen och värdena för dess parametrar, som samt beroende på i vilket sammanhang det används. I de flesta fall har dessa regler ingen effekt på exekveringen av frågor, men det finns tillfällen då den maximala resultatradlängden som beräknats av SQL Server är viktig för exekveringen av frågor. Det är viktigt att komma ihåg att i vissa sammanhang när du använder funktionen SUBSTRING() kan den maximala längden på resultatet vara lika med den maximala längden på en sträng med begränsad längd, som i SQL Server är 4000 tecken. Detta kan göra att frågan kraschar oväntat:

Microsoft OLE DB-leverantör för SQL Server: Varning: Frågeprocessorn kunde inte skapa en frågeplan från optimeraren eftersom den totala längden på alla kolumner i GROUP BY- eller ORDER BY-satsdelen överstiger 8000 byte.

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

14) Använd med försiktighet ELLER i design VAR, eftersom användning av ett OR-villkor kan göra frågan betydligt tyngre. Problemet kan lösas genom design KOMBINERA ALLT. Exempel:

Kod 1C v 8.x SELECT

FRÅN

VAR
_Demo Contractors.Link =Länk1
KOMBINERA ALLT
VÄLJA
_Demo Contractors.NameFull
FRÅN
Directory._Demo Motparter HUR MAN _Demo Motparter
VAR
_Demo Contractors.Link = Länk2

15) Skick INTE I i design VARökar frågekörningstiden, eftersom detta är ett slags INTE (OR1 OR2 ... ORn), så för stora bord försök att använda LEFT JOIN med skicket ÄR NULL. Exempel:

Kod 1C v 8.x SELECT
_Demo Contractors.Link
FRÅN
Directory._Demo Motparter HUR MAN _Demo Motparter
VÄNSTER ANSLUTNING Dokument._Köparens demoorder HUR MAN _Köparens demoorder
Programvara _Demo Motparter Länk = _Demo Beställning av köparen Motpart
VAR
_Demobeställning av köparen Motparten ÄR NULL

16) Vid användning Tillfälliga bord Du måste indexera villkoren och sammanfogningsfälten i dessa tabeller, MEN när du använder index kan frågan vara ännu långsammare. Därför är det nödvändigt att analysera varje fråga med och utan ett index, mäta hastigheten för utförande av en fråga och fatta ett slutgiltigt beslut.

Om du placerar data i en temporär tabell som initialt indexeras av vissa fält, kommer den temporära tabellen inte längre att ha ett index på dessa fält.

17) Om du inte använder Tillfällig bordschef, då finns det inget behov av att uttryckligen ta bort den temporära tabellen, den kommer att raderas efter att batchfrågan är klar, annars bör du ta bort den temporära tabellen med någon av följande metoder: kommando: FÖRSTÖRA anrop metoden i begäran TemporaryTableManager.Close().

Och förutom videon från Evgeny Gilev: Typiska fel när du skriver frågor i 1C:

Frågespråket är en av de grundläggande mekanismerna i 1C 8.3 för utvecklare. Med hjälp av frågor kan du snabbt hämta all data som lagras i databasen. Dess syntax är mycket lik SQL, men det finns vissa skillnader.

De främsta fördelarna med frågespråket 1C 8.3 (8.2) framför SQL:

• referensfält därav (referenser en eller flera punkter till objektdetaljer);
• att arbeta med resultat är mycket bekvämt;
• möjligheten att skapa virtuella tabeller;
• begäran kan skrivas på både engelska och ryska;
• förmåga att blockera data för att undvika låsningar.

Nackdelar med frågespråket i 1C:

• till skillnad från SQL tillåter inte 1C-frågor att ändra data;
• brist på lagrade procedurer;
• omöjlighet att konvertera en sträng till ett tal.

Låt oss ta en titt på vår minihandledning om de grundläggande konstruktionerna av frågespråket 1C.

På grund av det faktum att frågor i 1C endast tillåter dig att ta emot data, måste varje fråga börja med ordet "SELECT". Efter detta kommando indikeras fälten från vilka data måste hämtas. Om du anger "*" kommer alla tillgängliga fält att väljas. Den plats från vilken data kommer att väljas (dokument, register, kataloger, etc.) anges efter ordet "FRÅN".

I exemplet som diskuteras nedan väljs namnen på hela nomenklaturen från katalogen "Nomenklatur". Efter ordet "HUR" anges alias (namn) för tabeller och fält.

VÄLJA
Nomenklatur Namn AS Namn på nomenklatur
FRÅN
Directory.Nomenclature AS Nomenclature

Bredvid kommandot "SELECT" kan du ange nyckelord:

• OLIKA. Frågan kommer endast att välja rader som skiljer sig åt i minst ett fält (utan dubbletter).
• Första n, Var n– antalet rader från början av resultatet som måste väljas. Oftast används denna konstruktion i samband med sortering (ORDER BY). Till exempel när du behöver välja ett visst antal dokument som är aktuella efter datum.
• TILLÅTEN. Denna design låter dig välja från databasen endast de poster som är tillgängliga för den aktuella användaren. Baserat på användningen av detta nyckelord kommer användaren att få ett felmeddelande när han försöker söka efter poster som de inte har tillgång till.

Dessa nyckelord kan användas tillsammans eller separat.

FÖR FÖRÄNDRING

Detta förslag blockerar data för att förhindra ömsesidiga konflikter. Låst data kommer inte att läsas från en annan anslutning förrän transaktionen avslutas. I den här klausulen kan du ange specifika tabeller som måste låsas. I annat alla kommer att blockeras. Designen är endast relevant för det automatiska låsläget.

Oftast används "FOR CHANGE"-klausulen när man tar emot saldon. När allt kommer omkring, när flera användare arbetar i programmet samtidigt, medan en tar emot saldon, kan en annan ändra dem. I det här fallet kommer den resulterande resten inte längre att vara korrekt. Om du blockerar uppgifterna med detta förslag, tills den första anställde får rätt balans och utför alla nödvändiga manipulationer med det, kommer den andra anställde att tvingas vänta.

VÄLJA
Ömsesidiga uppgörelser. Anställd,
Ömsesidiga avräkningar Antal ömsesidiga avräkningar Saldo
FRÅN
Register över ackumuleringar Ömsesidiga avräkningar med anställda Saldon AS Ömsesidiga avräkningar
FÖR FÖRÄNDRING

VAR

Designen är nödvändig för att införa någon form av urval på den uppladdade informationen. I vissa fall av att hämta data från register är det mer rimligt att specificera urvalsvillkor i parametrarna för virtuella tabeller. När du använder "WHERE" hämtas alla poster först, och först därefter tillämpas urvalet, vilket avsevärt saktar ner frågan.

Nedan finns ett exempel på en förfrågan om att få kontaktpersoner för en specifik tjänst. Valparametern har formatet: &ParameterName (parameternamnet är godtyckligt).

URVAL (FALL)

Designen låter dig ange villkor direkt i förfrågans brödtext.

I exemplet nedan kommer "AdditionalField" att innehålla text beroende på om dokumentet är upplagt eller inte:

VÄLJA
TillträdeT&U.länk,
VAL
NÄR AntagningT&U.Utförs
DÅ "Dokumentet har godkänts!"
ANNAT "Dokumentet lades inte upp..."
AVSLUTA SOM Extrafält
FRÅN
Dokument Mottagande av varor och tjänster HUR Mottagningsvillkor

ANSLUTA SIG

Joins länkar två tabeller baserat på ett specifikt relationsvillkor.

VÄNSTER/HÖGER ANSLUTNING

Kärnan i LEFT join är att den första specificerade tabellen tas i sin helhet och den andra är länkad till den enligt anslutningsvillkoret. Om det inte finns några poster som motsvarar den första tabellen i den andra, ersätts NULL som deras värden. Enkelt uttryckt är huvudtabellen den först specificerade tabellen och data från den andra tabellen (om någon) har redan ersatt dess data.

Till exempel är det nödvändigt att få artikelartiklar från dokumenten "Mottagande av varor och tjänster" och priser från informationsregistret "Artikelpriser". I det här fallet, om priset för någon position inte hittas, ersätt NULL istället. Alla objekt från dokumentet kommer att väljas oavsett om de har ett pris eller inte.

VÄLJA
Kvitto&U.nomenklatur,
Priser.Pris
FRÅN
Dokument. Mottagande av varor och tjänster. Varor HUR Mottagningsvillkor
INTERN JOIN RegisterInformation.PricesNomenclature.SliceLast AS Priser
Programvarukvitto&U.Nomenclature = Priser.Nomenklatur

I RÄTT är allt precis tvärtom.

FULL ANSLUTNING

Denna typ av anslutning skiljer sig från de tidigare genom att som ett resultat kommer alla poster i både den första tabellen och den andra att returneras. Om inga poster hittas i den första eller andra tabellen baserat på det angivna länkvillkoret kommer NULL att returneras istället.

När du använder en fullständig anslutning i det föregående exemplet kommer alla artikelartiklar från dokumentet "Mottagning av varor och tjänster" och alla de senaste priserna från registret "Artikelpriser" att väljas. Värdena för icke-funna poster i både den första och andra tabellen kommer att vara lika med NULL.

INRE KOPPLING

Skillnaden mellan en INNER JOIN och en FULL JOIN är att om en post inte hittas i minst en av tabellerna kommer frågan inte att visa den alls. Som ett resultat kommer endast de varuposter från dokumentet "Mottagande av varor och tjänster" att väljas för vilka det finns register i informationsregistret "Artikelpriser", om vi i föregående exempel ersätter "FULLSTÄNDIG" med "INTERN".

GRUPP AV

Genom att gruppera i 1C-frågor kan du komprimera tabellrader (grupperingsfält) enligt en specifik gemensamt drag(grupperade fält). Grupperingsfält kan endast visas med aggregatfunktioner.

Resultatet av följande fråga blir en lista över produkttyper med maxpriser för dem.

VÄLJA
,
MAX(Pris.Pris) AS Pris
FRÅN

GRUPP AV
Priser.Nomenklatur.Typ av nomenklatur

RESULTAT

Till skillnad från gruppering, när du använder totaler, visas alla poster och totala rader läggs till dem. Gruppering visar endast generaliserade poster.

Resultaten kan sammanfattas för hela tabellen (med hjälp av nyckelordet "GENERAL"), för flera fält, för fält med hierarkisk struktur (sökord "HIERARKI", "ENDAST HIERARKI"). När man sammanfattar resultat är det inte nödvändigt att använda aggregerade funktioner.

Låt oss titta på ett exempel som liknar exemplet ovan med hjälp av gruppering. I det här fallet returnerar frågeresultatet inte bara grupperade fält utan även detaljerade poster.

VÄLJA
Priser.Nomenklatur.Typ av nomenklatur AS Typ av nomenklatur,
Priser.Pris AS Pris
FRÅN
Register över information. Priser på nomenklatur. Ögonblicksbild av de senaste AS-priserna
RESULTAT
MAXIMUM(Pris)
FÖRBI
TypNomenklatur

HAR

Den här operatorn liknar WHERE-operatorn, men används endast för aggregerade funktioner. De återstående fälten, förutom de som används av denna operatör, måste grupperas. WHERE-operatorn är inte tillämplig på aggregerade funktioner.

I exemplet nedan väljs maxpriserna för en vara om de överstiger 1000, grupperade efter artikeltyp.

VÄLJA

MAX(Pris.Pris) AS Pris
FRÅN
Register över information. Priser på nomenklatur. Ögonblicksbild av de senaste AS-priserna
GRUPP AV
Priser.Nomenklatur.Typ av nomenklatur
HAR
MAXIMUM(Priser.Pris) > 1000

SORTERA EFTER

Operatören ORDER BY sorterar resultatet av en fråga. För att säkerställa att poster visas i en konsekvent ordning, används AUTO ORDER. Primitiva typer sorteras enligt de vanliga reglerna. Referenstyper sorteras efter GUID.

Ett exempel på att få en lista över anställda sorterade efter namn:

VÄLJA
Anställda. Namn AS Namn
FRÅN
Directory.Employees HUR Anställda
SORTERA EFTER
namn
AUTO BESTÄLLNING

Andra 1C frågespråkskonstruktioner

• KOMBINERA– resultat av två frågor till en.
• KOMBINERA ALLT– liknande COMBINE, men utan att gruppera identiska rader.
• TÖMT BORD– används ibland vid sammanfogning av frågor för att ange en tom kapslad tabell.
• PLATS– skapar en tillfällig tabell för att optimera komplexa 1C-frågor. Sådana förfrågningar kallas för batchförfrågningar.

Språkfunktioner för frågor

• SUBSTRING trunkerar en sträng från en angiven position till ett specificerat antal tecken.
• ÅR...ANDRA låter dig få det valda värdet av en numerisk typ. Ingångsparametern är datumet.
• BÖRJAN PÅ PERIODEN och SLUT PÅ PERIODEN används när man arbetar med datum. Typen av period (DAG, MÅNAD, ÅR, etc.) anges som en extra parameter.
• ADDKDATE låter dig lägga till eller subtrahera en angiven tid av en viss typ från ett datum (ANDRA, MINUT, DAG, etc.).
• DIFERENCEDATE bestämmer skillnaden mellan två datum och anger typen av utdatavärde (DAG, ÅR, MÅNAD, etc.).
• ÄR INGET ersätter det saknade värdet med det angivna uttrycket.
• REPRESENTATION och REPRESENTATIONSLÄNKAR få en strängrepresentation av det angivna fältet. Tillämpa på alla värden respektive endast referensvärden.
• TYP, TYP VÄRDEN används för att bestämma typen av ingångsparameter.
• LÄNKär en logisk jämförelseoperator för attributvärdetypen.
• UTTRYCKA används för att konvertera ett värde till önskad typ.
• DATUM TID får ett värde av typen "Datum" från numeriska värden (år, månad, dag, timme, minut, sekund).
• MENANDE i en 1C-förfrågan används den för att indikera fördefinierade värden - kataloger, uppräkningar, planer för typer av egenskaper. Användningsexempel: " Där juridisk person = värde(uppräkning. juridisk person. individuell)«.

Frågebyggare

För att skapa frågor med 1C finns det en mycket bekväm inbyggd mekanism - frågedesignern. Den innehåller följande huvudflikar:

• "Tabell och fält" - innehåller de fält som måste väljas och deras källor.
• "Anslutningar" - beskriver villkoren för CONNECTION-strukturen.
• "Gruppering" – innehåller en beskrivning av grupperingsstrukturer och summerade fält baserat på dem.
• "Villkor" - ansvarar för att välja data i begäran.
• "Ytterligare" - Extra tillval begäran, såsom nyckelord för kommandot "SELECT", etc.
• "Joins/Aliases" - möjligheterna att sammanfoga tabeller anges och alias specificeras ("HOW"-konstruktionen).
• "Order" ansvarar för att sortera resultatet av frågor.
• "Totals" - liknande fliken "Gruppering", men används för "TOTALS"-konstruktionen.

Texten i själva begäran kan ses genom att klicka på knappen "Begäran" i det nedre vänstra hörnet. I detta formulär kan det korrigeras manuellt eller kopieras.

Begär konsol

För att snabbt se resultatet av en fråga i Enterprise-läge, eller felsöka komplexa frågor, använd . Den innehåller texten i begäran, ställer in parametrarna och visar resultatet.

Du kan ladda ner frågekonsolen på ITS-disken eller via .

20.09.2014

Det finns ett "Tillåtet" direktiv i frågespråket. Den är utformad för att tillåta plattformen att filtrera bort poster som användaren inte har rättigheter till vid inställning av begränsningar på databaspostnivå.

Det verkar som om det är bättre att alltid använda detta direktiv i frågor. Jag kommer att hävda att det inte är så. Jag kommer också att hävda att du om möjligt bör undvika att använda det, här är varför.

Låt oss säga att vi gör en rapport om ömsesidiga uppgörelser individer. Användaren har rättigheter till en organisation, det finns mer än en organisation i databasen och databasen har begränsningar på rekordnivå aktiverade. I databasen finns också ett register "Ömsesidiga uppgörelser" med dimensionerna "Organisation" och "Individuell". Om det finns en begäran i systemet

"Välja

Organisation,

Enskild

och den kommer att utföras på uppdrag av en användare med behörighet för en organisation, då kommer begäran inte att exekveras om det finns register över andra organisationer i detta register. Ett fel kommer att uppstå och felbeskrivningen blir "Användaren har inte tillräckliga rättigheter för att slutföra begäran!" och detta är sant, plattformen fuskar inte, eftersom den inte har rättigheter till register från andra organisationer i detta register.

Vad ska man göra i det här fallet, använd direktivet "Tillåtet"? Enligt min mening är det inte värt det. Du behöver bara ställa in valet efter organisation och användaren kommer att kunna generera en rapport. Frågan för en rapport med datasammansättning kommer att se ut så här

"Välja

Organisation,

Enskild

(Välja

Organisation

Enskild)

Från ackumulationsregistret Ömsesidiga uppgörelser

(Var

Organisation

Enskild)

Om användaren kör en fråga i tabellen utan val kommer rapporten inte att genereras, och användaren kommer inte att känna igen data för andra organisationer, men om han väljer för sin organisation kommer den att genereras med rätt data.

Du kan fråga igen - "Varför ska du inte använda det tillåtna direktivet?" Detta kräver omedelbart val och skyddar användaren från onödiga meddelanden!

Svaret på denna fråga kommer att vara följande: hur i detta fall kommer användaren att veta att all nödvändig information ingår i rapporten. Låt oss säga att den här användaren tidigare arbetade under fulla rättigheter och gjorde ett misstag och valde en individ från en annan organisation i dokumentet. Det kan också finnas en situation där data laddades ner - och en uppdelning av en annan organisation registrerades i organisationens dokument (i ZUP är de också föremål för restriktioner för ägaren). I det här fallet kommer direktivet "Tillåtet" att skära av förbjudna data utan några meddelanden till användaren, och han kommer inte att veta att inte allt som ska inkluderas i rapporten.

Därför bör du inte urskillningslöst inkludera detta direktiv i förfrågningar om standardkonfigurationer, eftersom detta är ett fel. Det avråds starkt från att göra detta i reglerade rapporteringsförfrågningar. Du bör inte heller göra detta i andra rapporter och dokument där riktighet av information behövs.

Men hur kan du undvika att programmet "kraschar" om du inte har tillräckligt med rättigheter?

Ja, det är väldigt enkelt, du måste använda kommandot "Try", här är ett exempel:

Försök

Request.Run();

Undantag

Report(ErrorDescription());

Slutförsök;

I rapporter från använder ACS Programkoden för att utföra rapporten måste skrivas manuellt, även genom ett försök.

Som ett resultat kommer användaren inte att få felaktig information och kommer att få ett rimligt felmeddelande.

Du kan bekanta dig med nyanserna av att ställa in RLS i separata avdelningar i vår artikel.

Konfigurationsobjektet "roll" ger en uppsättning rättigheter till operationer (åtgärder) över konfigurationsobjekt.

Roll "Fullständiga rättigheter".

Detta är bara en roll (ej fördefinierad) där alla typer av rättigheter till alla konfigurationsobjekt kontrolleras.

Det som skiljer den från andra roller är närvaron av rätten "Administration".

Om minst en användare har skapats börjar systemet kontrollera om det finns "Administration"-rättigheter - minst en användare måste ha det.

Åtkomstbegränsningar på rekordnivå

Row Level Security (RLS) – begränsning på rekordnivå.

Mekanismen för dataåtkomstbegränsningar låter dig hantera åtkomsträttigheter inte bara på nivån för metadataobjekt, utan också på nivån för databasobjekt. Följande objekt kan användas för att begränsa åtkomst till data:

• roller,
• sessionsparametrar,
• funktionella alternativ,
• privilegierade delade moduler,
• sökord TILLÅT på frågespråket.

Mekanismen är utformad för att begränsa åtkomst till metadataobjekttabellposter baserat på godtyckliga villkor som åläggs värdena för radfälten i dessa tabeller. Till exempel för att bara se register för "dina" motparter, organisationer etc.

Teknisk implementering av åtkomstbegränsningar i 1C

1C genererar en begäran till DBMS. Serverklustret lägger till en sektion WHERE till begäran, som innehåller texten till villkoret för att begränsa åtkomst via RLS, sedan skickas denna begäran till DBMS, den extraherade datan returneras till 1C-klienten.

Denna mekanism kommer att fungera för varje begäran från klienten:

• i rapporter,
• i dynamiska listor och i vanliga listformer
• i anpassade frågor.

En sådan implementering av mekanismen påverkar i hög grad prestandan.

Sätt att kringgå åtkomstbegränsningar.

I stora resurskrävande operationer (t.ex. bearbetning av ompostering av dokument) kan en del av koden flyttas till privilegierade moduler.

A) Privilegerad modul är en vanlig modul med flaggan "Privileged" i egenskaperna.

Dess egenhet är att koden i den exekveras utan någon kontroll av åtkomsträttigheter, inklusive RLS.

B) Också privilegierad läget kan slås på för dokumentobjektmoduler. Detta görs i dokumentets egenskaper, flagga

• Privilegerad behandling vid genomförande
• Privilegerat läge när du avbryter en transaktion

B) Metod SetPrivilegedMode()

Systemkommandot låter dig göra en del av koden för valfri modul privilegierad.

Från nästa kodrad kommer det privilegierade exekveringsläget att fungera.

Det kommer att fungera tills raden för att avaktivera detta läge eller tills slutet av proceduren/funktionen

(Sann);

// vilken kod som helst här kommer att exekveras utan rättighetskontroll och RLS

SetPrivilegedMode(Lögn ); // eller slutet av proceduren / funktion

Antalet gånger privilegierat läge är aktiverat måste matcha antalet gånger det har inaktiverats. Men om inom en procedur eller funktion det privilegierade läget har aktiverats (en gång eller flera), men inte stängts av, kommer systemet automatiskt att stängas av så många gånger som det fanns ofullständiga påslag i proceduren eller funktionen som lämnades

Om i en procedur eller funktion anropar en metod SetPrivilegedMode(False) gjorde mer än metodanrop SetPrivilegedMode(True ), då kommer ett undantag att kastas

Fungera PrivilegedMode() returnerar True om privilegierat läge fortfarande är aktiverat och False om det är helt inaktiverat. Detta analyserar inte antalet privilegierade lägesinställningar i en viss funktion.

Alla anropade procedurer och funktioner kommer också att köras i privilegierat läge.

Det är också möjligt att starta en privilegierad session. Detta är en session där privilegierat läge etableras från början av systemet. Dessutom, under drift metoden PrivilegedMode() kommer alltid att returnera True, och möjligheten att inaktivera privilegierat läge stöds inte. Endast en användare som har administrativa rättigheter (administrationsrättigheter) kan starta en privilegierad session. Du kan starta en session med knappen kommandorad starta klientapplikationen UsePrivilegedMode eller anslutningssträngparameter med informationsbas prmod.

Frågan uppstår naturligtvis: Varför då överhuvudtaget sätta upp åtkomstbegränsningar om det så lätt kan kringgås?

Säkert läge.

Ja, du kan skriva extern bearbetning med ett privilegierat körningsläge och ta bort/korrupta data. För att förhindra detta har systemet en global kontextmetod

Ställ inSafeMode().

Säkert läge ignorerar bland annat privilegierat läge.

Det måste installeras innan externa processorer anropas programmässigt eller exporteras till procedurer och funktioner från deras moduler.

När förbjudna operationer utförs skapas ett undantag under körning.

Dessutom kan du på rollinställningarsnivån inaktivera möjligheten för användare att interaktivt starta externa rapporter och bearbetning.

Konfigurera åtkomstbegränsningar

RLS kan endast konfigureras för rättigheter:

• läs (välj)
• lägga till (infoga)
• ändra (uppdatering)
• radera

För läsoperationer och radering måste ett objekt som finns i databasen följa begränsningar för dataåtkomst.

För tilläggsoperationen Dataåtkomstbegränsningen måste motsvara det objekt som planeras att skrivas till databasen.

För ändringsoperation dataåtkomstbegränsningen måste följa objektet både före ändringen (så att objektet läses) och efter ändringen (så att objektet skrivs).

För alla andra rättigheter finns inget sådant alternativ.

Låt oss lägga till en ny begränsning för "läs"-rättigheten för "Nomenklatur"-katalogen. En lista över fält för vilka du kan konfigurera den tillagda begränsningen öppnas.

Det betyder att om du försöker komma åt markerade fält kommer begränsningen att utlösas, men om du försöker komma åt omarkerade fält kommer begränsningen inte att fungera.

Om du väljer flaggan " Andra fält", kommer begränsningen att konfigureras för alla tabellfält, utom för fält för vilka begränsningar uttryckligen anges.

*Funktion: för rättigheter att lägga till, ändra, ta bort:

• Begränsningen kan endast konfigureras för alla fält.
• Det kan bara finnas en begränsning.

För "Läs" höger kan du konfigurera flera villkor; de kommer att kombineras med den logiska operatorn "AND".

Inte alla fält i huvudbegränsningsdataobjektet får användas i begränsningar för följande typer av databasobjekt:

• i ackumuleringsregister kan åtkomstbegränsningar endast innehålla mätningar av begränsningens huvudobjekt;
• i redovisningsregister kan begränsningar endast använda balansräkningsmått av begränsningens huvudobjekt

Om, under förhållanden med begränsad tillgång till data förhandlingsbart register ackumulering, mätningar som inte ingår i totalsummorna används, sedan vid åtkomst till den virtuella tabellen över varv används inte de lagrade totalerna och frågan exekveras helt enligt rörelsetabellen.

Mekanism för att införa åtkomstbegränsningar.

Varje operation på data lagrad i en databas i 1C:Enterprise leder i slutändan till ett anrop till databasen med någon begäran om att läsa eller ändra data. I processen att köra frågor till databasen, inför de interna mekanismerna i 1C:Enterprise åtkomstbegränsningar. Vart i:

• En lista över rättigheter skapas(läs, lägg till, ändra, ta bort), en lista över databastabeller och en lista över fält som används av denna fråga.
• Från alla roller för den aktuella användaren åtkomstbegränsningar är valda till data för alla rättigheter, tabeller och fält som är involverade i begäran. Dessutom, om en roll inte innehåller begränsningar för åtkomst till data i en tabell eller ett fält, betyder det att värdena för de obligatoriska fälten från alla poster är tillgängliga i den här tabellen. Med andra ord betyder frånvaron av en dataåtkomstbegränsning närvaron av en begränsning VAR ÄR Sanningen.
• Hämtar de aktuella värdena för alla sessionsparametrar och funktionella alternativ deltar i de valda restriktionerna.

För att få värdet på en sessionsparameter eller funktionellt alternativ Den aktuella användaren behöver inte ha behörighet för att hämta detta värde. Men om värdet för någon sessionsparameter inte har ställts in, kommer ett fel att uppstå och databasfrågan kommer inte att köras.

Restriktioner härledda från en roll kombineras med AND-operationen.

Restriktioner härledda från olika roller kombineras med ELLER-operationen.

De konstruerade villkoren läggs till i SQL-frågorna med vilka 1C: Enterprise kommer åt DBMS. Vid åtkomst till data från åtkomstbegränsningsvillkor utförs inte rättighetskontroll (varken för metadataobjekt eller databasobjekt). Dessutom beror mekanismen för att lägga till villkor på den valda metoden för drift av begränsningarna "alla" eller "tillåtna".

*Funktion: Om en användare har tillgång till flera roller med konfigurerade begränsningar på postnivå för ett objekt, så läggs i detta fall villkoren för begränsningarna till med den logiska operationen "ELLER". Med andra ord är användarens befogenheter kumulativa.

Detta leder till följande slutsats: låt inte villkoren för att begränsa åtkomsten till ett objekt i olika roller skära varandra, eftersom i det här fallet kommer texten i begäran att vara mycket komplicerad och detta kommer att påverka prestandan.

"Allt"-metoden.

Vid införande av begränsningar med ”alla”-metoden läggs villkor och fält till i SQL-frågor så att 1C:Enterprise kan få information om huruvida, under körningen av en databasfråga, data som var förbjudna för en viss användare användes eller inte. Om förbjuden data användes kommer begäran att krascha på grund av en åtkomstöverträdelse.

Att införa åtkomstbegränsningar med "alla"-metoden presenteras schematiskt i figuren:

"Tillåten" metod.

När begränsningar tillämpas med metoden "tillåten" läggs villkor till i SQL-frågor så att poster som är förbjudna för den aktuella användaren inte påverkar resultatet av frågan. Med andra ord, när begränsningar införs i det "tillåtna" läget, anses poster som är förbjudna för en given användare saknas och påverkar inte resultatet av operationen, som visas schematiskt i figuren:

Dataåtkomstrestriktioner påläggs databasobjekt när 1C:Enterprise går in i databasen.

I klient-serverversionen av 1C:Enterprise tillämpas begränsningar på 1C:Enterprise-servern.

Det här alternativet (TILLÅT) kommer dock inte att fungera om vi i en fråga hänvisar till en tabell för vilken åtkomstbegränsningar inte är konfigurerade, men som innehåller referenser till tabellrader med konfigurerade begränsningar. I det här fallet kommer frågeresultatet att visa "<Объект не найден>......" istället för referensfältets värde.

Om du utvecklar en rapport eller bearbetar med standard- eller anpassade konfigurationsfrågor, kontrollera alltid flaggan "Tillåten". för att rapporten ska fungera under vilken användare som helst med vilken uppsättning rättigheter som helst.

Vid objektläsning av data från databasen är det inte möjligt att ställa in flaggan "Tillåten". Därför är det nödvändigt konfigurera urval för objektläsning, med hänsyn till eventuella begränsningar av åtkomsträttigheter för användaren. Det finns inga sätt att erhålla endast tillåtna data inom objektteknik.

Det är viktigt att om en fråga inte anger nyckelordet ALLOWED, får alla val som anges i den frågan inte komma i konflikt med någon av läsbegränsningarna för databasobjekten som används i frågan. Dessutom, om frågan använder virtuella tabeller, måste motsvarande val tillämpas på själva de virtuella tabellerna.

Övning 1. Frågebyggare i RLS-inställningar.

Låt oss komponera texten i avsnittet "VAR" i frågan till katalogen. Du kan använda frågebyggaren.
Designern har ett avskalat utseende.

Fliken "Tabell".

Huvudtabellen kommer att vara tabellen för objektet för vilket begränsningen konfigureras.

Du kan också välja andra tabeller och skapa olika kopplingar mellan dem på fliken "Relationer".

Fliken "Villkor"

Här kan du konfigurera de faktiska åtkomstbegränsningsvillkoren

Låt oss lägga till villkor till "Pris"-attributet i nomenklaturkatalogen för rätten att "läsa" till alla fält i tabellen.

"Nomenklatur VAR Nomenklatur. Pris > 500"

Låt oss se hur denna enkla regel fungerar. Katalogtabellen innehåller följande element:

Efter att ha ställt in en åtkomstbegränsning kommer tabellen endast att visa element som uppfyller villkoret:

Grupper försvann också. Låt oss ändra texten i begränsningen

“Nomenklatur VAR Nomenklatur.Pris > 500

ELLER nomenklatur.Detta är en grupp"

Tja, nu är det vad du behöver.

Om du tar bort visningen av "kod"-fältet i listinställningarna kommer alla element i katalogen att visas, d.v.s. begränsningen fungerade inte. Om du ställer in "Kod"-fältet för att visa, kommer begränsningen att fungera.

I det här fallet, trots att katalogelementet är synligt i listfältet, kan dess form inte öppnas eftersom en begränsning av attributet är konfigurerad. Samma sak händer i en godtycklig begäran: när du försöker få en "begränsad" egenskap kommer det att uppstå ett åtkomstfel.

Om du försöker få de "begränsade" referenserna programmatiskt kommer ett åtkomstfel också att kastas.

Dessutom kommer det inte att vara möjligt att komma åt några fält av ett objekt via en länk, eftersom när man tar emot en länk läser systemet hela objektet, och om det innehåller "begränsade" detaljer kommer objektet inte att läsas.

När du arbetar programmatiskt med databasobjekt måste du därför tänka på möjliga begränsningar på postnivå och få alla nödvändiga objektdata på begäran och sedan placera dem i en struktur eller exekvera en del av koden i en privilegierad modul.

Efter att ha ställt in åtkomstbegränsningen ändrades visningen av raden i listan över rättigheter - den blev grå och en ikon dök upp.

Begränsningar vid inställning av åtkomst (RLS).

• Det finns ingen sammanfattningssektion;
• Virtuella registertabeller kan inte nås;
• Du kan inte använda parametrar explicit;
• Kan användas i kapslade frågor alla>/span> frågespråksverktyg förutom:
  • operatör I HIERARKI;
  • RESULTAT förslag;
  • kapslade frågeresultat får inte innehålla tabelldelar>/span>;
  • virtuella tabeller, i synnerhet saldon och omsättningar

Praxis 2. Nomenklatur med aktuellt pris.

Gör en åtkomstbegränsning om du behöver visa artiklar med ett aktuellt pris som är högre än ett visst värde, till exempel 100.

Lösning:

Vi lägger till en ny regel för åtkomstbegränsning för katalogen "Nomenklatur" med rättigheten "läs".
Välj "andra fält".
I konstruktorn lägger vi till en kapslad fråga. I den väljer du informationsregistertabellen "Artikelpriser".
Det finns ingen "order"-flik - detta är en funktion hos frågedesignern för att skapa en begäran om åtkomstbegränsning.
På fliken "Avancerat", ställ in "först 999999999", fliken "beställning" visas.
Vi ställer in beställning efter fältet "Period" i fallande ordning.
Sedan sätter vi upp en koppling mellan huvudtabellen och underfrågan genom referens.

Åtkomstbegränsningsmallar.

Övning 3. Begränsning av "motparter" genom värde i en konstant.

Låt oss ställa in en åtkomstbegränsning för katalogen Motparter baserat på värdet som lagras i konstanten.

Dessutom måste du ställa in en begränsning för alla objekt som använder katalogen "Motparter" i detaljerna.

Lösning

För katalogen "Motparter" kommer vi att sätta upp en begränsning för "läs"-rätten genom att lägga till en kapslad fråga till konstanten i avsnittet "Villkor". Glöm inte detta är en grupp.

Vi ser ett problem, Counterpartyes-katalogen är korrekt filtrerad och alla dokument med attributet "Counterparty" visas, vissa med "trasiga" länkar i attributet "Counterparty".

Nu måste du konfigurera åtkomstbegränsningar för alla objekt som använder länken till "Konton". Låt oss hitta dem med hjälp av tjänsten "sök efter länkar till ett objekt".

Låt oss kopiera och något ändra texten i RLS-villkoret från katalogen "Motparter". Detta måste göras så många gånger som det finns föremål som hittas.

Eller använd ett åtkomstbegränsningsmönster för att undvika problem med kodduplicering.

Åtkomstbegränsningsmallar konfigureras på rollnivå och kan användas för alla objekt inom den redigerade rollen.

Du kan lägga till vilken del av åtkomstbegränsningstext som helst i mallen. Mallen anropas med hjälp av symbolen "#". Till exempel #TemplateCounterparty.

Genom # i 1C skrivs instruktioner till förprocessorn. I samband med att köra åtkomstbegränsningsinställningar ersätter plattformen mallanropstexten med malltexten.

Låt oss lägga till texten efter ordet WHERE i mallen "Contractor Template", förutom texten om EtoGroup.

Parametrar i mallar för åtkomstbegränsning.

Låt oss fortsätta att lösa problem 2.

Problemet är nu att huvudtabellen i katalogen heter "motpart", i dokumentet "Kvittofaktura". Fältet som kontrolleras i katalogen kallas "länk", i dokumentet kallas det "Motpart".

Låt oss ändra namnet på huvudtabellen i malltexten till "#CurrentTable"

"#CurrentTable" är en fördefinierad parameter.

Och genom en punkt anger vi numret på ingångsparametern - ".#Parameter(1)

"#Parameter" är också ett fördefinierat värde. Kan innehålla ett godtyckligt antal indataparametrar. De adresseras med serienummer.

I texten till åtkomstbegränsningarna för katalogen anger vi följande:

För dokumentet följande:

"Försäljning av varor WHERE #TemplateCounterparty ("Motpart")"

När du anropar en mall för åtkomstbegränsning måste parametrar skickas till den endast som en sträng, det vill säga inom citattecken.

Huvudtabell - Nomenklatur

Malltexten är:

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

Malltexten innehåller en del av texten på språket för dataåtkomstbegränsning och kan innehålla parametrar som är markerade med "#"-symbolen.

Symbolen "#" kan följas av:

• Ett av nyckelorden:
  • En parameter följt av parameterns nummer i mallen inom parentes;
  • CurrentTable – indikerar infogning i texten av det fullständiga namnet på tabellen för vilken begränsningen byggs;
  • CurrentTableName– betecknar infogning i texten av det fullständiga namnet på tabellen (som ett strängvärde, inom citattecken) som instruktionen tillämpas på, i den aktuella versionen av det inbyggda språket;
  • NameCurrentAccessRight– innehåller namnet på den rättighet för vilken den aktuella begränsningen exekveras: LÄS, LÄGG TILL, INFOGA, ÄNDRA, UPPDATERA, DELETE;
• mallparameternamn – betyder infogning av motsvarande mallparameterbegränsning i texten;
• symbolen "#" – indikerar infogningen av ett tecken "#" i texten.

Ett åtkomstbegränsningsuttryck kan innehålla:

• Åtkomstbegränsningsmall, som anges i formatet #Mallnamn("Mallparametervärde 1", "Mallparametervärde 2",...). Varje mallparameter omges av dubbla citattecken. Om du behöver ange ett dubbelcitattecken i parametertexten måste du använda två dubbla citattecken.
• Funktion StrContains(WhereWeLook, WhatWeLook). Funktionen är utformad för att söka efter en förekomst av WhatWeLook-strängen i WhereWeLook-strängen. Returnerar True om förekomsten hittas och False annars.
• Operatorn + är för strängsammansättning.

För att göra det enklare att redigera malltexten klickar du på knappen Ställ in malltext på fliken Begränsningsmallar i rollformuläret. I dialogrutan som öppnas anger du malltexten och klickar på OK.

De kan inte installeras med SetParameter() eller något liknande.

Parametrarna i det här fallet är:

• Sessionsalternativ
• Funktionella alternativ

Läsning av sessionsparametrar i en åtkomstbegränsningsbegäran sker i privilegierat läge, det vill säga utan att kontrollera rättigheterna att arbeta med dem.

Övning 4. Tillgång till "dina" motparter

Det är nödvändigt att konfigurera begränsning av den nuvarande användarens åtkomst till "deras" motparter.

Det finns en katalog "Användare", en katalog "Motparter", dokument med uppgifterna "Motpart".

Den aktuella användaren bör endast se data för de motparter för vilka en anslutning har upprättats med honom.

Kommunikationen måste också konfigureras.

Möjliga alternativ:

Upprätta förbindelser mellan användare och motpart

• Detaljer i motpartskatalogen
• Register över information

Möjliga lösningar på problemet:

• Att lagra en användare i en konstant är ett dåligt alternativ, konstanten är tillgänglig för alla användare.
• Att lagra en fast uppsättning av den nuvarande användarens motparter i sessionsparametrarna är inte särskilt bra ett bra alternativ, det kan finnas många motparter
• Att lagra i sessionsparametrarna för den aktuella användaren och sedan begära en lista över "hans" motparter är ett acceptabelt alternativ.
• Andra alternativ.

Lösning.

Låt oss skapa en ny sessionsparameter "CurrentUser" och fylla i den i sessionsmodulen.

Låt oss skapa ett register med information "Compliance of managers and contractors"

Låt oss skapa en ny roll och i den en ny åtkomstbegränsning för dokumentet "Faktura".

I texten för begäran kommer vi att koppla huvudtabellen till informationsregistret för Konto = Konto och Manager = &Aktuellanvändare. Anslutningstyp Intern.

Om möjligt är det bättre att undvika kapslade frågor i åtkomstbegränsningstexter, eftersom det kommer att exekveras varje gång data läses från detta objekt från databasen.

Kontroll – restriktionerna fungerar

*Funktion: Om du ändrar listan över användarmotparter i registret kommer åtkomstbegränsningar att träda i kraft omedelbart utan att starta om användarsessionen.

Praxis 5. Datum för förbud mot ändringar.

Det är nödvändigt att införa en begränsning för redigering av data före det fastställda datumet för att förbjuda ändringar.
Du måste begränsa det för användare.

Låt oss skapa ett informationsregister "Datum för förbud mot ändringar" med dimensionen Användare, resurs Datum för förbud.

Låt oss bygga logiken i lösningen så här:

• om en användare inte anges gäller förbudet alla användare
• om det finns en begränsning för alla användare och en begränsning för en specifik användare, så gäller begränsningen för en specifik användare, och för andra enligt den allmänna principen.

Uppenbarligen kan en sådan begränsning konfigureras för databasobjekt som har någon position på tidsaxeln. Det kan vara

• Dokumentation
• Periodiska informationsregister

Låt oss skapa en ny roll "Begränsningar efter datum för förbud mot ändringar".

I det, för dokumentet "Faktura" för rätt "ändring" kommer vi att lägga till en ny åtkomstbegränsning.

Vi anger inställningen för alla fält.

Texten till begränsningen är:

ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice

Ändra förbudsdatum Förbudsdatum AS Förbudsdatum
FRÅN

INNER JOIN (VÄLJ
MAX(Ändra förbjudna datum.Användare) SOM användare
FRÅN
Register över information Datum för förbud mot ändringar AS Datum för förbud mot ändringar
VAR
(Ändra förbjudna datum.Användare = &Aktuellanvändare
ELLER Datum förbjudna ändringar.Användare = VÄRDE(Directory.users.EmptyLink))) AS VZ_User
BY Datum för förbud mot ändringar.User = VZ_User.User) AS NestedQuery
Programvarukvitto Faktura.Datum > Kapslad fråga.förbudsdatum

Låt oss kolla - begränsningen fungerar.

Använda preprocessor-instruktioner

#Om villkor1 #Då

Begär fragment 1

#ElseIf Condition2 #Då

Begär fragment 2

#Annat

Begär fragment 3

#EndIf

Under förhållanden kan du använda logiska operationer (och, eller, inte, etc.) och tillgång till sessionsparametrar.

Detta tillvägagångssätt i samband med att konstruera åtkomstbegränsningar är bekvämt eftersom, beroende på villkoren, en kortare text för begäran kommer att sammanställas. En enklare fråga belastar systemet mindre.

Nackdelen är att frågekonstruktorn inte fungerar med sådan text.

* Egendom:

I motsats till instruktionerna till förbehandlaren av det inbyggda språket i åtkomstbegränsningstexterna, innan operatören Då måste du sätta en hash - #Då

Övning 6. Byt "Använd RLS"

Låt oss komplettera vårt system med restriktioner med en switch som slår på/stänger av användningen av restriktioner på rekordnivå.

För att göra detta kommer vi att lägga till en konstant och en sessionsparameter med namnet "UseRLS".

Låt oss skriva i sessionsmodulen för att ställa in värdet på sessionsparametern från värdet på konstanten.

Låt oss lägga till följande kod i alla texter om åtkomstbegränsning:

"#If &UseRLS #Då….. #EndIf"

Vi kollar – allt fungerar.

Men nu efter att ha slagit på "använd radar"-flaggan kommer ändringarna inte att träda i kraft omedelbart. Varför?

Eftersom sessionsparametern ställs in när sessionen startas.

Det är möjligt att ställa in värdet på sessionsparametern som ska återställas när ett nytt konstant värde skrivs, men detta kommer bara att fungera för den aktuella användarsessionen. Andra användare bör uppmanas att starta om systemet.

Slutet på första delen.