Prosedyren for å arbeide med det innebygde språkforespørselsobjektet. Hva er formålet med "Language"-konfigurasjonsobjektet?
Utvikling av en applikasjonsløsning i 1C: Enterprise-systemet består av to hovedhandlinger: visuell design av konfigurasjonsobjekter og beskrivelse av den spesifikke oppførselen til systemet ved bruk av det innebygde språket og spørringsspråket.
Det innebygde språket i 1C: Enterprise-systemet har mange likheter med andre programmeringsspråk, men er ikke en direkte analog til noen av dem. Dens viktigste funksjoner:
· myk skriving (typen til en variabel bestemmes av typen verdi den inneholder og kan endres under drift);
· mangel på programvarebeskrivelse av applikasjonstyper (de opprettes når du legger til konfigurasjonsobjekter);
· hendelsesorientert innebygd språk;
· alle operatører har både russisk og engelsk stavemåte, som kan brukes samtidig.
Konfigurasjonsmoduler
Moduler i applikasjonsløsningen er designet for å plassere programteksten på det innebygde språket. Disse modulene er plassert på forskjellige steder i konfigurasjonen og har forskjellige formål. De fleste moduler er "bundet" til bestemte konfigurasjonsobjekter eller til selve applikasjonsløsningen.
Følgende typer programvaremoduler skilles:
· Vanlige moduler. Konfigurasjonen kan ha et vilkårlig antall moduler, inkludert ingen. Vanlige moduler i seg selv kalles ikke opp under konfigurasjonsprosessen. De tjener bare til å inneholde tekstene til prosedyrer og funksjoner som kan kalles fra andre moduler i applikasjonsløsningen. Derfor mangler de en variabel beskrivelsesdel og en hovedprogramdel. At. Vanlige moduler inneholder kun prosedyrer og funksjoner.
· Applikasjonsmodul. Det er alltid en enkelt applikasjonsmodul i konfigurasjonen. Den utføres når systemet starter i 1C: Enterprise-modus og er ment å utarbeide handlinger relatert til sluttbrukerens arbeidsøkt. Hovedhendelsene som kan behandles i en søknadsmodul er start- og slutthendelsene for søknaden. Sekvensen fra samtalen vises i ris. 1. Begivenhet Før du starter systemet Oppstår når systemet starter før hovedvinduet åpnes. Ved å håndtere denne hendelsen har utbygger for eksempel mulighet til å nekte å kjøre dersom noen betingelser ikke er oppfylt. Begivenhet Når du starter systemet oppstår etter å ha åpnet hovedvinduet. I behandleren av dette arrangementet kan du for eksempel vise informasjon om bursdagsfolk osv.
· Ekstern tilkoblingsmodul. Det er alltid en enkelt ekstern tilkoblingsmodul i konfigurasjonen. Den kjøres når applikasjonen åpnes som en COM-server (i ekstern tilkoblingsmodus). I ekstern tilkoblingsmodus er det ikke den fullverdige 1C: Enterprise-applikasjonen som lanseres, men en «lettversjon» der alle funksjoner som på en eller annen måte er relatert til organiseringen av brukergrensesnittet ikke er tilgjengelige.
· Applikasjonsobjektmoduler. Hvert (for eksempel et programvaredokument eller en katalog), hvis data kan endres i 1C: Enterprise-modus, har sin egen modul. I tillegg til beskrivelsen av variabler og hovedprogrammet, kan en objektmodul inneholde en beskrivelse av prosedyrer - hendelsesbehandlere knyttet til et gitt konfigurasjonsobjekt. Det er to hendelser som er reist for alle objekter - Før opptak Og Ved opptak.
· Skjema moduler. Hvert skjema har sin egen modul, som definerer oppførselen til skjemaet og handlingene som utføres fra det, for eksempel å åpne andre skjemaer. Arrangementer heves for alle former Før åpning, under åpning, før stenging Og Ved avslutning.
Kontekst
I 1C: Enterprise-systemet angir kontekst modulens miljø, dvs. variabler, objekter, egenskaper, metoder og hendelser tilgjengelig for den. Vi kan skille mellom følgende typer kontekster, og følgelig regler for synligheten av eksporterte variabler, prosedyrer og funksjoner:
· Global kontekst, tilgjengelig i alle andre sammenhenger, består av følgende deler:
§ egenskaper, metoder og hendelser i den globale konteksten (for eksempel eiendommen Arbeidsdato);
§ systemoppregninger og systemverdisett (f.eks. Returner CodeDialog Og Symboler).
· Felles modulkontekst dannet av den globale konteksten og den lokale konteksten til selve den generelle modulen (dvs. prosedyrene og funksjonene definert i den generelle modulen). I sammenheng med en felles modul er eksporterte prosedyrer og funksjoner til andre vanlige moduler tilgjengelige. Eksporterte variabler, prosedyrer og funksjoner for applikasjonsmodulen er ikke tilgjengelige.
· I sammenheng med en applikasjonsmodul eller ekstern tilkoblingsmodul Eksporterte prosedyrer og funksjoner til vanlige moduler er tilgjengelige.
· I sammenheng med en applikasjonsobjektmodul det er tilgang til detaljene og tabelldelene av objektet, samt dets metoder og hendelser. Eksporterte variabler, prosedyrer og funksjoner for applikasjonsmodulen (ekstern tilkoblingsmodul) og vanlige moduler er tilgjengelig her.
· I sammenheng med en skjemamodul skjemadetaljer er tilgjengelige, samt skjemaegenskaper, metoder og hendelser. Hvis et skjema har et hovedattributt tilordnet, blir egenskapene og metodene til applikasjonsobjektet som brukes som hovedattributt, tilgjengelig i skjemamodulen.
Forholdet mellom kontekster vises skjematisk i ris. 2. På ris. 3 skildrer den mulige interaksjonen mellom journalskjemamodulen og dokumentmodulen.
Prosedyrer og funksjoner
Prosedyrer og funksjoner er programblokker som kan kalles opp ved navn fra et annet sted, for eksempel en annen prosedyre. Funksjoner skiller seg fra prosedyrer bare ved at de har en returverdi. I versjon 8 er rekkefølgen på prosedyrer og funksjoner ikke viktig. Dette betyr at prosedyren kan plasseres under der den kalles.
Prosedyrer og funksjoner kan ha parametere som definerer hvilke handlinger den skal gjøre med hvilke objekter. Parametre for en prosedyre eller funksjon sendes som referanse som standard. Dette betyr at endring av en formell parameter i en prosedyre eller funksjon vil endre den faktiske parameteren på punktet der den kalles. For å garantere at en parameter sendes av verdi, må du sette inn et nøkkelord før parameternavnet Betydning.
Eksempel 1:
Prosedyre Calculate()
Beløp=Pris*Antall;
Slutt på prosedyre
Beregning(); // Ring prosedyren
Eksempel 2:
Perem Glob;
// Beskrivelse av prosedyren
Prosedyreberegning(Par1, Par2, ParZ) Eksport
Glob = Glob + Par1 + Par2 + ParZ;
Slutt på prosedyre
Beregning(5, 6, 7); // Ring prosedyren
Eksempel 3:
Perem Glob;
// Beskrivelse av funksjonen
Funksjonsberegning(Par1, Par2, ParZ) Eksport
Lok = Glob + Par1 + Par2 + ParZ;
Returlås;
EndFunction
Res = Beregn(5, 6, 7); // Funksjonsanrop
Datatyper
Number, String, Date, Boolean, Undefined, Null (for uspesifiserte verdier i databasetabeller)
Type. Verdier av den spesielle typen "Type" er nødvendig for å representere og sammenligne datatyper, for eksempel:
Erklære variabler
Variabler vises i programmet i følgende tilfeller:
· etter at de er deklarert ved hjelp av variabeloperatoren.
Perem<Имя_переменной>[Eksport];
Variabel A, B;
· etter den første plasseringen av variabelnavnet på venstre side av tildelingsoperatøren.
Eksempel:
· når du bestemmer navnene på identifikatorene til redigerte dialogelementer;
· ved innstilling av formelle parametere for prosedyrer.
Cast
Typecasting kan være eksplisitt eller implisitt.
For eksplisitt casting finnes følgende funksjoner: Number, String, Date, Boolean. Implisitt type casting utføres automatisk av systemet ved evaluering av uttrykk.
Eksempel: Verdien til den numeriske variabelen MonthNumber konverteres implisitt til en streng og legges til en annen streng:
A = "Måned" + Månedsnummer;
Kataloger
Arbeid med kataloger utføres ved hjelp av følgende objekter:
· Katalogsjef. Gir tilgang til alle konfigurasjonsreferansebøker. Egenskapene til dette objektet faller sammen med navnene på kataloger og inneholder objekter av typen DirectoryManager.
· DirectoryManager. Gir tilgang til operasjoner på en katalog som et sett med elementer. Ved å bruke metodene til dette objektet kan du søke, få et utvalg, lage nye elementer og få tilgang til katalogskjemaer og oppsett.
· DirectoryLink. Identifiserer utvetydig et element (gruppe) i katalogen og lar deg få tilgang til den i skrivebeskyttet modus. Gjennom egenskapene og metodene til dette objektet kan du lese detaljene til et element (gruppe) og få tilgang til tabelldelene. Verdien av denne typen lagres i attributter som refererer til elementer i denne katalogen, for eksempel i attributtet Ansatt dokument Rekruttering en kobling til et spesifikt katalogelement lagres Ansatte.
· DirectoryObject. Gir skrivbar tilgang til et element. Dette objektet inneholder metoder som påvirker et element i databasen, for eksempel metoder Skrive ned Og Slett.
· Katalogvalg. Gir muligheten til å iterere gjennom katalogelementer. Sampling kan være direkte eller hierarkisk.
· Katalogliste. Et objekt for å administrere listen over elementer i et tabellfelt. Lar deg administrere kolonner, utvalg og sortering i listen.
I 1C:Enterprise-systemet?
1. Konfigurasjons- og databasetekster lagres i formatetUNICODE
3. Det finnes ikke noe riktig svar
6.75 Til hvilket formål lagres konfigurasjons- og databasetekster i formatetUNICODE?
1. UNICODE-formatet sikrer uforanderlighet (uavhengighet av operativsystemets programvareplattform) for informasjonspresentasjon
2. FormatUNICODE lar deg støtte forskjellige språk i 1C:Enterprise-systemet
3. Det finnes ikke noe riktig svar
6.76 Internasjonaliseringsmekanismer fastsatt. ..
1. teknologiplattform 1C:Enterprise
2. anvendte løsninger
3. Svar 1 og 2 er riktige
4. det er ikke noe riktig svar
6.77 Hva er en lokaliseringskode?
1. En streng som består av en språkkode og en landskode som identifiserer en region i verden
2. Programvareproduktkode (angitt på registreringsskjemaet, dokumentasjon inkludert i leveringssettet)
3. Formater strengalternativ for konvertering
4. Svaret hennes er riktig
6.78 Er det sant at i 1C:Enterprise 8 kan all tekstinformasjon samtidig inneholde tegn fra forskjellige språk?
1. Ja, siden alle konfigurasjons- og databasetekster er lagret i formatetUNICODE
2. Avhengig av innstillingene som ble spesifisert ved opprettelse av infobasen
3. Bare hvis dette er gitt av konfigurasjonen
6.79 Hva er formålet med "Language"-konfigurasjonsobjektet?
1. For å lage et programgrensesnitt på forskjellige språk
2. Å lage tekstdokumenter på forskjellige språk
3. Et slikt objekt finnes ikke i 1C: Enterprise 8
6.80 Hvordan kan jeg endre språket for visning (redigering) av konfigurasjonen?
1. Bruke språkvalgknappen i statuslinjen til høyre for "NUM"-knappen
2. Gjennom menypunktet "Konfigurasjon - Konfigurasjonsredigeringsspråk"
3. I 1 C: Enterprise eksisterer ikke denne muligheten
4. Verpa svarer 1 og 2
6.81 Hva er stavemåten til de innebygde språkoperatørene?
1. Bare russisk skrift
3.
6.82 Er det mulig å bruke innebygde språkoperatører i russisk og engelsk skrift i én kildetekst?
1. Kun med spesielle konfiguratorinnstillinger
2. Ja, dette krever ikke å endre noen konfiguratorinnstillinger
3. Nei, siden det innebygde språkalternativet er satt i konfigurasjonsegenskapene
6.83 Hva er hensikten med det innebygde språket?
1. For å bestemme standard programgrensesnitt
2. Å beskrive (på konfigurasjonsutviklingsstadiet) algoritmer for funksjonen til en anvendt oppgave
3. Det finnes ikke noe riktig svar
6.84 Hva er stavemåten til de innebygde språkfunksjonene?
1. Bare russisk skrift
2. Kun engelsk stavemåte
3. Russisk og engelsk skrift
4. Avhengig av konfiguratorinnstillingene
6.85 Hva betyr parameter L?(L) i formatstrengen til NumberInWriting()-formateringsfunksjonen?
1. Signer "skriv ut brøkdelen i tall/ord"
2. Antall desimaler
3. Lokaliseringskode
7. Tabellmodell av applikasjonsløsningen
7.1 Når du setter opp begrensninger for datatilgang, kan du angi flere (basert på antall felt) begrensninger:
1. For "Les" høyre
2. For høyre "Endre"
3. For "Legg til"-høyre
4. For "Slett" høyre
5. For alle rettighetene ovenfor
6. For alle mulige rettigheter
7.2 Når du setter opp begrensninger for datatilgang, kan følgende brukes som verdier for begrensninger for datatilgang:
1. Kun verdier for øktparametere
2. Kun data fra tabeller (spørringer)
3. Sesjonsparameterverdier og data fra tabeller (spørringer)
4. Bare verdier med typer: Number, String, Boolean, Date
7.3 Hvilken av metodene ovenfor kan brukes slik at koden og navnet på katalogen vises i "Felt"-delen av spørringsdesigneren?
1. Fyll først ut «Tabell»-delen, og velg deretter de ønskede objektene fra denne delen, flytt dem til «Felt»-delen ved å dobbeltklikke med venstre museknapp
2. Uten å fylle ut "Tabell"-delen, velg umiddelbart de nødvendige objektene fra tabellene - datakilder i "Database"-delen, og overfør dem til "Felt"-delen ved hjelp av Dra og slipp-teknologi. "Tabell"-delen fylles ut automatisk
3. Fyll først ut "Tabell"-delen, og velg deretter de nødvendige objektene fra denne delen, overfør dem til "Felt"-delen ved å bruke knappene på skjemaet ">" """
4. Svar I og 3 er riktige
5. Svar I, 2 og 3 er riktige
7.4 For å øke hastigheten på utførelse av forespørselen, må du:
1. Sett parametere for de fleste virkelige tabeller
2. Angi parametere for de fleste virtuelle tabeller
3. I stedet for å spesifisere parametere for en ekte eller virtuell tabell, bruk valget spesifisert av "WHERE" spørringsspråkkonstruksjonen
4. Svar I og 2 er riktige
7.5 Er det mulig å tildele et nytt navn (alias) for det når du velger en kildetabell i "Tabell"-delen av spørringsdesigneren?
1. Ja det kan du
2. Ja, du kan, men bare hvis datakilden er en nestet spørring
3. Ja, du kan, men bare hvis datakilden er en virtuell tabell
4. Svar 1 og 2 er riktige
5. Svar 1 og 3 er riktige
7.6 En nestet spørring kan brukes:
1. Som en datakildetabell
2. Som en operand for sammenligningsoperasjoner "B" eller "NOT B" når du angir parametere for virtuelle tabeller
3. Som en operand for sammenligningsoperasjoner "B" eller "NOT B" når du spesifiserer spørringsspråkkonstruksjonen "WHERE"
4. Verpa svarer 1, 2 og 3
7.7 Er det mulig å få totaler etter hierarki ved å bruke spørringsdesigneren?
1. Det er mulig hvis du angir totaltypen "Elementer og hierarki" for grupperingsfeltet
2. Det er mulig hvis du spesifiserer totaltypen "Kun hierarki" for grupperingsfeltet
3. Verpa svarer 1 og 2
7.8 På "Betingelser"-fanen til spørringsdesigneren kan en egen linje i listen over betingelser genereres:
1. Dobbeltklikk med venstre museknapp på ønsket felt i listen over tilgjengelige felt
2. Ved å flytte ønsket felt til listen ved hjelp av Dra og slipp-teknologi
3. Klikk på "Legg til"-knappen. Hvis betingelsen er vilkårlig, kan betingelsesteksten skrives inn "manuelt"
4. Ring opp kontekstmenyen og velg "Legg til" fra den. Det er mulig å bruke et vilkårlig uttrykk
5. Alle svarene ovenfor er riktige
7.9 På «Koblinger»-fanen til spørringsdesigneren kan du definere:
1. Koble til datakildetabeller og relasjoner mellom dem
2. Kombinere datakildetabeller og forbindelser mellom dem
3. Forhold mellom feltene i tabellen oppnådd som et resultat av spørringen
4. Forhold mellom feltene i datakildetabellen og tabellen oppnådd som et resultat av spørringen
7.10 Når du kobler til datakildetabeller i spørringsdesigneren, kan du:
1. Tilordne en tilkobling uten å spesifisere tilkoblingsbetingelsen
2. Tilordne en tilkobling som indikerer tilkoblingstilstanden, og denne tilstanden kan bare være én
3. Tilordne en tilkobling som indikerer tilkoblingstilstanden, og denne betingelsen kan bare være enkel
4. Tilordne det nødvendige antallet tilkoblinger som indikerer det nødvendige antallet kommunikasjonsbetingelser, og disse betingelsene kan enten være enkle eller vilkårlige
7.11 Å opprette en forbindelse mellom datakildetabeller i spørringsdesigneren tillater:
1. Sammenføyning av bare to datakildetabeller
2. Koble til det nødvendige antallet datakildetabeller
3. Kobler bare to datakildetabeller, og avkrysningsboksen "Alle" må være merket av for minst én av tabellene
Grunnleggende, som gjør det lettere for nybegynnere å lære. Det er imidlertid ikke en direkte analog til noen av de listede språkene.Her er bare noen av de viktigste funksjonene til det innebygde språket:
- pre-kompilering; før utførelse konverteres moduler som inneholder tekst i det innebygde språket til intern kode;
- caching av kompilerte moduler i minnet;
- myk skriving - typen av en variabel bestemmes av typen verdi den inneholder og kan endres under drift;
- mangel på programvarebeskrivelse av konfigurasjonsobjekter; Utvikleren kan bruke enten objekter innebygd i plattformen eller objekter skapt av systemet som et resultat av visuell design av applikasjonsløsningen.
Hendelsesorientert innebygd språk. Formålet med det innebygde språket i 1C:Enterprise-systemet bestemmes av ideologien om å lage applikasjonsløsninger. Applikasjonsløsninger i 1C:Enterprise 8.0 er ikke fullstendig kodet. Det meste av applikasjonsløsningen er skapt av utvikleren gjennom visuell design - å lage nye konfigurasjonsobjekter, angi deres egenskaper, presentasjonsformer, relasjoner osv. Det innebygde språket brukes kun til å bestemme oppførselen til applikasjonsløsningsobjekter som er forskjellig fra standard én, og å lage sine egne databehandlingsalgoritmer.
Av denne grunn brukes moduler som inneholder tekst på det innebygde språket av systemet i spesifikke, tidligere kjente situasjoner som kan oppstå under driften av applikasjonsløsningen. Slike situasjoner kalles hendelser. Hendelser kan være assosiert med funksjonen til applikasjonsløsningsobjekter eller med selve applikasjonsløsningen som sådan.
For eksempel er en rekke hendelser knyttet til funksjonen til Directory-applikasjonsløsningsobjektet, blant annet BeforeWrite-hendelsen. Denne hendelsen inntreffer like før katalogelementdataene skal skrives til databasen. En utvikler, ved hjelp av et innebygd språk, kan beskrive en algoritme som for eksempel vil kontrollere riktigheten av data som legges inn av brukeren. Ved å plassere denne algoritmen i den aktuelle modulen, vil utvikleren sikre at hver gang brukeren registrerer et katalogelement, vil systemet utføre algoritmen opprettet av utvikleren og sjekke om brukeren har glemt å fylle inn de nødvendige katalogdetaljene.
Dermed kan vi si at det innebygde språket er et skriptspråk for programmering av forretningslogikk, og bruken av moduler i det innebygde språket er hendelsesavhengig, d.v.s. moduler kjøres når visse hendelser oppstår under driften av applikasjonsløsningen.
Forhåndsdefinerte datatyper
1C:Enterprise 8.0-plattformen lar utvikleren bruke ulike typer data.
Det er et stort antall datatyper som er definert på nivået av selve plattformen. For eksempel dette primitive datatyper, for eksempel streng, tall, dato osv.
Beskrivelse primitive datatyper:
- NULL- manglende verdi. Brukes for eksempel i spørringer.
- Udefinert- tom, udefinert verdi. Den brukes for eksempel ved evaluering av overføring av parametere hvis denne parameteren utelates når en prosedyre eller funksjon kalles. Detaljer som har en sammensatt datatype er av typen "Udefinert" som standard.
- boolsk- inneholder to verdier: True eller False. Brukes for eksempel i logiske uttrykk - et logisk uttrykk er av typen "boolsk".
- Dato- inneholder dato og klokkeslett. Standardverdien er 01/01/01 00:00:00 startdatoen for vår tidsalder. Tiden måles fra begynnelsen av dagen. Et uttrykk som har en bokstavelig type "dato" skrives som følger - "00010101000000". Først skrives året ned, så måneden, så datoen og så klokkeslettet. Følgende oppføring er mulig: "20041031". Standardtidspunktet er begynnelsen av dagen.
- Linje- kan være variabel, fast eller ubegrenset lengde. Generelt anbefales det å bruke strenger med variabel lengde.
- Antall- tallbitdybden er økt til 38 biter.
- Type- tjener til å bestemme typene verdier. Brukes for eksempel til å sammenligne datatyper. Den har ingen bokstaver og returneres av funksjonene Type(<Имя типа>) eller TypeValue(<Значение>).
Dessuten er det flere komplekse datatyper. For eksempel støtter plattformen en rekke typer som er universelle samlinger av verdier: matrise, struktur, liste over verdier, verditre, etc.
Datatyper "Universelle samlinger" - en liste (sett) over dataobjekter av enhver type, hvis verdier kan nås med brute force eller med en spesifisert indeks (nøkkel). Nummereringen av samlingselementer starter fra 0. Alle spesifiserte datatyper opprettes kun programmatisk.
Array. Representerer en nummerert samling av verdier av en vilkårlig type. Et matriseelement kan nås med indeksen. Elementene i en matrise kan spesielt være andre matriser. Dette lar deg lage flerdimensjonale arrays.
Struktur. Representerer en navngitt samling bestående av nøkkel-verdi-par. Nøkkelen kan bare være en streng, verdien kan være av en vilkårlig type. Et strukturelement kan nås med verdien av nøkkelen, dvs. ved navn. Brukes vanligvis til å lagre et lite antall verdier, hver med et unikt navn.
Korrespondanse. Akkurat som Structure, er det en samling nøkkel-verdi-par. Imidlertid, i motsetning til en struktur, kan en nøkkel være av nesten hvilken som helst type.
Liste over verdier. Brukes vanligvis til å løse grensesnittproblemer. Lar deg bygge dynamiske sett med verdier og manipulere dem (legge til, redigere, slette elementer, sortere). Den kan inneholde verdier av enhver type; i tillegg kan typene lagrede verdier i en liste være forskjellige.
Tabell over verdier. En verditabell lar deg bygge og manipulere dynamiske sett med verdier. Den kan fylles med verdier av enhver type, og i en tabell kan typene lagrede verdier være forskjellige.
Tre av verdier. Et verditre er et dynamisk generert sett med verdier av enhver type, som ligner på en verditabell. I motsetning til en verditabell, kan radene i et verditre danne hierarkiske strukturer: hver rad i treet kan ha et sett med underordnede rader, hver av de underordnede radene kan i sin tur også ha et sett med underordnede rader, og så videre. I dette tilfellet kan søk etter verdier, sortering og oppnå resultater utføres enten i henhold til gjeldende hierarkinivå, eller inkludere alle underordnede.
COMSafeArray. Representerer et objektomslag over en flerdimensjonal SAFEARRAY-array av
Prosedyre SelectFromFileClick(Element) // Velge en fil med viewingFileSelectionDialog = NewFileSelectionDialog(FileSelectionDialogMode.Open); FileSelectionDialog.Directory = ""; FileSelectDialog.Preview = Sant; FileSelectionDialog.FilterIndex = 0; If FileSelectDialog.Select() Then File = New File(FileSelectDialog.FullFileName); Bilde = NewValueStorage(NewImage(FileSelectionDialog.FullFileName)); DisplayImage(); slutt om; Slutt på prosedyre
THIS_KEYWORD
<Это конструкция языка>,
<Это конструкция
языка>
THIS_FUNCTION(<Это конструкция языка>)
I regler som beskriver et spørringsspråk, er språkkonstruksjoner angitt i vinkelparenteser. Nøkkelord og funksjonsnavn er beskrevet med store bokstaver.
Språkkonstruksjoner kan inneholde valgfrie elementer - nøkkelord osv. I reglene som beskriver spørringsspråket, er valgfrie elementer omsluttet av hakeparenteser "[" og "]":
[DETTE ER ET VALGFRITT ORD] [<Это необязательная конструкция>]
I noen tilfeller kan språkdesignet bruke ett av flere alternative elementer. Slike elementer i reglene er oppført gjennom en vertikal strek «|»:
EITHER_THIS_WORD | ELLER THIS_WORD
<Либо эта конструкция>
| <Либо эта конструкция>
Beskrivelser av alle konstruksjoner er ledsaget av eksempler som forklarer hvordan de brukes i spørringsspråket.
Kommentarer på spørrespråk
Anmodningsorganet kan inkludere kommentarer. En kommentar anses å være en del av en linje som begynner med sekvensen av tegn // og fortsetter til slutten av linjen:
// Dette er en kommentar.
Kommentarer ignoreres når forespørselen utføres.
Tospråklig representasjon av søkeord
En av de viktigste egenskapene til 1C: Enterprise spørringsspråk er at, som i det innebygde språket, har alle nøkkelord to stavemåter: på russisk og engelsk. Senere i dette kapittelet er russisk stavemåte for nøkkelord indikert. Nedenfor er en tabell som viser korrespondansen mellom russisk og engelsk og stavealternativer for søkeord på søkespråket...... (utelatt)
Hoveddeler av forespørselsteksten
Forespørselsteksten kan beskrives med følgende regel:
<Описание запроса>
[<Объединение запросов>]
[<Упорядочивание
результатов>]
[AUTO BESTILLING]
[<Описание итогов>]
Som det fremgår av denne regelen, består forespørselsteksten av flere deler, eller seksjoner:
I seksjon<Упорядочивание результатов>Du kan definere bestillingsbetingelser for radene i søkeresultatet. Bestilling av resultatet av en spørring er omtalt på side 324.
AUTO ORDER lar deg aktivere automatisk rekkefølge av rader i søkeresultatet. Denne modusen er beskrevet på side 331.
I seksjon<Описание итогов>Du kan spesifisere hvilke totaler som skal beregnes i spørringen. Denne delen er beskrevet på side 332.
Be om beskrivelse
Som allerede nevnt, må forespørselsteksten nødvendigvis inneholde en forespørselsbeskrivelsesdel, som definerer:
Felter som vil være inneholdt i resultatet av forespørselen;
Spørre datakilder - kildetabeller;
Forhold som påvirker valg av data i en forespørsel;
Rekkefølgen som søkeresultatene er gruppert i.
Forespørselsbeskrivelsesdelen består av flere sammenhengende setninger:
VELG [ANNERLEDES] [FØRST<Количество>]
<Список
полей выборки>
[FRA<Список источников>]
[HVOR<Условие отбора>]
[GRUPPE AV<Поля группировки>]
[HA<Условие отбора>]
[FOR ENDRING [<Список таблиц верхнего уровня>]]
Forespørselsbeskrivelsen begynner med et påkrevd nøkkelord VELGE.
By på HVOR<Условие отбора> lar deg filtrere søkeresultatet. Resultatet inkluderer bare de postene der den angitte betingelsen er sann. Reglene for beskrivelse av utvalgsforhold er omtalt på side 315.
By på FOR ENDRING er ment å indikere behovet for å blokkere data som leses i en transaksjon.
By på GRUPPE lar deg beskrive rekkefølgen søkeresultatene er gruppert i. Gruppering er omtalt i detalj på side 316.
By på HA lar deg pålegge betingelser for gruppering av resultater. Beskrevet på side 318.
Alle spørringseksemplene i dette kapittelet gir spørringsteksten og spørringsresultatet. Det antas at forespørselsteksten sendes som en parameter til Execute-metoden til Request-objektet.
La oss gi et eksempel på en ganske enkel spørring som består av én SELECT-setning og en liste med utvalgsfelt.
//Du må vise en liste over fakturaer i rapporten.
Søkeresultat:
Bruk av ordet ANNERLEDES
I mange situasjoner er det ønskelig at de samme radene i en rapport ikke gjentas.
// Det er nødvendig å finne ut hvilke motparter generelt
// varene ble sendt for perioden.
Velg Dokument.Faktura.motpart
Søkeresultat:
Det kan sees at søkeresultatet inneholder mange gjentatte linjer, noe som reduserer klarheten. For å unngå repetisjon bør søkeordet DIFFERENT spesifiseres i spørringsbeskrivelsen.
Velg Diverse Document.Invoice.Motpart
Søkeresultat:
Bruk av ordet FØRST
I noen tilfeller er det nødvendig å vise et begrenset antall rader i en rapport. For å gjøre dette, i spørringsbeskrivelsen bør du spesifisere nøkkelordet FØRST, og etter det - det nødvendige antallet linjer.
// Det er nødvendig å velge de fem dyreste varene.
// Valget bør utføres i synkende rekkefølge av produktprisen.
Velg Første 5
Directory.Nomenclature.Name,
Directory.Nomenclature.PurchasingPrice
Sorter etter Directory.Nomenclature.PurchasePrice Synkende
Søkeresultat:
Beskrivelse av utvalgsfelt
Etter det obligatoriske nøkkelordet SELECT (og de kvalifiserende ordene DIFFERENT og FIRST), spesifiseres en liste med utvalgsfelt i forespørselsteksten. Disse feltene vil bli behandlet ved henting av data i en forespørsel. Spørreresultatet vil også ha settet med felt definert i denne listen. Utvalgsfeltene er beskrevet i henhold til følgende regler:
<Описание поля>[ [HVORDAN]<Псевдоним поля>]
<Выражение>[.<Группа полей>]
Listen over utvalgsfelt består av ett eller flere elementer atskilt med komma. Hver<Поле выборки>består av en beskrivelse av valgfeltet og et valgfritt feltalias.
I stedet for å liste opp feltene i utvalgslisten, kan du angi en stjerne "*". Dette vil bety at spørringsresultatet må inneholde alle feltene som er i kildetabellene - spørringsdatakildene beskrevet i kildelisten.
Kommentar! Når du spesifiserer en stjerne "*" i listen over utvalgsfelt, inkluderes ikke de virtuelle feltene i kildetabellene i resultatet.
<Описание поля>definerer hvordan feltverdiene skal genereres. I det enkleste tilfellet er valgfeltet en lenke til et felt i kildetabellen. Koblingen kan spesifiseres ved å spesifisere tabellen som inneholder dette feltet, eller uten å spesifisere selve tabellen. Feltavregning er diskutert på.
Generelt kan valgfeltet ikke bare være en lenke til et felt i kildetabellen, men også noen<Выражение>. Uttrykk er omtalt i detalj på side 344.
Søkeresultater kan grupperes ved å bruke aggregerte funksjoner spesifisert som uttrykk i utvalgte felt. Gruppering av søkeresultater er omtalt på side 316. Aggregerte funksjoner er beskrevet på side 345.
Hvert valgfelt kan tildeles et alias. I fremtiden kan den brukes for mer praktisk tilgang til dette feltet. Bruken av feltaliaser diskuteres nedenfor.
<Группа полей>kan bare spesifiseres når valgfeltet peker til en nestet tabell. I dette tilfellet kan du spesifisere hvilke felt som skal behandles i det nestede tabellutvalget. Hvis en feltgruppe ikke er spesifisert, vil alle feltene i den nestede tabellen bli behandlet i utvalget. Tilgang til nestede tabeller er beskrevet i .
Feltaliaser i utvalgslisten
Hvis du tilordner et alias til et utvalgsfelt, kan du senere henvise til dette feltet ved å bruke dets alias i ORDER BY og TOTAL klausulene, samt når du arbeider med resultatet av en spørring. Slik behandling kan være mer praktisk og visuell, og i noen tilfeller den eneste mulige.
Nøkkelordet HOW kan gå foran feltaliaset. Dette ordet er kanskje ikke spesifisert i det hele tatt, men hvis det er spesifisert, øker synligheten og lesbarheten til forespørselsteksten.
Feltaliaser settes i samsvar med reglene for tildeling av variabelidentifikatorer. Kalenavnene i forespørselen kan ikke være de samme.
Å tildele aliaser til felt påvirker ikke i seg selv datautvalget i spørringen.
// Må velges fra produktkatalogen
// navn på varer og navn på grupper.
Velge
Katalog. Nomenklatur. Navn som produkt,
Katalog. Nomenclature.Parent.Name Som gruppe
fra
Directory.Nomenklatur
Søkeresultat:
Merk at feltene i feltspørringsresultatet heter "Vare" og "Gruppe". Hvis feltaliaser ikke ble spesifisert, vil feltene i søkeresultatet bli kalt "Navn" og "Navn1" (feltnavnene i søkeresultatet kan ikke samsvare, så "1" legges automatisk til navnet på det andre feltet). som er mye mindre tydelig.
Nestede tabeller i listen over utvalgsfelt
Et felt i utvalgslisten kan referere til en nestet tabell i spørringsdatakilden. I dette tilfellet vil søkeresultatfeltet være av typen spørringsresultat, det vil si at det vil inneholde et nestet spørringsresultat generert på grunnlag av en nestet kildetabell.
Som standard er alle feltene i den nestede tabellen – datakilden – inkludert i det nestede resultatet. Det er mulig å eksplisitt definere en gruppe felter som skal inneholdes i et nestet spørringsresultat. En gruppe med nestede resultatfelt er beskrevet i henhold til følgende regel:
(<Список вложенных полей>) | *
<Вложенное поле [, <Вложенное поле>[, ...] ]
<Список вложенных полей>består av ett eller flere elementer atskilt med komma. Hvis listen består av ett element, trenger den ikke stå i parentes.
I stedet for å liste nestede felt, kan du spesifisere en stjerne "*"; dette vil bety at det nestede spørringsresultatet må inneholde alle feltene som er i den nestede tabellen.
<Выражение>[[HVORDAN]<Псевдоним поля>]
<Вложенное поле>kan representere et uttrykk. I det enkleste tilfellet<Выражение>er en referanse til et felt i en nestet tabell. Uttrykk er omtalt i detalj på side 344.
Hvert nestede felt kan tildeles et alias. Lengre<Псевдоним поля>kan brukes for mer praktisk tilgang til dette feltet, i likhet med aliaser for felt i utvalgslisten - se avsnittet "Aliaser for felt i utvalgslisten" på
Aliaser kan tilordnes til nestede felt uavhengig av om et alias er tilordnet til selve den nestede tabellen.
//Det er nødvendig å vise spesifikasjonen av fakturaer i rapporten,
// selve dokumentet, nomenklatur og mengde.
Velge
Document.Invoice.Composition.(Nomenklatur som produkt, mengde)
Søkeresultat:
Link Sammensatt Produkt Mengde Jeans for kvinner 4 Jeans for kvinner 5 Skjorte "Cowgirl" 5 Faktura 00005 datert 24.02.2002 0:00:00 Jeans for kvinner 1 Jeans for kvinner 1 Moydodyr "Akvarium" 5 Synke "Lily" 8 Mikser "Ultra" 10
Vær oppmerksom på at "Komposisjon"-feltet i søkeresultatet er en nestet tabell som har feltene "Nomenklatur" og "Antall".
//Vis alle feltene i den tabellformede delen av fakturaen i rapporten.
Velge
Document.Invoice.Link,
Document.Invoice.Composition.*
Hensikten med IZ-leddet er å angi en liste over kildetabeller - datakilder som brukes i en gitt SELECT-setning.
Det skal bemerkes at IZ-leddet i spørringsspråket er valgfritt. Den kan utelates hvis datakildene er fullstendig kvalifisert i beskrivelsen av listen over utvalgsfelt i SELECT-leddet. Vær oppmerksom på at en rekke av eksemplene i de forrige avsnittene ikke inneholdt IZ-klausulen.
Etter nøkkelordet IZ vises en liste over kilder. Generelt er kildelisten beskrevet av følgende sett med regler:
<Источник>[, <Источник>[, ...]]
Spørringsdatakilder er oppført i kildelisten, atskilt med komma. Hver<Источник>kildelisten skal inneholde en beskrivelse av kilden; i tillegg kan det spesifiseres<Перечень соединений>- regler for å koble en kilde til andre kilder. Tilkoblingsspesifikasjoner er beskrevet.
<Описание источника> [ <Перечень соединений> ]
Hvis datakilden er en infobasetabell,<Описание источника>inneholder<Имя таблицы>.
<Таблица>[ [HVORDAN]<Псевдоним источника>]
Hvis kildetabellen er virtuell, kan du spesifisere<Параметры>dens dannelse. Virtuelle tabellparametere er beskrevet i detalj i delen "Forespørselsdatakilder".
<Имя таблицы> [(<Параметры>)] | <Описание запроса>
En underspørring kan også fungere som en spørringsdatakilde; i dette tilfellet inneholder kildebeskrivelsen<Описание запроса>. Bruken av nestede spørringer er beskrevet på.
Beskrivelsen av datakilden kan også tildele dens alias. Lengre<Псевдоним источника>kan brukes for mer praktisk tilgang til denne kilden. Bruk av datakildealiaser er omtalt på.
Tilkoblingsspesifikasjoner
Når du definerer flere kilder i kildelisten, for hver post fra den første kildetabellen, gjøres et valg fra den andre kildetabellen, og så videre. Dermed resulterer spørringen i alle mulige kombinasjoner av alle poster fra alle spesifiserte kilder.
Søkeresultat:
Motpart Bank Leverandører JSCB InvestBank Leverandører JSCB PromStroyBank Strikkefabrikk "Zarya" JSCB InvestBank Strikkefabrikk "Zarya" JSCB PromStroyBank Denim klesfabrikk JSCB InvestBank Denim klesfabrikk JSCB PromStroyBank Kjøpere JSCB InvestBank Kjøpere JSCB PromStroyBank Klesmesse JSCB InvestBank Klesmesse JSCB PromStroyBank Handelshuset "Budenovsky" JSCB InvestBank Handelshuset "Budenovsky" JSCB PromStroyBank Paviljong 45 på grossistmarkedet JSCB InvestBank Paviljong 45 på grossistmarkedet JSCB PromStroyBank Bayern - porselen JSCB InvestBank Bayern - porselen JSCB PromStroyBank Denim klesfabrikk JSCB InvestBank Denim klesfabrikk JSCB PromStroyBank JSCB PromStroyBank JSCB InvestBank JSCB PromStroyBank JSCB PromStroyBank
Spørreresultatet inneholder kombinasjoner av alle motparter med alle banker. Som regel gir et slikt resultat i seg selv ikke mening. Vanligvis må kombinasjoner av poster fra forskjellige kildetabeller begrenses av noen forhold. Det er mulig i et spørrespråk å beskrive en slik kombinasjon av kilder ved å spesifisere selve kildene og definere betingelsene for hvilke kombinasjoner av poster fra disse kildene må inkluderes i søkeresultatet.
Det er flere typer tilkoblinger, de er beskrevet av følgende regler:
<Соединение> [<Перечень соединений>]
Generelt<Перечень соединений>kan inneholde og beskrive ikke bare én forbindelse (av to kilder), men også flere forbindelser av flere kilder samtidig.
[INTERN] BLI MED<Описание источника>AV<Условие отбора> |
VENSTRE [YTRE] BLI MED<Описание источника>AV<Условие отбора> |
HØYRE [YTRE] BLI MED<Описание источника>AV<Условие отбора> |
FULL (YTRE] BLI MED<Описание источника>AV<Условие отбора>
<Условие отбора>inneholder betingelser som gjør at utvalget må kombinere data fra de originale tabellene - kildene til spørringen. Regler for å beskrive forhold på et spørringsspråk er omtalt på side 357.
Nøkkelordene VENSTRE, HØYRE og FULL avklarer sammenhengens natur. Ordene INTERN eller EKSTERN er kanskje ikke spesifisert i det hele tatt; de øker klarheten og lesbarheten til forespørselsteksten.
Kildene som slås sammen er ikke likeverdige med hverandre, og i noen tilfeller avhenger resultatet av hvilken tabell som er oppført først, før JOIN-nøkkelordet (til venstre for det), og hvilken tabell som er oppført nummer to (til høyre).
[INTERN] JOIN betyr at fra begge kildetabellene - datakilder, må bare de kombinasjonene av poster som oppfyller den angitte betingelsen inkluderes i spørringsresultatet. De resterende postene er ikke inkludert i resultatet.
// Trenger å finne ut hvilke banker som er samtidig
// motparter (de samme navn er til stede
//både i katalogen motparter og i bankkatalogen).
Velge
Banks.Link Hvordan banker
Fra
Inner Join
Directory.Banks Hvordan Banker
Av
Søkeresultat:
Motpart Bank JSCB PromStroyBank JSCB PromStroyBank
EN VENSTRE [YTRE] JOIN betyr at søkeresultatet må inkludere kombinasjoner av poster fra begge kildetabellene som oppfyller den angitte betingelsen. Men i motsetning til en intern sammenføyning, må søkeresultatet også inkludere poster fra den første kilden (indikert til venstre for ordet JOIN) som ingen poster fra den andre kilden ble funnet for som samsvarer med betingelsen.
På denne måten vil søkeresultatet inkludere alle poster fra den første kilden; de vil bli slått sammen med poster fra den andre kilden hvis den angitte betingelsen er oppfylt. Spørringsresultatlinjer der det ikke ble funnet noen poster fra den andre kilden som samsvarer med betingelsen, vil inneholde NULL i feltene som genereres basert på poster fra denne kilden.
//Det er nødvendig å vise alle motparter i rapporten, og for disse
// som også er en bank - angi en lenke til banken.
Velge
Counterpartyes.Link Som motpart,
Banks.Link Hvordan banker
Fra
Katalog Motparter Hvordan Motparter
Venstre ytre skjøt
Directory.Banks Hvordan Banker
Av
Motparter.navn = Banker.navn
Søkeresultat:
EN HØYRE [YTRE] JOIN betyr at søkeresultatet må inkludere kombinasjoner av poster fra begge kildetabellene som oppfyller en spesifisert betingelse. I tillegg må søkeresultatet også inkludere poster fra den andre kilden (indikert til høyre for ordet CONNECTION) som ingen poster fra den første kilden ble funnet for som samsvarer med betingelsen.
Dermed vil søkeresultatet inkludere alle poster fra den andre kilden; de vil bli slått sammen med poster fra den første kilden hvis den angitte betingelsen er oppfylt. Spørringsresultatlinjer der det ikke ble funnet noen poster fra den første kilden som samsvarer med betingelsen, vil inneholde NULL i feltene som genereres basert på poster fra denne kilden.
//Det er nødvendig å vise alle banker i rapporten, og for de
// som også er motpart - angi en lenke til motparten.
VELGE
Counterpartyes.Link Som motpart,
Banks.Link Like Bank
FRA
Katalog Motparter Hvordan Motparter
Høyre ytre skjøt
Directory.Banks Hvordan Banker
Av
Motparter.navn = Banker.navn
Søkeresultat:
Motpart Bank NULL JSCB InvestBank JSCB PromStroyBank JSCB PromStroyBank
EN FULL [YTRE] JOIN betyr at søkeresultatet må inkludere kombinasjoner av poster fra begge kildetabellene som oppfyller en spesifisert betingelse. I tillegg må søkeresultatet også inkludere postene fra begge kildene som det ikke ble funnet treff for.
På denne måten vil søkeresultatet inkludere alle poster fra begge kilder; de vil være koblet til hverandre når den angitte betingelsen er oppfylt. Forespørselsresultatlinjer der det ikke ble funnet poster fra noen kilde som samsvarer med betingelsen, vil inneholde NULL i feltene som genereres basert på poster fra den kilden.
// Det er nødvendig å vise alle motparter og alle banker i rapporten,
// og de som er begge - skriv ut på en linje.
Velge
Counterpartyes.Link Som motpart,
Banks.Link Hvordan banker
Fra
Katalog Motparter Hvordan Motparter
Full Ytre Sammenføyning
Directory.Banks Hvordan Banker
Av
Motparter.navn = Banker.navn
Søkeresultat:
Datakildealiaser
Hvis du tilordner et alias til en datakilde, kan denne kilden i fremtiden nås ved å bruke dette aliaset (og kan ikke lenger nås ved å spesifisere tabellnavnet). Slik behandling kan være mer praktisk og visuell, og i noen tilfeller den eneste mulige.
Aliaset er satt i samsvar med reglene for tildeling av variabelidentifikatorer. Kalenavnene i forespørselen kan ikke være de samme.
Nøkkelordet HOW kan gå foran kildealiaset. Dette ordet er kanskje ikke spesifisert i det hele tatt, men hvis det er spesifisert, øker synligheten og lesbarheten til forespørselsteksten.
Å tildele aliaser til kilder påvirker ikke i seg selv datautvalget i spørringen.
// Dette eksemplet viser bruken
// i listen over utvalgsfelt for aliaset Produkt,
// tilordnet kildetabellen Directory.Nomenclature
Velge
Produktnavn,
Produkt.Foreldre
Fra
Directory.Nomenclature.Product
Nestede tabeller i kildelisten
Kildelisten kan også inneholde nestede tabeller - tabelldeler av oppslagsverk og dokumenter.
//Det er nødvendig å vise spesifikasjonen av fakturaer i rapporten -
// vis selve dokumentet, nomenklatur og mengde.
//Kildelisten inneholder den nestede tabellen "Komposisjon" -
// tabelldel av fakturaen.
// Utvalget er begrenset til åtte poster for ikke å overbelaste eksemplet.
Velg First 8
Link, nomenklatur, mengde
Fra
Dokument.Faktura.sammensetning
Søkeresultat:
Link Nomenklatur Mengde Faktura 00007 datert 25.02.2002 21:03:21 Jeans for kvinner 4 Faktura 00006 datert 25.02.2002 0:00:00 Jeans for kvinner 5 Faktura 00006 datert 25.02.2002 0:00:00 Skjorte "Cowgirl" 5 Faktura 00005 fra 03/01/2002 20:58:28 Jeans for kvinner 1 Faktura 00004 datert 03/01/2002 20:50:40 Jeans for kvinner 1 Faktura 00003 datert 23.02.2002 0:00:00 Moydodyr "Akvarium" 5 Faktura 00003 datert 23.02.2002 0:00:00 Synke "Lily" 8 Faktura 00003 datert 23.02.2002 0:00:00 Mikser "Ultra" 10
Vær oppmerksom på at når du spesifiserer en nestet tabell i kildelisten, er det mulig å få tilgang til både feltene i selve den nestede tabellen og feltene i toppnivåtabellen (den som inneholder den nestede tabellen). I dette tilfellet åpnes "Link"-feltet i selve dokumentet.
Underspørringer i kildelisten
I listen over spørringskilder kan en underspørring brukes som kildetabell. I dette tilfellet inneholder kildebeskrivelsen underspørringsbeskrivelsen. Beskrivelsen av en nestet spørring er kompilert på nøyaktig samme måte som en vanlig: se
Å bruke en nestet spørring som en datakilde er ikke forskjellig fra å bruke en infobasetabell. Alle felt som er beskrevet i listen over felt for valg av underspørring er tilgjengelige som felt for en slik kilde.
Resultatet vil være nøyaktig det samme som i forrige eksempel.
Genererer rapporter
Jobber med forespørsler
For å jobbe med spørringer brukes et innebygd språkobjekt Be om . Den lar deg få informasjon lagret i databasefelt i form av en prøve dannet i henhold til spesifiserte regler.
Spørr datakilder
Spørringen mottar innledende informasjon fra et sett med tabeller. Disse tabellene representerer data fra ekte databasetabeller i en enkel å analysere form. De kan deles inn i to store grupper: ekte og virtuelle.
Virkelige tabeller kan på sin side være objekt (referanse) eller ikke-objekt (ikke-referanse):
Det særegne ved ekte tabeller er at de inneholder data fra en enkelt ekte tabell lagret i en database. For eksempel er virkelige tabeller tabellen "Directory.Clients", som tilsvarer katalogen "Clients", eller tabellen "Akkumulasjonsregister. Materialrester", som tilsvarer akkumuleringsregisteret "Material Resterende".
Virtuelle tabeller dannes primært fra data fra flere databasetabeller. For eksempel er en virtuell tabell tabellen "Akkumuleringsregister. Materialrester. Saldo og omsetning", dannet av flere tabeller i akkumuleringsregisteret "Materialrest". Noen ganger kan virtuelle tabeller dannes fra en reell tabell (for eksempel dannes den virtuelle tabellen "Prices.SliceLast" basert på informasjonsregistertabellen "Prices"). Felles for alle virtuelle tabeller er imidlertid at de kan gis en rekke parametere som bestemmer hvilke data som er inkludert i de virtuelle tabellene. Settet med slike parametere kan være forskjellig for forskjellige virtuelle tabeller, og bestemmes av dataene som er lagret i kildedatabasetabellene.
Reelle tabeller er delt inn i objekt (referanse) og ikke-objekt (ikke-referanse) tabeller.
Objekt(referanse)tabeller gir informasjon om referansedatatyper (kataloger, dokumenter, planer for karakteristikker osv.). Og i ikke-objekt (ikke-referanse) - alle andre datatyper (konstanter, registre, etc.).
Et særtrekk ved objekt(referanse)tabeller er at de inneholder et "Link"-felt som inneholder en lenke til gjeldende post. I tillegg er det for slike tabeller mulig å få en tilpasset representasjon av objektet; disse tabellene kan være hierarkiske og feltene til slike tabeller kan inneholde nestede tabeller (tabelldeler).
Spørrespråk
Algoritmen som data vil bli valgt fra kildetabellene til forespørselen er beskrevet i forespørselsteksten på et spesielt språk - spørrespråk. Forespørselsteksten består av flere deler:
forespørsel om beskrivelse,
slå sammen spørringer
bestille resultatene,
automatisk bestilling,
beskrivelse av resultatene.
Den eneste obligatoriske delen av forespørselen er den første - beskrivelsen av forespørselen. Alle andre er tilstede ved behov.
Be om beskrivelse definerer datakilder, utvalgsfelt, grupperinger osv.
Slår sammen søk bestemmer hvordan resultatene av flere søk skal kombineres.
Organisering av resultater definerer bestillingsbetingelsene for rader med søkeresultater.
Autobestilling lar deg aktivere automatisk rekkefølge av søkeresultatrader.
Beskrivelse av resultater bestemmer hvilke totaler som skal beregnes i spørringen og hvordan resultatene skal grupperes.
Rapport Register over dokumenter Ytelse av tjenester
Den første rapporten som vi vil begynne å bli kjent med spørringsspråket på grunnlag av, vil være rapporten "Register over dokumenter for levering av tjenester". Denne rapporten vil ganske enkelt vise en liste over "Service Provision"-dokumenter som finnes i databasen i rekkefølgen etter datoer og nummer.
La oss lage et nytt konfigurasjonsobjekt i konfiguratoren: Rapport "Register of Documents Levering of Services". La oss gå til "Layout"-fanen og starte utformingsdesigneren.
Som en datakilde for forespørselen vil vi velge objekttabellen (referanse) for "Service Provision"-dokumentene. Fra denne tabellen velger vi følgende felt:
"Herre",
"Klient":
Vær oppmerksom på at når du velger feltene "Warehouse", "Master" og "Customer", er feltene "Warehouse.View", "Master.View" og "Customer.View" også valgt i listen over valgte felt. Faktum er at i det generelle tilfellet antas det at disse feltene vil vises i cellene i et regnearkdokument. Siden de tilsvarende feltene "Warehouse", "Master" og "Customer" er referansefelt, hvis en referanseverdi sendes som en parameterverdi for output, vil systemet utføre en ekstra forespørsel om å få en representasjon av dette feltet (som vil være vist i dokumentet), noe som resulterer i tregere rapportutgang. Derfor, ved valg av referansefelt, tilbyr systemet å umiddelbart inkludere representasjoner av referansefelt i listen over valgte felt, i forventning om at de vil bli brukt for utdata til dokumentet.
Etter dette, la oss gå til "Ordre"-fanen og indikere at forespørselsresultatet først må sorteres etter verdien av "Dato"-feltet, og deretter etter verdien av "Service Provision. Link"-feltet:
La oss gå til "Rapport"-fanen og tilbakestille "Bruk rapportbygger"-flagget:
La oss tilbakestille "Bruk rapportbygger"-flagget...
Klikk "OK". Designeren vil generere rapportskjemaet og oppsettet. La oss åpne skjemamodulen og finne prosedyren "Register of Documents Levering of Services" i den. I denne prosedyren, hvordan forespørselsteksten vil bli generert, som vil bli brukt til å innhente dataene vi er interessert i:
Query.Text = "VELG
Levering av tjenester.Dato AS Dato,
Levering av tjenester. Antall AS-nummer,
Levering av tjenester. Lager,
Tilbyr tjenester. Lager. Presentasjon,
Tilbyr tjenester. Mester,
Tilbyr tjenester. Master. Presentasjon,
Levering av tjenester. Klient,
Levering av tjenester Kunde Representasjon
Document.Provision of Services HVORDAN yte tjenester
SORTER ETTER
Forespørselsteksten begynner, som vi sa ovenfor, med en del av forespørselsbeskrivelsen:
I Levering av tjenesten. Dato AS Dato,
I Levering av tjenester. Nummer AS-nummer,
I Levering av tjenester. Lager,
I Levering av tjenester. Lager. Presentasjon,
Jeg leverer tjenester. Mester,
I Levering av tjenester. Master. Presentasjon,
I Levering av tjenester. Klient,
1 Levering av tjenester Kunder Representasjon
I Dokument Levering av tjenester HVORDAN yte tjenester
Forespørselsbeskrivelsen begynner med et påkrevd nøkkelord VELGE. Dette etterfølges av en liste over utvalgte felt som beskriver feltene som skal inneholdes i søkeresultatet. Denne listen kan inneholde både selve feltene og noen uttrykk beregnet ut fra feltverdiene.
Etter IZ-nøkkelordet er datakilder indikert - de originale spørringstabellene, hvis innhold behandles i spørringen. I dette tilfellet er dette objekt(referanse)tabellen "Document.Provision of Service". Etter nøkkelordet HVORDAN angitt pseudonym datakilde. I vårt tilfelle er dette "Å levere tjenester". I fremtiden kan denne datakilden nås i hoveddelen av forespørselen ved hjelp av et alias.
Vi ser denne oppfordringen i beskrivelsen av utvalgsfeltene:
| Levering av tjenester.Dato AS Dato,
| Levering av tjenester. Antall AS-nummer,
| Levering av tjenester. Lager,
| Tilbyr tjenester. Lager. Presentasjon,
| Tilbyr tjenester. Mester,
| Tilbyr tjenester. Master. Presentasjon,
| Levering av tjenester. Klient,
| Levering av tjenester Kunde Representasjon
Utvalgsfelt kan også ha aliaser, som kan brukes til å referere til dette feltet senere i forespørselsteksten. I vårt tilfelle er dette aliasene "Dato" og "Nummer".
Etter beskrivelsesdelen av spørringen i vårt eksempel kommer resultatbestillingsdelen:
| BESTILL ETTER
| Dato, | Antall";
By på SORTER ETTER lar deg sortere radene i søkeresultatet. Etter dette nøkkelleddet er et ordensuttrykk, som generelt sett er en liste over felt (uttrykk) og utdatarekkefølge. I vårt tilfelle vil bestillingen først utføres av valgfeltet, som er tilgjengelig via aliaset - "Kode", og deretter av feltet - "Nummer". I begge tilfeller vil sorteringsrekkefølgen være stigende, som er standard sorteringsrekkefølge.
La oss nå ta hensyn til hvordan søkeresultatet vises i et regnearkdokument.
Prosedyre Register over dokumenter Levering av tjenester (TabDoc) Eksport
//((CONSTRUCTOR_OUTPUT_FORM(Register over dokumentlevering av tjenester)// Dette fragmentet ble bygget av konstruktøren.// Ved gjenbruk av konstruktøren,// introdusert manuelt Endringer Vil gå tapt!!!
Layout = GetLayout("Register over dokumenter som leverer tjenester"); Request = Ny forespørsel;
Resultat = Query.Run();
HeaderArea = Layout.GetArea("Header"); AreaKeller =
Layout.GetArea("TableFooter"); DetailRecordsArea =
TabDoc.Output(TableHeadArea); TabDoc.StartAutogruttingRows();
SelectDetails = Result.Select();
Mens SelectDetails.NextFunctions() Loop
AreaDetailRecords.Parameters.Fill(SelectionDetails);
TabDoc.Output(RecordsDetailsArea,DetailsSelection.Level()); EndCycle;
/L)CONSTRUCTOR_OUTPUT_FORM Sluttprosedyre
Rapportskjemaet inneholder et kontrollelement TabularDocumentField med navnet "TabDoc", som er fylt med data basert på layouten generert av designeren.
I begynnelsen av prosedyren får vi rapportoppsettet, hvorfra vi deretter henter områdene som eksisterer i den til de tilsvarende variablene:
HeaderArea = Layout.GetArea("Header"); AreaKeller =
Layout.GetArea("Kjeller"); TableHeaderArea =
Layout.GetArea("TableHeader"); TableFooterArea =
Layout.GetArea("TableFooter"");DetailRecordsArea =
Layout.GetArea("Detaljer");
Deretter tømmer vi regnearkdokumentet og viser de områdene som ikke inneholder data hentet fra søkeresultatet:
TabDoc.Clear(); TabDoc.Output(AreaHeader);
TabDoc.Output(TableHeadArea); TabDoc.StartAutoGroupingRows();
I den siste linjen la designeren til begynnelsen av autogruppering av rader. I dette eksemplet har vi ikke rader som må grupperes, men som standard foreslår designeren alltid å gruppere rader i et regnearkdokument. Dette kallet vil ikke påvirke hastigheten på rapportutdata, så vi lar konstruktørteksten være uendret.
Etter dette får vi et utvalg fra søkeresultatet, som vi går gjennom i en sløyfe:
I hver iterasjon av løkken fyller vi parametrene til det tidligere oppnådde layoutområdet med verdier hentet fra neste søkeresultatprøvepost og viser dette området i et regnearkdokument.
På slutten av prosedyren viser vi de siste områdene av layouten i et regnearkdokument:
TabDoc.FinishAutoGroupingRows();
TabDoc.Output(TableFooterArea);
TabDoc.Output(AreaFooter);
La oss nå starte 1C:Enterprise i feilsøkingsmodus og se på resultatet av rapporten vår:
Ved å bruke eksemplet i denne rapporten demonstrerte vi derfor hvordan vi bruker utdataskjemadesigneren og ble kjent med noen grunnleggende spørringsspråkkonstruksjoner.
"Service Rating"-rapporten vil inneholde informasjon om hvilke tjenester som ga Master of All Trades LLC størst fortjeneste i den angitte perioden. Ved å bruke "Service Rating"-rapporten som et eksempel, vil vi illustrere hvordan du velger data i en bestemt periode, hvordan du setter søkeparametere og hvordan du bruker data fra flere tabeller i en spørring og inkluderer alle data fra en av kildene i søkeresultat.
La oss lage et nytt konfigurasjonsobjekt "Service Rating"-rapport. La oss gå til "Layouts"-fanen og kalle utgangsskjemakonstruktøren.
La oss velge objekttabellen (referanse) til katalogen "Nomenklatur" og den virtuelle tabellen til akkumuleringsregisteret "Sales.Turnover". For å eliminere tvetydigheten til navn i spørringen, gir vi nytt navn til "Nomenclature"-tabellen til "SprNomenclature" (høyreklikk kontekstmeny).
Plasser deretter markøren på "SalesTurnover"-tabellen og åpne dialogen for å angi virtuelle tabellparametere:
Åpne dialogboksen for å angi virtuelle tabellparametere
La oss indikere at begynnelsen og slutten av perioden vil bli overført i de tilsvarende parameterne «StartDate» og «EndDate» («&»-symbolet før navnet indikerer at dette er en forespørselsparameter):
Velg deretter feltene "SprNomenclature.Link" og "SalesTurnover.RevenueTurnover" fra tabellene:
SprNomenclature.Presentation
SalgOmsetningInntektOmsetning
La oss gå til fanen "Koblinger" og se at designeren allerede har opprettet en forbindelse mellom de to valgte tabellene - verdien av registerendringen "Nomenklatur" skal være lik referansen til katalogelementet "Nomenklatur".
Det eneste som gjenstår for oss å gjøre er å tilbakestille "All"-flagget for registertabellen og sette det for katalogtabellen.
Vi vil velge alle elementene fra "Nomenklatur"-katalogen
Å sette «Alle»-flagget ved katalogtabellen vil bety at alle elementer vil bli valgt fra katalogen og disse elementene vil bli tildelt inntektsomsetningsverdien fra registeret. Som et resultat av forespørselen vil derfor alle tjenester være til stede, og for noen av dem vil inntektsomsetningen bli indikert. For de tjenestene som ikke ble levert i den valgte perioden, vil ingenting bli angitt.
La oss gå til fanen "Betingelser" og angi betingelsene for å velge elementer fra "Nomenklatur"-katalogen. Når vi setter valgbetingelsene, vil vi igjen bruke spørringsparametere. Den første betingelsen må være at det valgte elementet ikke er en gruppe (for å gjøre dette, bytt til "Custom Condition"-modus).
Den andre betingelsen må være at den valgte varen er en tjeneste (dette er den "enkle betingelsen"):
I fremtiden, før vi utfører forespørselen, vil vi sende den tilsvarende oppregningsverdien til parameteren "Type of Nomenclature".
La oss gå til "Associations/Aliases"-fanen og spesifisere at katalogelementvisningen vil ha aliaset "Service", og registerfeltet vil ha aliaset "Revenue":
La oss gå til «Ordre»-fanen og angi at søkeresultatet skal sorteres i synkende rekkefølge etter verdien av «Inntekt»-feltet.
På «Totaler»-fanen bestemmer vi at vi må vise generelle totaler, og de skal være summen av verdiene i «Inntekt»-feltet:
På "Rapport"-fanen fjerner du "Bruk rapportbygger"-flagget.
La oss nå gå til kategorien "Output Form". La oss indikere at parameterne "Sluttdato" og "Startdato" vil bli redigert i skjemaet i inndatafeltene av typen "Dato". For parameteren "Type of Nomenclature" vil vi tvert imot fjerne redigeringsflagget i skjemaet:
Klikk "OK". Plattformen vil generere et layout og rapportskjema Åpne skjemamodulen og finn fremgangsmåten for «Service Rating» i den.
I denne prosedyren, i delen der spørringsparametrene er satt, vil vi bestemme verdien av parameteren "Nomenclature Type" (korrigeringer er uthevet med fet skrift):
| VENSTRE TILKOBLING Registrer Akkumulering.Salg,Omsetning(&Startdato,
| &Utløpsdato,)
| HVORDAN SALGES Omsetning
| BESTILL ETTER | Inntekt NED
|RESULTATBELØP (inntekt) ETTER | ER VANLIG";
RequestSetParameterC"Type of Nomenclature",
Transfers.Types of Nomenclature.Service);
Query.SetParameter("StartDate",StartDate); Request.SetParameterC"EndDate", EndDate);
La oss nå se på forespørselsteksten generert av konstruktøren:
| SprNomenclature.Representation AS Representation,
|SalgOmsetning.OmsetningOmsetning AS Omsetning
| Directory.Nomenclature AS RefNomenclature
VENSTRE TILKOBLING Registrer Akkumulasjoner.Salg.Omsetning(&Startdato,
| HVORDAN SALGES Omsetning
| Software SalesTurnover.Nomenclature = SprNomenclature.Link
| (RefNomenclature.ThisGroup = False) OG
| SprNomenclature.Type of Nomenclature = &Type of Nomenclature
| BESTILL ETTER
| Inntekt NED
|RESULTATBELØP (inntekt) ETTER
Først kommer som vanlig forespørselsbeskrivelsesdelen og den inneholder konstruksjoner som er nye for oss.
Når forespørselskildene ble beskrevet (etter IZ-nøkkelordet), ble muligheten til å definere flere forespørselskilder brukt:
| Directory.Nomenclature AS RefNomenclature
|&Sluttdato,)
| HVORDAN SALGES Omsetning
| Software SalesTurnover.Nomenclature = SprNomenclature.Link
I dette tilfellet velges poster fra to kilder: "SprNomenklatura" og "SalesTurnover", med nøkkelsetningen VENSTRE FORBINDELSE... AV beskriver måten registreringer fra disse to kildene vil bli kombinert på.
VENSTRE FORBINDELSE betyr at søkeresultatet må inkludere kombinasjoner av poster fra begge kildene som samsvarer med betingelsen spesifisert etter nøkkelordet BY. I tillegg må søkeresultatet også inkludere poster fra den første (angitt til venstre for ordet FORBINDELSE) kilde som ingen poster som samsvarer med tilstanden ble funnet fra den andre kilden.
Det er ikke noe nytt for oss i beskrivelsen av den første kilden og tilkoblingstilstanden, men når vi beskriver den andre kilden, bruker vi muligheten til å angi parameterne til den virtuelle spørringstabellen:
| Registrer Akkumulasjoner.Salg.Omsetning(&Startdato, &Sluttdato,)
Den første parameteren er begynnelsen av perioden for beregning av totalene, den andre er slutten av perioden. Som et resultat vil kildetabellen kun inneholde omsetningen beregnet i den overførte perioden. Her bør du alltid huske at hvis vi passerer en dato som disse parameterne (og i vårt tilfelle vil dette være tilfellet), så inneholder datoen også tiden nøyaktig til sekundet.
Hvis det er kjent på forhånd at brukeren ikke vil være interessert i resultatene av rapporten i perioder spesifisert med en nøyaktighet på sekunder, bør følgende funksjon tas i betraktning: som standard er klokkeslettet i datoen satt til 00 :00:00. Hvis du derfor ikke iverksetter spesielle tiltak, viser det seg at når brukeren setter rapporteringsperioden fra 03/01/2004 til 31/03/2004, vil registersummene bli beregnet fra begynnelsen av dagen 03/01/ 2004 00:00:00 til begynnelsen av dagen 31/03/2004 00:00: 00. Data for den 31. dagen, bortsett fra begynnelsen av dagen, vil derfor ikke bli inkludert i beregningen, noe som vil overraske brukeren sterkt.
For å eliminere denne situasjonen, bør to ting gjøres.
Først, i rapportskjemaet, begrenser du brukerens mulighet til å angi startdato og sluttdato ved å sette datosammensetningen for de tilsvarende inndatafeltene som "Dato":
La oss bestemme sammensetningen av datoen ...
For det andre, når du sender parametere, bruk den innebygde funksjonen Slutten av dagen(). For å gjøre dette, gå tilbake til rapportskjemamodulen og gjør de nødvendige endringene (tillegg er uthevet med fet skrift):
ProcedureFormActionsRatingServicesGenerate(Button) //((CONSTRUCTOR_WEEKEND_FORM_PROCEDURE_CALL(RatingServices) //Dette fragmentet ble bygget av konstruktøren. // Ved gjenbruk av konstruktøren vil // manuelt utførte endringer gå tapt!!!
TabDoc = FormElements.TableField;
//))CONSTRUCTOR_OUTPUT_FORM_CALL_PROCEDURE
Co. netprosedyrer
La oss fortsette å se på forespørselsteksten. Som en del av spørringsbeskrivelsen er det en annen konstruksjon som er ny for oss - å sette betingelser for valg av data fra kildetabellene:
| SprNomenclature.Representation AS Representation,
| SalgOmsetning.OmsetningOmsetning AS Omsetning
| Directory.Nomenclature AS RefNomenclature
| VENSTRE TILKOBLING Registrer Akkumulasjoner.Salg.Omsetning(&Startdato,
| &Utløpsdato,
| HVORDAN SALGES Omsetning
| Software SalesTurnover.Nomenclature = SprNomenclature.Ssshka
| SprNomenclature.ThisGroup = Falsk OG
| SprNomenclature.Type of Nomenclature = &Type of Nomenclature
Valgbetingelsen innledes alltid med et nøkkelord HVOR. Etter det beskrives selve tilstanden. Vær oppmerksom på at feltene i kildetabellene som betingelsen er brukt på, kanskje ikke er inkludert i utvalgslisten (som i vårt tilfelle). I tillegg bruker betingelsen vår søkeparameteren "Type of Nomenclature".
RESULTATBELØP (inntekt) PO
Det starter alltid med et nøkkelord RESULTATER, etterfulgt av en beskrivelse av hvilke totaler som vil være tilstede i søkeresultatet. Umiddelbart etter ordet RESULTATER beskriver aggregerte funksjoner som må beregnes i resultatene. I vårt tilfelle vil beløpet i «Inntekt»-feltet bli beregnet. Deretter følger nøkkelordet PO, hvoretter grupperingene som totalene skal beregnes i, beskrives. I vårt tilfelle er de fraværende og bare nøkkelordet brukes ER VANLIG, som indikerer at totalsummene vil bli beregnet for hele tabellen som helhet.
Nå som vi er ferdige med å bli kjent med teksten i forespørselen, la oss starte 1C:Enterprise i feilsøkingsmodus og se hvordan rapporten vår fungerer.
La oss sette rapporteringsperioden fra 03/01/2004 til 30/04/2004. Resultatet vil se slik ut:
La oss nå endre sluttdatoen til 31.03.2004 og sørge for at dataene for 31. mars er inkludert i rapporten:
