Velg syntaks 1s. Mer komplekse resultater av den betingede uttalelsen

Til tross for alle manglene, er tekstfeltsøk fortsatt en av de mest populære. Vi kan finne strengdatatyper overalt - navn, kontonummer, adresser, samt annen informasjon kan lagres i dette formatet. I spørsmål i det innebygde 1C-språket, for enkelhets skyld for utviklere, brukes en spesiell operatør "LIKE". Dette er en av de mest brukte kommandoene, så uten en grundig kjennskap til dens syntaks og muligheter, vil det være vanskelig for en programmerer å jobbe.

Bruker LIKE-operatoren

Før du bruker noen operatør i praksis, må du tydelig forstå formålet, bruksstedene og syntaksen. Hensikten med å bruke "LIKE" i en 1C-forespørsel er å sjekke om tilstanden er oppfylt som en mal. Returverdien er en boolsk type - sann eller usann, som indikerer om gitt tilstand. LIKE-operatoren kan brukes flere steder i en spørring:

I vilkårsblokken, utpekt med nøkkelordet "HVOR";
I utformingen av Choice When Then Otherwise End;
Direkte i utvalgsfeltene, som et resultat av feltsammenlikning.

Verifikasjonssyntaksen er alltid den samme og består av 3 lenker. Venstre tekstverdi, som kontrolleres, deretter "LIKE"-operatøren selv, og til høyre er malen som sjekken utføres med. For raskt og enkelt å lage maler, er det spesielle symboler som gjør utviklingen enklere:

"%" er en sekvens av alle tegn med vilkårlig lengde. Brukes til å søke individuelle ord eller tall på en linje;
"_" – et enkelt tegn. Beregnet på å indikere tilstedeværelsen av et enkelt tegn;
"[...]" er en sekvens av tegn som skal sammenlignes med et tegn i en streng. Ved hjelp av et slikt mønster kontrolleres en overensstemmelse med noen av tegnene oppført i parentes. Du kan også angi en rekke tall eller bokstaver ([a-g], );
"[^...]" er det motsatte mønsteret til det forrige. Forskjellen mellom tegnet som er spesifisert i linjen og de som er oppført i parentes er merket av.

For bedre å forstå og forstå prinsippene for å lage riktige maler, la oss se på noen eksempler som ofte oppstår i utvikleres liv. Den første er når vi trenger å velge fra nomenklaturkatalogen alle elementer i navnene som ordet "CUTTER" vises på. I dette tilfellet må vi bruke LIKE i spørringsbetingelsene:

SELECT Nomenclature.Name AS Name FROM Directory.Nomenclature AS Nomenclature WHERE Nomenclature.Name SAMMENLIGNENDE med "% CUTTER%"

Hvis vi fjerner begge "%"-symbolene, vil spørringen vise et produkt hvis navn samsvarer fullstendig med det som er spesifisert i anførselstegn. Hvis vi lar malen "CUTTER%" eller "% CUTTER", vil resultatet være en liste over elementer som slutter eller begynner med en gitt kombinasjon av tegn.

La oss se på et problem som kan forvirre nybegynnere programmerere som ikke kan søkesyntaks. La oss si at du må finne alle elementer som har "%"-symbolet i navnene deres. Spesielt for tilfeller der du trenger å søke etter reserverte tegn, er det en "spesialtegn"-operator. #,\,/,~ og andre tegn kan brukes som spesialtegn, hvoretter eventuelle reserverte tegn ganske enkelt vil betegne et tegn.

SELECT Nomenclature.Name AS Name FROM Directory.Nomenclature AS Nomenclature WHERE Nomenclature.Name LIGNENDE "%#%" SPESIELL KARAKTER "#"

Hvis du trenger å bruke en parameter i søket, brukes variabelen i søket med parameteren SIMILAR ved å bruke addisjon. Husk at parameteren må være en strengtype, ellers må du konvertere den til en streng i forespørselen. Dette er nok kompleks operasjon og det er bedre å utelukke det på forhånd.

VELG Nomenclature.Name AS Name FROM Directory.Nomenclature AS Nomenclature WHERE Nomenclature.Name LIGNENDE "%" + &name + "%"

LIGNENDE-funksjonen gjelder i alle versjoner av plattformen, fra 8, og på grunn av dens anvendelighet vil ikke 1C-utviklere ønske å endre den. Tekstsøk avhenger selvfølgelig alltid av nøyaktigheten til navnet som er skrevet inn, men det er fortsatt en av de vanligste. I denne forbindelse må profesjonelle 1C-utviklere studere bruken av SIMILAR med alle dens nyanser.

Jeg bestemte meg for å gi mitt bidrag og beskrive de funksjonene ved språket som ikke ble diskutert i artiklene ovenfor. Artikkelen er rettet mot nybegynnere.

1. "IZ" design.

For å hente data fra databasen er det slett ikke nødvendig å bruke "FROM"-konstruksjonen.
Eksempel: Vi må velge all informasjon om banker fra bankkatalogen.
Be om:

SELECT Directory.Banks.*

Velger alle felt fra bankkatalogen. Og ligner på forespørselen:

VELG Banker.* FRA Directory.Banks AS Banker

2. Bestilling av data etter referansefelt

Når vi trenger å organisere spørringsdata etter primitive typer: "String", "Number", "Date", etc., så løses alt ved å bruke "ORDER BY"-konstruksjonen hvis du trenger å bestille dataene etter et referansefelt? Referansefeltet er en lenke, unik identifikator, dvs. Grovt sett kan et vilkårlig sett med tegn og vanlig rekkefølge gi et resultat som ikke er helt forventet. For å bestille referansefelt brukes konstruksjonen "AUTO BESTILLING". For å gjøre dette må du først bestille dataene direkte etter referansetypen ved å bruke "ORDER BY"-konstruksjonen, og deretter "AUTO ORDER"-konstruksjonen.

I dette tilfellet, for dokumenter, vil bestillingen skje i rekkefølgen "Dato->Nummer", for oppslagsverk i "Hovedvisning". Hvis bestillingen ikke skjer etter referansefelt, anbefales det ikke å bruke konstruksjonen "AUTO BESTILLING".

I noen tilfeller kan "AUTO BESTILLING"-konstruksjonen bremse utvelgelsesprosessen. På lignende måte kan du skrive om uten automatisk bestilling av dokumenter:

3.Få en tekstrepresentasjon av en referansetype. "PRESENTASJON" design.

Når du trenger å vise et felt av en referansetype, for eksempel "Bank"-feltet, som er en lenke til et element i "Banks"-katalogen, må du forstå at når dette feltet vises, vil en underspørring til "Banker"-katalogen vil automatisk bli utført for å få en visning av katalogen. Dette vil redusere datautgangen. For å unngå dette, må du bruke "PREPRESENTASJON"-konstruksjonen i forespørselen for umiddelbart å få en representasjon av objektet og deretter vise det for visning.

I datasammensetningssystemet brukes denne mekanismen som standard, men når du lager oppsett i celler, bør du spesifisere representasjonen av referansefeltet, og for eksempel plassere selve lenken i transkripsjonen.

4. Betingelse for prøvetaking av data etter mal.

For eksempel må du få Mobil ansatte av typen (8 -123- 456-78-912). For å gjøre dette må du angi følgende betingelse i forespørselen:

VELG Employee.Name, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

Tegnet "_" er et tjenestetegn og erstatter et hvilket som helst tegn.

5. Samtidig bruk av totaler og grupperinger.

Totaler brukes ofte sammen med grupperinger, i dette tilfellet kan det hende at aggregerte funksjoner ikke er spesifisert i totalene.

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, SUM(Provision of Services.Amount of Document) AS Sum of Document FROM Document.Provision of Services AS Provision of Services GROUP BY Provision of Services.Organisation, Provision of Services.Nomenklatur RESULTATER AV GENERELT, Organisasjon, nomenklatura

I dette tilfellet vil spørringen returnere nesten det samme som følgende spørring:

SELECT Provision of Services.Organization AS Organisation, Provision of Services.Nomenclature AS Nomenclature, Provision of Services.Amount of Document AS Amount of Document FROM Document.Provision of Services AS Provision of Services RESULTATE AMOUNT (Amount of Document) BY GENERAL, Organisation, Nomenklatur

Bare den første spørringen vil skjule poster med samme nomenklatur.

6. Frareferansefelt.

Å referere til felt gjennom en prikk kallesen. For eksempel Betaling.Organisasjon.Administrativ enhet. I dette tilfellet, i referansefeltet "Organisasjon" i "Betaling"-dokumentet, refererer det til en annen tabell "Organisasjoner", der verdien av attributtet "Administrativ enhet" vil bli oppnådd. Det er viktig å forstå at når du får tilgang til felt gjennom en prikk, oppretter plattformen implisitt en underspørring og kobler sammen disse tabellene.

Be om:

Kan representeres som:

VELG Payment.Link, Payment.Organization, Payment.Organization, Organisations. AdministrativeUnit FROM Document.Payment AS Payment VENSTRE JOIN Directory.Organizations AS Organisasjoner Programvare Payment.Organization = Organisasjoner.Link

Når du refererer til referansefelt av en sammensatt type, forsøker rammeverket å lage implisitte sammenføyninger til alle tabeller som er en del av feltets type. I dette tilfellet vil ikke spørringen være optimal Hvis det er klart kjent hvilken type felt det er, er det nødvendig å begrense slike felt etter type med en konstruksjon UTTRYKKE().

For eksempel er det et akkumuleringsregister "Ufordelte betalinger", der flere dokumenter kan fungere som registrar. I dette tilfellet er det feil å innhente verdiene til registrardetaljene på denne måten:

VELG UnallocatedPayments.Registrar.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

type bør begrenses sammensatt felt registrar:

VELG EXPRESS(UnallocatedPayments.Register AS Document.Payment).Dato, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

7. Konstruksjon "HVOR"

Med en venstresammenføyning av to tabeller, når du pålegger en "WHERE"-betingelse på den høyre tabellen, vil vi få et resultat som ligner resultatet med en indre sammenføyning av tabeller.

Eksempel. Det er nødvendig å velge alle klienter fra klientkatalogen og for de klienter som har et betalingsdokument med verdien av attributtet "Organisasjon" = &Organisasjon, vis dokumentet "Betaling", for de som ikke har det, ikke vis det.

Resultatet av spørringen vil returnere poster bare for de klientene som hadde betaling etter organisasjon i parameteren, og vil filtrere ut andre klienter. Derfor må du først motta alle betalinger for "slik og slik" organisasjon i en midlertidig tabell, og deretter koble den til "Kunder"-katalogen ved å bruke en venstre sammenføyning.

VELG Payment.Link AS Payment, Payment.Shareholder AS Client PLASS toPayments FROM Document.Payment AS Payment WHERE Payment.Branch = &Branch; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AS Betaling FRA Directory .Clients AS Klienter VENSTRE FORBINDELSE topayments SOM topayments SOFTWARE Clients.Link = topayments.Client

Du kan komme deg rundt denne tilstanden på en annen måte. Det er nødvendig å pålegge en "WHERE"-betingelse direkte på forholdet mellom de to tabellene. Eksempel:

VELG Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers VENSTRE CONNECTION Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet") GRUPPE ETTER Clients.Link, Payment. Link

8. Blir med nestede og virtuelle tabeller

Nestede søk ofte nødvendig for å hente data basert på en eller annen tilstand. Hvis du deretter bruker dem sammen med andre tabeller, kan dette redusere utførelsen av spørringen kritisk.

For eksempel må vi få saldobeløpet per gjeldende dato for noen klienter.

SELECT UnallocatedPaymentsBalances.Customer, UnallocatedPaymentsBalances.AmountBalance FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQuery LEFT JOIN RegisterAccumulations.UnallocatedPayments.UnallocatedPayments lokalisertPaymentsBalances. Kunde

Når du utfører en slik spørring, kan DBMS-optimalisatoren gjøre feil når du velger en plan, noe som vil føre til suboptimal utførelse av spørringen. Når du kobler sammen to tabeller, velger DBMS-optimalisatoren en tabellsammenføyningsalgoritme basert på antall poster i begge tabellene. Hvis det er en nestet spørring, er det ekstremt vanskelig å bestemme antall poster som den nestede spørringen vil returnere. Derfor bør du alltid bruke midlertidige tabeller i stedet for nestede spørringer. Så la oss omskrive forespørselen.

SELECT Clients.Link AS Link PLASS tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Clients) ; ////////////////////////////////////////////// //////////////////////////////////// VELG tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT JOIN RegisterAccuulations.UnallocatedPayments.Balances (, Client) IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

I dette tilfellet vil optimizeren kunne bestemme hvor mange poster den midlertidige tabellen tClients bruker og vil kunne velge den optimale algoritmen for å slå sammen tabeller.

Virtuelle bord , lar deg få nesten ferdige data for de fleste brukte oppgaver (Slice of the First, Slice of the Last, Remains, Turnovers, Remains og Turnovers) Nøkkelordet her er virtuelt. Disse tabellene er ikke fysiske, men kompileres av systemet på farten, dvs. Ved mottak av data fra virtuelle tabeller samler systemet inn data fra de endelige registertabellene, komponerer, grupperer og sender det ut til brukeren.

De. Når du kobler til en virtuell tabell, opprettes en tilkobling til en underspørring. I dette tilfellet kan DBMS-optimalisatoren også velge en ikke-optimal tilkoblingsplan. Hvis spørringen ikke genereres raskt nok og spørringen bruker sammenføyninger i virtuelle tabeller, anbefales det å flytte tilgangen til de virtuelle tabellene til en midlertidig tabell, og deretter lage en sammenføyning mellom to midlertidige tabeller. La oss omskrive den forrige forespørselen.

VELG Clients.Link AS Link PLASSER tClients FROM Directory.Clients AS Clients INDEKS BY Link HVOR
Clients.Link B (&Clients) ; ////////////////////////////////////////////// ///////////////////////////// SELECT ULLOCATEDPAYMENTS.AmountBalance, UnfordoatedPayments.Client as Client Place Balances from RegisterAccumulations.unallocatedPayments.Balances (, klient B ( SELECT tClients Link FROM tClients)) AS UnallocatedPaymentsBalances; ////////////////////////////////////////////// ///////////////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS AmountRemaining FROM tClients AS tClients LEFT JOIN toRemaining AS Remainder PO tClients.Link = tRemainings.Client

9.Sjekker resultatet av forespørselen.

Resultatet av spørringen kan være tomt for å se etter tomme verdier, bruk følgende konstruksjon:

ResRequest = Request.Execute(); Hvis resQuery.Empty() Returner deretter; slutt om;

Metode Tømme() bør brukes før metoder Velge() eller Lesse(), siden det tar tid å hente samlingen.

Det er ikke en åpenbaring for noen at det er ekstremt uønsket å bruke spørringer i en loop. Dette kan kritisk påvirke driftstiden til en bestemt funksjon. Det er svært ønskelig å motta alle dataene i forespørselen og deretter behandle dataene i en loop. Men noen ganger er det tilfeller der det blir umulig å flytte forespørselen utenfor loopen. I dette tilfellet, for optimalisering, kan du flytte opprettelsen av spørringen utenfor loopen, og i loopen erstatte de nødvendige parameterne og utføre spørringen.

QueryResult = Query.Execute().Select(); EndCycle;

Dette vil spare systemet fra syntakskontroll av forespørselen i en løkke.

11. Konstruksjon "HAVING".

VELG Betaling.Kunde, BELØP(Betaling.Beløp) SOM Beløp FRA Dokument.Betaling SOM Betaling HVOR MÅNED(Betalingsdato) = 9 GRUPPER ETTER Betaling.Kunde HAR BELØP(Betal.Beløp) > 13000

I konstruktøren, for å gjøre dette, går du bare til fanen "Betingelser", legg til en ny tilstand og merker av for "Egendefinert". Så er det bare å skrive Beløp (Betaling.Beløp) > 13000

12. NULL-verdi

Jeg vil ikke her beskrive prinsippene for treverdi-logikk i databasen, det er mange artikler om dette emnet. Bare kort om hvordan NULL kan påvirke resultatet av spørringen. Verdien NULL er egentlig ikke en verdi, og det faktum at verdien er udefinert er ukjent. Derfor returnerer enhver operasjon med NULL NULL, enten det er addisjon, subtraksjon, divisjon eller sammenligning. En NULL-verdi kan ikke sammenlignes med en NULL-verdi fordi vi ikke vet hva vi skal sammenligne. De. begge disse sammenligningene er: NULL = NULL, NULL<>NULL er ikke sant eller usant, det er ukjent.

La oss se på et eksempel.

For de kundene som ikke har betalinger, må vi vise "Sign"-feltet med verdien "Ingen betalinger". Dessuten vet vi med sikkerhet at vi har slike kunder. Og for å gjenspeile essensen av det jeg skrev ovenfor, la oss gjøre det på denne måten.

VELG "Ingen betalinger" AS Attributt, NULL AS Document PLACE topbetalinger; ////////////////////////////////////////////// //////////////////////////// select clients.link as client, betaling.link hvordan betaling setter tclientpayment fra katalog.clients som klienter forlot tilkoblingsdokumentet. Payment AS Payment Software Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// //////////////////////////// select tclientpayment.client from tclientpayment as tclientpayment internt join tpayment as ttopay by tclientpayment.payment = tpayment

Vær oppmerksom på den andre midlertidige tabellen tClientPayment. Med venstre join velger jeg alle klienter og alle betalinger for disse klientene. For de kundene som ikke har betalinger, vil "Betaling"-feltet være NULL. Etter logikken, i den første midlertidige tabellen "tPayments" utpekte jeg 2 felt, ett av dem NULL, den andre linjen "Har ikke betalinger". I det tredje bordet blir jeg med indre sammenføyning tabellene "tClientPayment" og "tPayment" for feltene "Payment" og "Document". Vi vet at i den første tabellen er «Dokument»-feltet NULL, og i den andre tabellen er de som ikke har betalinger i «Betaling»-feltet også NULL. Hva vil en slik forbindelse returnere til oss? Men det vil ikke returnere noe. Fordi sammenligningen NULL = NULL ikke evalueres til True.

For at forespørselen skal returnere det forventede resultatet, la oss skrive det om:

VELG "Ingen betalinger" AS Attribut, VALUE(Document.Payment.EmptyLink) AS Document PLACE toPayments; ////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink )) HVORDAN Betaling PUT tClientPayment FROM Directory.Clients AS Clients LEFT CONNECTION Document.Payment AS Payment BY Clients.Link = Payment.Shareholder; ////////////////////////////////////////////// //////////////////////////// select tclientpayment.client from tclientpayment as tclientpayment internt join tpayment as ttopay by tclientpayment.payment = tpayment

Nå, i den andre midlertidige tabellen, har vi indikert at hvis "Betaling"-feltet er NULL, så er dette feltet en tom lenke til betalingsdokumentet. I den første tabellen erstattet vi også NULL med en tom referanse. Nå involverer tilkoblingen ikke-NULL-felt og forespørselen vil returnere det forventede resultatet.

Alle forespørsler i artikkelen gjenspeiler situasjonene jeg ønsker å vurdere og ingenting mer. OM De er kanskje ikke vrangforestillinger eller suboptimale, det viktigste er at de gjenspeiler essensen av eksemplet.

13. Et udokumentert trekk ved "CHOICE WHEN...THEN...END"-designet.

I tilfelle det er nødvendig å beskrive "Betingelser"-konstruksjonen i forespørselen, bruker vi standardsyntaksen:

VELG UTVALG NÅR Users.Name = "Vasya Pupkin" SÅ "Vår favorittansatt" ELSE "Vi vet ikke dette" END AS Field1 FROM Directory.Users AS Users

Men hva om vi for eksempel trenger å få månedens navn i en forespørsel? Å skrive en stor konstruksjon i en forespørsel er stygg og tidkrevende, så denne formen for skriving ovenfor kan hjelpe oss:

SELECT MONTH(US_CalculationConsumption_TurnoverSchedule.CalculationPeriod) NÅR 1 SÅ "Januar" NÅR 2 SÅ "FEBRUAR" NÅR 3. SÅ "MARS" NÅR 4. SÅ "April" NÅR 5. SÅ "6. MAI" NÅR JUNI "NÅR JUNI" 8. SÅ "August" NÅR 9. SÅ "September" NÅR 10. SÅ "Oktober" NÅR 11. SÅ

Nå ser designet mindre tungvint ut og er lett å forstå.

14. Batch-utførelse av spørringer.

For ikke å multiplisere forespørsler kan du lage én stor forespørsel, dele den opp i pakker og jobbe med den.
For eksempel må jeg hente følgende felt fra "Brukere"-katalogen: "Fødselsdato" og de tilgjengelige rollene for hver bruker. last opp dette til ulike tabelldeler på skjemaet. Selvfølgelig kan du gjøre dette i én forespørsel, så må du iterere gjennom postene eller skjule dem, eller du kan gjøre dette:

SELECT Users.Link AS Fullt navn, Users.Fødselsdato, Users.Role PUT vtUsers FROM Directory.Users AS Users; ////////////////////////////////////////////// ////////////////////////// SELECT tueUsers.Full navn, tueUsers.Fødselsdato FROM tueUsers AS tueUsers GROUP BY tueUsers.fullt navn, tueUsers . Fødselsdato; ////////////////////////////////////////////// //////////////////////////// select wusers.full name, wusers.role from wusers as wusers group by wusers.full name, wusers av fødsel

tPackage = Request.ExecutePackage();

TP_BirthDate = tPackage.Upload();
TP_Roles = tPackage.Unload();

Som vi kan se, kan spørringen utføres i en batch og resultatet kan behandles som en matrise. I noen tilfeller er det veldig praktisk.

15. Betingelser i en batchforespørsel

For eksempel har vi en batchforespørsel, hvor vi først får feltene: «Navn, Fødselsdato, Kode» fra «Brukere»-katalogen og ønsker å hente poster med betingelser for disse feltene fra «Individualer»-katalogen.

SELECT Users.Individual.Name AS Name, Users.Individual.Date of Birth AS Fødselsdato, Users.Individual.Code AS Kode PLASS vtUsers FRA Directory.Users AS Users; ////////////////////////////////////////////// /////////////////////////// r r

Du kan stille vilkår som dette:

WHERE Individuals.Code IN (SELECT tueUsers.Code FROM tueUsers) OG Individuals.Name IN (SELECT tueUsers.Code FROM tueUsers) OG Individuals.BirthDate IN (SELECT tueUsers.DateBirth FROM tueUsers)

Og du kan gjøre det slik:

HVOR (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers.Date of Birth FROM tueUsers)

Dessuten er det nødvendig å opprettholde orden.

16. Ringe spørringsbyggeren for "tilstand" i en batchforespørsel

Når det er nødvendig å pålegge en betingelse, som i eksemplet ovenfor, kan du glemme hvordan dette eller det feltet kalles i den virtuelle tabellen.
For eksempel må du pålegge en betingelse i "Fødselsdato"-feltet, og i den virtuelle tabellen kalles dette feltet "Debitors fødselsdato", og hvis du glemmer navnet, må du avslutte redigering av betingelsen uten lagre og se på navnet på feltet. For å unngå dette kan du bruke følgende teknikk.

Det er nødvendig å sette parenteser etter konstruksjon "B" og la et tomt mellomrom (mellomrom) mellom parentesene, velg denne plassen og kall opp spørringskonstruktøren. Designeren vil ha tilgang til alle tabellene i batch-spørringen. Teknikken fungerer både på virtuelle registertabeller og på fanen "Betingelser". I sistnevnte tilfelle må du merke av i boksen "P (vilkårlig tilstand)" og gå inn i redigeringsmodusen "F4".

Forespørslene ble ofte gjort på flukt, og de tjener ganske enkelt til å illustrere "teknikkene" som jeg vurderte.

Jeg ønsket å se på bruken av indekser i spørringer, men dette er et veldig bredt tema. Jeg legger det inn i en egen artikkel, eller legger det til her senere.

oppd1. Poeng 11,12
oppd2. Poeng 13,14,15,16

Brukte bøker:
Spørrespråk "1C:Enterprise 8" - E.Yu. Khrustaleva
Faglig utvikling i 1C:Enterprise 8-systemet."

NULL er ikke noe mer enn fravær av en verdi. Mange forveksler det med verdien "0" av typenummer, en tom referanse til et objekt eller en tom streng. På grunn av denne misforståelsen oppstår det mange feil.

NULL-verdien vises hvis forespørselen refererer til et ikke-eksisterende felt, egenskap eller ødelagt kobling.

Basert på SQL, som ikke tillater normal likhetstesting for NULL. Nedenfor er to måter å sjekke for NULL i 1C 8.3.

1C 8.3 spørringsspråkfunksjonen ISNULL() har to inngangsparametere:

uttrykk som skal testes;
erstatningsuttrykk.

Hvis verdien som testes er NULL, vil denne funksjonen returnere verdien til erstatningsuttrykket. Hvis verdien er en annen enn NULL, vil uttrykket som testes bli returnert.

Nedenfor er et eksempel. Den velger alle vareelementer i den tabellformede delen av produktet fra dokumentet "Mottak av varer og tjenester". Ved å bruke venstre sammenføyning tildeles hver vare siste pris fra informasjonsregisteret "Varepriser".

I dette tilfellet kan det oppstå en situasjon at det for en posisjon rett og slett ikke er en pris i registeret. I dette tilfellet vil ISNULL-funksjonen returnere oss den vanlige null. Hvis du ikke bruker det, vil vi motta en feilmelding når du prøver å utføre aritmetiske operasjoner på "Pris"-feltet med en NULL-verdi.

VELGE

ISNULL(Priser.Pris, 0) AS CurrentPrice
FRA

HVOR

DET ER NULL i SELECT-setningen

Ekvivalenten til ISNULL() er ISNULL, som brukes i SELECT-setningen og sjekker om verdien er NULL. "IS" i dette tilfellet antyder likhet, og spørringen i det forrige eksemplet vil se slik ut:

VELGE
Products.Nomenclature AS Produkt,
VALG
NÅR Prisene ER NULL
SÅ 0
ELLERS Priser.Pris
SLUTT SOM Gjeldende Pris
FRA
Dokumentmottak av varer og tjenester AS
VENSTRE FORBINDELSE RegisterInformation.PricesNomenclature.SliceLast AS Priser
Programvareprodukter.Nomenklatur = Priser.Nomenklatur
HVOR
Products.Link = &LinkToDocument

Forskjeller mellom funksjonen ISNULL() og IS NULL

Som du kan se fra de foregående eksemplene, returnerer forespørselen i begge tilfeller de samme dataene. ISNULL()-funksjonen er en kortversjon av SELECTION WHEN... IS NULL...END, men den er fortsatt å foretrekke av følgende grunner:

ISNULL()-funksjonen optimaliserer spørringen. Den leses én gang, så når du sjekker et komplekst uttrykk, vil forespørselen behandles raskere.
ISNULL()-funksjonen forkorter konstruksjonen, noe som gjør spørringen mer lesbar.
Når du kjører ISNULL()-funksjonen, reduseres erstatningsuttrykket til typen uttrykk som testes for strengtyper (strenglengde) og numeriske typer (bitdybde).

I denne artikkelen ønsker vi å diskutere alt med deg 1C spørrespråkfunksjoner, og spørrespråkkonstruksjoner. Hva er forskjellen mellom funksjon og design? Funksjonen kalles med parenteser og mulige parametere i dem, og konstruksjonen skrives uten parentes. Utvilsomt alle strukturer og funksjoner i 1C spørrespråk gjøre datainnsamlingsprosessen fleksibel og multifunksjonell. Disse funksjonene og konstruksjonene gjelder for forespørselsfelt, og noen gjelder også for betingelser.

1C Språkfunksjoner

Fordi en klar beskrivelse 1C spørrespråkfunksjoner er mye mindre vanlig enn beskrivelser av strukturer, bestemte vi oss for å begynne å se på funksjoner. La oss nå se på hver enkelt separat, og beskrive dens formål, syntaks og eksempel på bruk, så:

1. Funksjon DATO TID - denne funksjonen oppretter et konstant felt av typen "Dato".

Syntaks: DATO TID(<Год>,<Месяц>,<День>,<Час>,<Минута>,<Секунда>)

Eksempel på bruk:

2. DATO DIFFERENCE funksjon- returnerer differansen mellom to datoer i en av dimensjonene (år, måned, dag, time, minutt, sekund). Målingen sendes som en parameter.

Syntaks: DIFERENCEDATE(<Дата1>, <Дата2>, <Тип>)

Eksempel på bruk:

Query.Text = "SELECT | DIFFERENCEDATE(DATETIME(2015, 4, 17), DATETIME(2015, 2, 1), DAY) | AS Number of Days";

3. Funksjon VALUE- setter et konstant felt med en forhåndsdefinert post fra databasen du kan også få en tom lenke av hvilken som helst type.

Syntaks: VALUE(<Имя>)

Eksempel på bruk:

Request.Text = "VELG //forhåndsdefinert element | VALUE(Directory.Currencies.Dollar) AS Dollar, //empty link | VALUE(Document.Receipt of Goods and Services.EmptyLink) AS Receipt, //transfer value | VALUE(Transfer . Legal Individual) AS Individual, //forhåndsdefinert konto VERDI(Kontoplan. Egenregnskap.Material) AS Account_10" ;

4. VELG funksjon- vi har foran oss en analog av IF-konstruksjonen, som brukes i koden, bare denne brukes i 1C-spørringer.

Syntaks: VALG NÅR<Выражение>DERETTER<Выражение>ELLERS<Выражение>SLUTT

Eksempel på bruk:

Request.Text = //hvis beløpet er mer enn 7500, så bør det være en rabatt på 300 rubler, //så hvis betingelsen utløses så funksjonen //returnerer Beløp - 300 //ellers vil forespørselen ganske enkelt returnere Beløp "VELG | VELG | NÅR TCReceipts.Amount > 7500 | THEN TCReceipts.Amount - 300 | ELSE TCReceipts.Amount | END AS AmountWithDiscount | FROM |

5. EXPRESS-funksjon- lar deg uttrykke et konstant felt med en bestemt type.

Syntaks: EXPRESS(Feltnavn AS Typenavn)

Eksempel på bruk:

Et annet alternativ er å bruke EXPRESS-funksjonen i felt blandede typer hvor finnes disse? Det enkleste eksemplet er "Registrar" for ethvert register. Så hvorfor må vi kanskje kvalifisere typen i registraren? La oss vurdere situasjonen når vi velger "Nummer"-feltet fra registraren, fra hvilken tabell vil nummeret bli valgt? Det riktige svaret av alle! Derfor, for at søket vårt skal fungere raskt, bør vi spesifisere en eksplisitt type ved å bruke EXPRESS-funksjonen

Eksempel på bruk:

Query.Text = "SELECT | EXPRESS(Nomenclature.Comment AS Line(300)) AS Comment, | EXPRESS(Nomenclature.Sum AS Number(15,2)) AS Sum |FROM | Directory.Nomenclature AS Nomenclature";

6. ISNULL-funksjon(alternativ stavemåte ISNULL) - hvis feltet er av typen NULL, erstattes det med funksjonens andre parameter.

Syntaks: ISNULL(<Поле>, <ПодставляемоеЗначение>)

Eksempel på bruk:

Vær også oppmerksom på at det er tilrådelig å ALLTID erstatte NULL-typen med en eller annen verdi, fordi sammenligning med typen NULL returnerer alltid FALSE selv om du sammenligner NULL med NULL. Oftest dannes NULL-verdier som et resultat av sammenføyningstabeller (alle typer sammenføyninger unntatt interne).

Query.Text = //Velg hele elementet og dets saldo //hvis det ikke er noen saldo i en vare, vil det være et felt //NULL som vil bli erstattet med verdien 0 "SELECT | No. Link, | ISNULL (ProductsInStockRemains.InStockRemaining, 0) HVORDAN Gjenstående |.Nomenclature AS No. |.

7. REPRESENTASJON funksjon- lar deg få en representasjon av forespørselsfeltet.

Syntaks: OPPTREDEN(<НаименованиеПоля>)

Eksempel på bruk:

Konstruerer i 1C spørrespråk

Vi diskuterte med deg ovenfor 1C spørrespråkfunksjoner, nå er det på tide å vurdere konstruksjoner i 1C-spørringsspråket, de er ikke mindre viktige og nyttige, la oss komme i gang.

1. Bygg LINK- er en logisk operator for å sjekke en referansetype. Oppstår oftest når du sjekker et felt av en kompleks type mot en bestemt type. Syntaks: LINK<Имя таблицы>

Eksempel på bruk:

2. Design MELLOM- denne operatøren sjekker om verdien er innenfor det angitte området.

Syntaks: MELLOM<Выражение>OG<Выражение>

Eksempel på bruk:

3. Konstruksjon B og B HIERARKI- sjekk om verdien er i den overførte listen (matriser, verditabeller osv. kan overføres som en liste). Operatoren IN HIERARKIET lar deg se hierarkiet (et eksempel på bruk av kontoplanen).

Syntaks: I(<СписокЗначений>), I HIERARKIET(<СписокЗначений>)

Eksempel på bruk:

4. Design LIGNENDE- Denne funksjonen lar oss sammenligne en streng med et strengmønster.

Syntaks: SOM "<ТекстШаблона>"

Alternativer for radmønster:

% - en sekvens som inneholder et hvilket som helst antall vilkårlige tegn.

En vilkårlig karakter.

[...] - ethvert enkelt tegn eller sekvens av tegn oppført innenfor hakeparenteser. Oppregningen kan spesifisere områder, for eksempel a-z, som betyr et vilkårlig tegn inkludert i området, inkludert endene av området.

[^...] - ethvert enkelt tegn eller sekvens av tegn oppført innenfor hakeparenteser bortsett fra de som er oppført etter negasjonstegnet.

Eksempel på bruk:

5. Design TILLATT- denne operatøren lar deg velge bare de postene fra databasen som den som ringer har lesetillatelse til. Disse rettighetene er konfigurert på postnivå (RLS).

Syntaks: TILLATT skrives etter søkeord VELGE

Eksempel på bruk:

Request.Text = "VELG TILLATT | Motparter. Link | FRA | Katalog. Motparter AS Motparter";

6. Design DIVERSE- lar deg velge poster der det ikke er noen dupliserte poster.

Syntaks: VARIOUS skrives etter nøkkelordet SELECT

Eksempel på bruk:

Request.Text = //velger poster som leseren har rettigheter til "SELECT VARIOUS | Counterparties.Name |FROM | Directory. Counterparties AS Counterparties" ;

Dessuten kan VARIOUS-konstruksjonen brukes med den TILLATTE operatøren og andre operatører.

Eksempel på bruk:

Request.Text = //velger ulike poster som leseren har rettigheter til "SELECT ALLOWED VARIOUS | Counterparties.Name |FROM | Directory. Counterparties AS Counterparties";

7. Design FØRST- velger antall poster spesifisert i parameteren fra søkeresultatet.

Syntaks: FØRST<число>

Eksempel på bruk:

Request.Text = //velg de første 4 CCD-numrene fra katalogen "SELECT FIRST 4 | CCD Numbers. Link | FROM | Directory. CCD Numbers AS CCD Numbers";

8. Design FOR ENDRING- lar deg låse et bord, fungerer kun i transaksjoner (relevant kun for automatiske låser).

Syntaks: FOR ENDRING<НаименованиеТаблицы>

Eksempel på bruk:

9. Design BESTILL ETTER- organiserer data etter et bestemt felt. Hvis feltet er en lenke, så når du setter flagget AUTO BESTILLING Sortering vil skje etter lenkerpresentasjon hvis flagget er slått av, sorteres koblinger etter ansienniteten til lenkeadressen i minnet.

Syntaks: SORTER ETTER<НаименованиеПоля>AUTO BESTILLING

Eksempel på bruk:

10. Design GROUP BY- brukes til å gruppere søkestrenger etter spesifikke felt. Numeriske felt må brukes med en hvilken som helst aggregert funksjon.

Syntaks: GRUPPE AV<НаименованиеПоля1>, .... , <НаименованиеПоляN>

Eksempel på bruk:

11. Design HAVING- lar deg bruke en aggregert funksjon på en datavalgbetingelse, lik WHERE-konstruksjonen.

Syntaks: HA<агрегатная функция с условием>

Eksempel på bruk:

12. Bygg INDEKS ETTER- brukes til å indeksere søkefeltet. Et søk med indeksering tar lengre tid å fullføre, men gjør søking gjennom indekserte felt raskere. Kan bare brukes i virtuelle tabeller.

Syntaks: INDEKSER ETTER<Поле1, ... , ПолеN>

Eksempel på bruk:

13. Design HVOR- lar deg pålegge en betingelse på alle valgfelt. Resultatet vil kun inkludere poster som tilfredsstiller betingelsen.

Syntaks: HVOR<Условие1 ОператорЛогСоединения УсловиеN>

Eksempel på bruk:

Query.Text = //alle poster med CompensationRemaining er valgt<>0 og //AmountForCalcCompRemaining > 100 "SELECT | CompensationRPORmains.Counterparty, |CompensationRPORmains.Child, | CompensationRPORmains.CompensationRemaining, | CompensationRPORmains.AmountForCalcCompRemains |Place DataTzRPRemains |KompensasjonRPORmaining.CompensationRemaining<>0 | And CompensationRPORmains.AmountForCalcCompRemaining> 100" ;

14. Design RESULTATER... GENERELT- brukes til å beregne totaler. Designet spesifiserer feltene som totaler skal beregnes med, og aggregerte funksjoner brukes på de totale feltene. Ved bruk av totaler for hvert felt etter TOTAL-konstruksjonen, grupperes data. Det er en valgfri GENERELL konstruksjon. Bruken av den gir også ekstra gruppering. Du vil se et eksempel på forespørselsresultatet nedenfor.

Syntaks: RESULTATER<АгрегатнаяФункция1, ... , АгрегатнаяФункцияN>AV<ОБЩИЕ> <Поле1, ... , ПолеN>

Eksempel på bruk:

Figuren skisserer grupperingene som ble dannet under utførelsen av forespørselen, den øverste refererer til GENERELT, og den andre til feltet MotpartsavtaleAvtaletype.

Du kan bruke ulike funksjoner på spørringsfelt. I denne delen vil jeg vurdere de mest brukte (av meg personlig) av dem.

DATO TID- spesifiserer et konstantfelt med datotypen. Syntaks:

DATO TID(<Год>,<Месяц>,<День>,<Час>,<Минута>,<Секунда>)
Request.Text =
"VELGE
| DATOTIME(2013, 1, 1) AS OMG";//1. januar 2013

FORSKJELL DATO- returnerer differansen mellom 2 datoer i den angitte dimensjonen (år, måned, dag, time, minutt, sekund). Syntaks:

DIFERENCEDATE(<Дата1>, <Дата2>, <Тип>)
Request.Text =
"VELGE
| DATODIFFERENCE(DATETIME(2013; 2; 28); DATOTIME(2013; 1; 1); DAY)
| SOM DAGER TIL SLUTTEN AV VINTEREN";

BETYDNING- spesifiserer et konstant felt med en forhåndsdefinert post for en av databasetabellene du kan også sende en tom lenke. Syntaks:

BETYDNING(<Имя>)
Request.Text =
"VELGE
//forhåndsdefinert katalogelement
| VERDI(Katalog.Valuta.Rubler) AS rubel,
//tom lenke til dokumentet
| VERDI(Dokument.Faktura for betaling til kjøper.EmptyLink) AS EmptyInvoice,
//oppregningsverdi
| VALUE(Enumeration.GenderIndividuals.Male) AS Mann,
//forhåndsdefinert konto fra kontoplanen
| VERDI(Kontoplan. Selvbærende. Varer) AS Konto_41";

VALG- en analog av IF-konstruksjonen for 1C spørrespråk. Syntaks:

VALG
NÅR<Выражение>DERETTER<Выражение>
ELLERS<Выражение>
SLUTT
Request.Text =
"VELGE
//hvis prisen er mindre enn 100, vil forespørselen fortsatt returnere 100
//ellers vil forespørselen returnere den virkelige prisen
| VALG
| NÅR Produkter.Pris > 100
| SÅ Produkter.Pris
| ANNET 100
| SLUTT SOM PRIS
|FRA

MELLOM- kontrollerer verdien for inkludering i området. Syntaks:

MELLOM<Выражение>OG<Выражение>
Request.Text =
//få alle produkter i prisklassen fra 100 til 1000
"VELGE
| Produkter.Produkt
|FRA
|HVOR
| Produkter.Pris MELLOM 100 OG 1000";

I Og I HIERARKIET- sjekk tilstedeværelsen av en verdi i den overførte listen. HIERARKI vil også utvide hierarkiske elementer ned og se etter verdi blant de underordnede elementene. Syntaks:

I(<СписокЗначений>), I HIERARKIET(<СписокЗначений>)
Request.Text =
//få alle underkontoene til 41. og 10. konto
"VELGE
| Selvforsørgende.Link AS-konto
|FRA
| Kontoplan Selvforsørgende AS
|HVOR
| Selvforsørgende.Referanse I HIERARKIET (VERDI(Kontooversikt. Selvfinansierende.Vare),
| VERDI(Kontoplan. Kostnadsregnskap. Materialer))";

SOM- lar deg sammenligne en streng med et mønster, brukt når søkestrengen ikke er strengt definert. Bygge malen:

% (prosent): en sekvens som inneholder et hvilket som helst antall vilkårlige tegn
_ (understrek): ett vilkårlig tegn
[...] (ett eller flere tegn i hakeparenteser): ethvert enkelt tegn oppført innenfor hakeparentesene. Opptellingen kan spesifisere områder, for eksempel a-z, som betyr et vilkårlig tegn inkludert i området, inkludert endene av området
[^...] (i hakeparentes et negasjonstegn etterfulgt av ett eller flere tegn): ethvert enkelt tegn annet enn de som er oppført etter negasjonstegnet

Syntaks:

SOM "<ТекстШаблона>"
Request.Text =
//finn alle stolene i nomenklaturkatalogen
"VELGE
| Produkter.Produkt
|FRA
| Directory.Products AS Produkter
|HVOR
| Products.Name LIGNENDE ""tool%""";
//denne forespørselen vil returnere stol, stol, høy stol, kontorstol, etc.,
//men tabellen vil ikke være på denne listen

ISNULL- hvis feltet ikke er definert, defineres det i det angitte uttrykket. Syntaks:

ISNULL(<Выражение>, <Выражение>)
Request.Text =
//Hvis feltet ikke er definert (NULL)? deretter tilordne den en tom lenke
"VELGE
| ISNULL(Products.Link, VALUE(Directory.Products.EmptyLink)) AS Produkt
|FRA
| Directory.Products AS Produkter";

Jeg gjør oppmerksom på at NULL må behandles, fordi dette er en veldig "lunefull" type (i 1C:Enterprise 8-systemet er det definert spesiell type NULL med ett element). Hvis du prøver å sammenligne eller tilordne en verdi av denne typen, vil du definitivt støte på en feil, så ikke glem denne konstruksjonen. Når kan NULL dukke opp:

etter sammenføyning av tabeller, bortsett fra interne (se neste artikkel om sammenføyninger);
etter å ha valgt detaljer definert kun for kataloggrupper og omvendt;
etter å ha valgt dokumentjournalkolonnen, mens gjeldende dokument ikke har detaljer inkludert i denne kolonnen.

Dette er langt fra full liste funksjonene til 1C 8 spørrespråk, hvis du er interessert i noe annet arbeid, skriv i kommentarene.