1s pakešu vaicājuma izpilde. Manekenu pakešu pieprasījumi. Metodes Run() un RunBatch()

Šis raksts ir paredzēts lasītājiem, kuri pārzina SQL valodu.

1C vaicājumu valoda, kas tiek izmantota kopš 8. versijas, šodien ir kļuvusi par noderīgu rīku darbam ar datu bāzēm, kas ļauj no tām lasīt, bet ne rakstīt. Sintaktiski vaicājuma valoda ir ļoti līdzīga SQL valodai, bet krievu valodā.

Tālāk ir sniegta atbilstības tabula starp galveno vaicājumu valodu un SQL operatoriem:

1C vaicājumu valodu operatori

SQL priekšraksts

DAŽĀDI

SAVIENOTS

GROUP BY

KOMBINĒT

KĀRTOT PĒC

Un tas nav pilnīgs saraksts. Pilnīgāku atsauces informāciju par pieejamajiem vaicājumu valodu operatoriem var iegūt vaicājumu noformētājā, kas tiks apspriests tālāk.

1C pieprasījuma izpilde no programmas koda tiek veikta, izmantojot iebūvēto valodas objektu “Pieprasījums”. Piemērs datu bāzes vaicājuma rakstīšanai, izmantojot iebūvēto programmēšanas valodu:

Pieprasījums = jauns pieprasījums; Query.Text = "SELECT | Synonym.Link AS Link |FROM | Directory.Directory1 AS Sinonīms"; Select = Query.Run().Select(); While Selection.Next() Loop // Ievietot atlases apstrādi SelectionDetailedRecords EndCycle;

Metode “Run” izpilda vaicājumu, metode “Select” atgriež vērtību, kuras veids ir “SelectFromQueryResult”. Varat arī izmantot izkraušanas metodi, kas atgriež vērtību tabulu.

Pieprasījuma parametri tiek saglabāti rekvizītā “Parameters” (šajā gadījumā šī ir struktūra, tāpēc šeit ir piemērojamas visas struktūras metodes - ievietošana, dzēšana utt.).

Parametra “Query.Parameters.Insert” (“Directory”, DirectoryLink) iestatīšanas piemērs. Pieprasījumā varat piekļūt parametriem, izmantojot & Directory. Tālāk ir parādīts pieprasījuma piemērs, izmantojot parametrus:

Pieprasījums = jauns pieprasījums; Query.Text = "SELECT | Users.Link AS saite, | Users.Parent AS Parent, | Users.Name AS nosaukums |FROM | Directory.Users AS Users |WHERE | Users.Link = &Directory"; Query.Parameters.Insert("Directory", DirectoryLink); Select = Query.Run().Select(); While Selection.Next() Loop // Ievietot atlases apstrādi SelectionDetailedRecords EndCycle;

Atcerēsimies, ka vaicājumu valoda ir paredzēta tikai datu nolasīšanai no datu bāzes, tāpēc tai nav analogu tādiem SQL priekšrakstiem kā INS ERT un UPDATE. Datus var modificēt tikai ar iebūvētās 1C programmēšanas valodas objekta modeli. Arī 1C vaicājumu valodā ir operatori, kuriem SQL nav analogu, piemēram:

  • HIERARHIJĀ
  • VIETA
  • INDEX BY

HIERARHIJĀ– ļauj atlasīt visus hierarhiskā direktorija elementus, kas ir iekļauti pārsūtītās saites hierarhijā. Pieprasījuma piemērs, izmantojot HIERARHIJĀ:

SELECT Produkti.Saite, Produkti.Raksts NO direktorija.Produkti AS Produkti WHERE Produkti.Saite HIERARHIJANĀ(&Citrusaugļi)"

Šajā gadījumā rezultāts atgriezīs visus Citrus nomenklatūras direktorija pakārtotos elementus neatkarīgi no tā, cik hierarhijas līmeņu ir šim direktorijam.

Tāpat, piemēram, uzdevums ir atrast preci ar nosaukumu “Pildspalva”. Produktam ir jābūt iekļautam “Kancelejas preču” hierarhijā. Preces”, tas ir, mums nav jāmeklē durvju rokturis. Nomenklatūras struktūra šajā gadījumā ir šāda:

Birojs

|_ Tintes pildspalvas |_ Sarkans pildspalvas |_ Zila pildspalva |_ Tintes pildspalvas |_ Lineāli

Piederumi

|_ Durvju rokturi |_ Vienkāršs durvju rokturis |_ Luksusa durvju rokturis

Mēs rakstām šādu pieprasījumu:

SELECT Produkti.Saite, Produkti.Raksts NO direktorija.Produkti AS Produkti WHERE Produkti.Nosaukums, piemēram, "Pen%" AND Products.Saite HIERARCHY(&Kancelejas preces)"

Izmantojot dizainu HIERARHIJĀ jāņem vērā, ka, nododot tukšu saiti parametram “Office”, pieprasījuma izpilde palēnināsies, jo platforma pārbaudīs katru elementu, lai redzētu, vai tas pieder saknei.

VIETA– Šis paziņojums ievieto rezultātu pagaidu tabulā. Pieprasījuma piemērs:

SELECT Users.Link AS Saite, Users.Parent AS Parent, Users.Name AS Nosaukums PLACE SelectedLietotāji FROM Directory.Users AS Users WHERE Users.Link = &Directory; SELECT SelectedUsers.Link AS Saite, SelectedUsers.Parent AS Parent, SelectedUsers.Name AS Nosaukums FROM SelectedUsers AS SelectedUsers

Šis SQL vaicājums tiks izpildīts ar vairākiem vaicājumiem:

  • Pagaidu tabulas izveide (platforma var “atkārtoti izmantot” iepriekš izveidotās pagaidu tabulas, tāpēc izveide ne vienmēr notiek);
  • Datu ievietošana pagaidu tabulā;
  • Galvenā vaicājuma izpilde, proti, SEL ECT no šīs pagaidu tabulas;
  • Pagaidu galda iznīcināšana/tīrīšana.

Pagaidu tabulu var tieši iznīcināt, izmantojot konstrukciju IZNĪCINĀT, vai netieši - aizverot pagaidu tabulu pārvaldnieku.

Iebūvētās programmēšanas valodas objektam “Query” ir rekvizīts “Temporary Table Manager”, kas paredzēts darbam ar pagaidu tabulām. Koda piemērs:

MVT = jauns pagaidu tabulu pārvaldnieks(); Pieprasījums = jauns pieprasījums; Query.TemporaryTableManager = MVT;

Pēc vaicājuma izpildes MVT mainīgo var izmantot otrreiz citā vaicājumā, kas neapšaubāmi ir vēl viena pagaidu tabulu izmantošanas priekšrocība. Šajā gadījumā pagaidu tabula no datu bāzes tiks dzēsta, kad tiks izsaukta metode “Aizvērt”...

MVT.Aizvērt();

...vai dzēšot mainīgo no atmiņas, tas ir, izpildot metodi, kurā mainīgais tika deklarēts. Pagaidu tabulas palielina diska apakšsistēmas slodzi, tāpēc nevajadzētu izveidot pārāk daudz pagaidu apakšsistēmu (piemēram, cilpā) vai liela apjoma apakšsistēmu.

INDEX BY– šis operators tiek izmantots kopā ar operatoru VIETA. Veidojot pagaidu tabulu, šis operators var indeksēt veidojamo tabulu, kas ievērojami paātrina darbu ar to (bet tikai tad, ja indekss atbilst jūsu vaicājumam).

Bezmaksas ekspertu konsultācija

Paldies par jūsu pieprasījumu!

1C speciālists ar jums sazināsies 15 minūšu laikā.

Dažu vaicājumu valodu operatoru iezīmes

PĀRMAIŅĀM– šis operators ir paredzēts, lai bloķētu noteiktu vaicājumu tabulu (vai visas tabulas, kas piedalās vaicājumā). Bloķēšana tiek veikta, uzliekot galdam U slēdzeni. SQL tas tiek īstenots, izmantojot mājienu UPDLOCK. Šis dizains ir nepieciešams, lai novērstu strupceļu. Pieprasījuma piemērs ar konstrukciju PĀRMAIŅAI:

IZVĒLĒTIES Lietotāji.Saite AS Saite, Lietotāji.Vecāks AS Vecāks, Lietotāji.Vārds AS Nosaukums FROM Direktorija.Lietotāji AS Lietotāji AIZLIETOJAS PIEVIENOTIES Directory.RFK AS RFK, IZDEVĪJOT Lietotāji.RFK = RFK.Saite, LAI MAINĪT direktoriju.Lietotāji

Šajā piemērā U slēdzene tiks ievietota lietotāju tabulā. Ja nenorādīsiet bloķēšanas tabulu, tā tiks uzlikta visām tabulām, kas piedalās vaicājumā. Ir svarīgi atzīmēt, ka šis dizains darbojas tikai konfigurācijās, kurās ir iespējots automātiskais bloķēšanas pārvaldības režīms.



SAVIENOTS– pieprasījums atbalsta savienojumus KREISI/LABI, PILNĪGS, IEKŠĒJS, kas atbilst savienojumiem SQL – LEFT/RIGHT JOIN, OUTER JOIN, INNER JOIN.

Tomēr, izmantojot vaicājumu veidotāju, jūs to nevarēsit izdarīt PAREIZI PIEVIENOJIES. Konstruktors vienkārši apmainīs galdus, bet operators vienmēr būs kreilis. Šī iemesla dēļ jūs nekad neredzēsit labā savienojuma izmantošanu 1C.

Sintaktiski savienojums izskatās šādi:

SELECT Table1.Link AS Saite no FROM Directory.Directory1 AS Table1 LEFT JOIN Directory.Directory2 AS Table2 BY Table1.Attributes = Table2.Attributes

1C vaicājumu valodai nav operatora, lai pievienotos Dekarta produktam (CROSS JOIN). Tomēr operatora neesamība nenozīmē, ka vaicājuma valoda neatbalsta šādu savienojumu. Ja nepieciešams, varat pievienot tabulas šādi:

ATLASĪT Tabulu 1.Saite AS Saite no FROM Direktorija.Directory1 AS Table1 LEFT JOIN Directory.Directory2 AS Table2 BY TRUE

Kā redzams no piemēra, savienojuma atslēga ir iestatīta PATIESĪGI, tas ir, katra vienas tabulas rinda atbilst citas tabulas rindai. Savienojuma veids (LEFT, RIGHT, FULL, INNER) nav svarīgs, ja jums ir rindas abās tabulās, bet, ja vienā no tabulām (teiksim, tabulā) nav rindu - rezultāts būs atšķirīgs. Piemēram, lietojot IEKŠĒJĀ savienojuma rezultāts būs tukšs. Izmantojot PA KREISI PA LABI savienojuma rezultāts būs vai nebūs dati atkarībā no tā, kuru tabulu mēs pievienojam - ar datiem vai nē. Izmantojot PILNĪGS Dati vienmēr tiks savienoti (protams, tikai no vienas tabulas, jo otra ir tukša, savienojuma veida izvēle ir atkarīga no konkrētā lietojumprogrammas uzdevuma).

Neliels vizuāls padoms par to, kā darbojas dažādi savienojuma veidi:



PATĪK. Atšķirībā no līdzīgā SQL operatora - LIKE, veidne priekš PATĪK var norādīt, izmantojot tikai dažas speciālās rakstzīmes:

  • % (procenti): secība, kas satur jebkādu skaitu patvaļīgu rakstzīmju;
  • _ (pasvītrojums): viena patvaļīga rakstzīme;
  • / - nākamā rakstzīme ir jāinterpretē kā parasta rakstzīme.

PROGRAMMATŪRAS REZULTĀTI SQL analogs ir ROLLUP operators. Operatora lietošanas piemērs REZULTĀTI:

IZVĒLĒTIES PRODUKTI.Cena AS Cena, Produkti.Produkts AS Prece NO Kataloga.Nomenklatūra AS Produkti REZULTĀTI VIDĒJIE (Cena) PA produktiem

Rezultāts būs šāds:

Gulta

9833,333

Dzelzs

Pildspalva

Tas nozīmē, ka rezultātam tiek pievienota papildu rindiņa, kas satur lauka vērtību, ar kuru tiek veikta grupēšana, un apkopošanas funkcijas vērtību.

Darbs ar pakešu pieprasījumiem

1C ļauj strādāt ar pieprasījumu partijām. Pakešu pieprasījumā pieprasījuma teksti tiek atdalīti ar semikolu (;). 1C partijas pieprasījums tiek izpildīts secīgi. Pakešu pieprasījuma teksta piemērs:

SELECT Users.Link AS Saite, Users.Parent AS Parent, Users.Name AS Nosaukums FROM Directory.Users AS Users;
SELECT Darba grafiks.Lietotājs AS Lietotājs, Darba grafiks.Datums AS Datums, Darba grafiks.Darba laiks AS Darba laiks NO Reģistrēties Informācija.Darba grafiks AS Darba grafiks

Lai iegūtu visu pakotnē iekļauto vaicājumu rezultātu, ir jāizmanto pieprasījuma objekta metode “ExecutePackage”, nevis “Run”. Šī metode izpilda visus pieprasījumus secīgi. Vaicājuma rezultāts ir rezultātu masīvs katram pakotnes vaicājumam, un izvietojuma secība masīvā ir tāda pati kā vaicājumu secība pakotnes tekstā.

Apsverot vaicājumu valodu, ir vērts pieminēt tādu funkciju kā virtuālās tabulas. Virtuālās tabulas nav atrodamas datu bāzē, tās ir sava veida iesaiņojums, kas tiek izpildīts DBVS pusē kā vaicājums, izmantojot apakšvaicājumus. 1C vaicājuma piemērs, izmantojot virtuālās tabulas:

SELECT ReģistrsSaistībasApgrozījums.Atbildība AS Atbildība no ReģistraUzrājumi.ReģistrsSaistības.Apgrozījums() AS ReģistrsSaistībasApgrozījums

Šāds vaicājums DBVS izskatītos šādi:

SEL ECT T1.Fld25931RRef FR OM (SELECT T2._Fld25931RRef AS Fld25931RRef, CAST(SUM(T2._Fld25936) AS NUMERIC(38, 8)) AS Fld25936Apgrozījums(_SERIUM_, CAST27, CAST3) 8) ) AS Fld25937Apgrozījums_ FR OM dbo._AccumRgTn25938 T2 WH ERE ((T2._Fld949 = @P1)) AND ((T2._Fld25936 @P2 VAI T2._Fld25937 @P3)) T2._Fld2 ) 5936 ) KĀ SKAITS(38, 8))) 0.0 VAI (CAST(SUM(T2._Fld25937) AS NUMERIC(38, 8))) 0.0) T1>>>>

Var redzēt, ka tas neizskatās pēc SQL, jo ir apakšvaicājums, grupēšana. Virtuālās tabulas kopumā ir “sintaktiskais cukurs”, tas ir, tās kopumā ir izveidotas vaicājumu izstrādes ērtībām, lai vaicājumi būtu kompaktāki un lasāmāki.

Tikai reģistros ir virtuālās tabulas, bet kuras virtuālās tabulas ir pieejamas reģistrā, var redzēt vaicājumu noformētājā.



Lietojot virtuālās tabulas, vienmēr ir jānodrošina atlases nosacījums. Pretējā gadījumā var rasties veiktspējas problēmas.



Pieprasījuma pamattekstā tas izskatās šādi:

Uzkrāšanas reģistrs Apgrozījumu (, Operation = &Operation) AS Saistību reģistrs

Vaicājumu rakstīšanas ērtībai, tas ir, vaicājuma tekstu izveidei, 1C ir konstruktors, kuru var izsaukt, izmantojot konteksta izvēlni (peles labā poga):



Vaicājumu noformētājā varat redzēt pilnu atbalstīto vaicājumu valodas funkciju un operatoru sarakstu.


Vaicājumu veidotājs ir ļoti elastīgs vizuālais rīks jebkuras sarežģītības vaicājumu izveidei. Tas ir pieejams tikai konfiguratora režīmā. Uzņēmuma režīmā ir tā sauktā “Vaicājumu konsole” - tā ir ārēja apstrāde, kas tiek piegādāta ITS diskā. Pārvaldītai lietojumprogrammai vaicājumu konsoli var lejupielādēt no vietnes its.1c.ru.

Apraksts par darbu vaicājumu noformētājā ir ārpus šī raksta darbības jomas, tāpēc tas netiks detalizēti apspriests.

Neoptimālas vaicājuma veiktspējas iemesli

Zemāk ir saraksts ar galvenajiem iemesliem (bet ne visiem), kas noved pie lēnas vaicājuma izpildes.

  • Savienojumu izmantošana ar apakšvaicājumiem

Nav ieteicams veikt savienošanu ar apakšvaicājumiem, ir jāaizstāj ar pagaidu tabulām. Apakšvaicājumu savienošana var izraisīt ievērojamus veiktspējas zudumus, un vaicājumu izpildes ātrums dažādās DBVS var ievērojami atšķirties. Šādu vaicājumu izpildes ātrums ir jutīgs arī pret DBVS statistiku. Šādas uzvedības iemesls ir tas, ka DBVS optimizētājs ne vienmēr var pareizi noteikt optimālo vaicājuma izpildes plānu, jo optimizētājs neko nezina par to, cik rindu apakšvaicājums atgriezīs pēc tā izpildes.

  • Virtuālo tabulu izmantošana vaicājumu savienojumos

Virtuālās tabulas DBVS līmenī tiek izpildītas kā apakšvaicājumi, tāpēc iemesli ir tādi paši kā pirmajā rindkopā.

  • Nosacījumu izmantošana vaicājumā, kas neatbilst esošajiem indeksiem

Ja pieprasījuma nosacījumos (operatorā KUR vai virtuālās tabulas nosacījumi) izmanto laukus, kas nav visi iekļauti indeksā, šis vaicājums tiks izpildīts, izmantojot SQL konstrukcijas tabulas skenēšanu vai indeksa skenēšanu (pilnībā vai daļēji). Tas ietekmēs ne tikai vaicājuma izpildes laiku, bet arī pārmērīga S bloķēšana tiks ievietota papildu rindās, kas savukārt var izraisīt bloķēšanas eskalāciju, tas ir, visa tabula tiks bloķēta.

  • VAI izmantošana vaicājuma nosacījumos

Izmantojot loģisko operatoru VAI dizainā KUR var izraisīt arī tabulas skenēšanu. Tas notiek tāpēc, ka DBVS nevar pareizi izmantot indeksu. Tā vietā VAI jūs varat izmantot dizainu VISU APVIENOT.

  • Datu saņemšana, izmantojot punktu, saliktā tipa laukiem

Nav ieteicams iegūt vērtības ar punktu (konstrukcijā IZVĒLIES KUR), jo, ja objekta atribūts izrādīsies sarežģīts tips, savienojums notiks ar katru tabulu, kas iekļauta šajā sarežģītajā tipā. Rezultātā DBVS vaicājums būs ievērojami sarežģītāks, kas var liegt optimizētājam izvēlēties pareizo vaicājuma izpildes plānu.

1C Enterprise platforma ļauj vienlaikus izpildīt vairākus vaicājumus secīgi. 1C to sauc par pieprasījuma pakotni. Vienas pakotnes ietvaros katrs pieprasījums ir atdalīts ar semikolu.

Lai pakotnē panāktu vaicājumu pakāpenisku izpildi, parasti sākotnēji tiek izveidotas pagaidu tabulas, pēc tam tiek izveidoti to koplietošanas nosacījumi, piemēram, filtri, pievienošanās un savienības. Pateicoties tam, tiek sasniegts gala rezultāts. Pagaidu tabulas, kas iegūtas jebkuru vaicājumu rezultātā paketē, turpina pastāvēt līdz paketes beigām kopumā vai līdz tiek izpildīts vaicājums, kas iznīcina pagaidu tabulas.

Turklāt pakešu vaicājumu un pagaidu tabulu izmantošana ievērojami palielina visa šī koda segmenta lasāmību. Sarežģītus vaicājumus, kas satur arī ligzdotus vaicājumus, var būt ļoti grūti saprast. Tomēr, ja jūs sadalāt garu sarežģītu vaicājumu vairākos un pat izmantojat pagaidu tabulas, tas ne tikai uzlabos uztveri, bet vairumā gadījumu palielinās veiktspēju.

Vēl viena svarīga detaļa par labu pakešu vaicājumiem 1C ir tā, ka atšķirībā no tā, mēs varam atsevišķi iegūt katra partijas vaicājuma rezultātu.

Pieprasījumu paketes izveides piemērs 1C valodā

Lai skatītu piemēru, kā izveidot vaicājumu paketi, mēs izmantosim vaicājumu noformētāju, kuru skaidrības labad izsauksim no vaicājumu konsoles. Tādējādi mēs uzreiz varam redzēt pakotnes izpildes rezultātu.

Izveidosim vienkāršu pakešu pieprasījumu. Es iesaku nekavējoties ievietot pieprasījuma tekstu un pēc tam to atvērt un redzēt, kā tiek veidota pieprasījumu pakete. Pievienojiet jaunu pieprasījumu konsolei un ielīmējiet šādu tekstu:

Saņemiet 267 video nodarbības 1C bez maksas:

Pašpietiekama saite.
Pašpietiekams. Vecāki,
Pašpietiekams kods.
Pašpietiekams ātrās atlases kods.
Pašpietiekams vārds,
Pašpietiekams. Tips,
Pašpietiekams ārpusbilances,
Pašpietiekams, kvantitatīvs.
NO
Kontu plāns Self-supporting AS Self-supporting
KUR
Pašpietiekams.Link = &Konts
;
////////////////////////////////////////////////////////////////////////////////

IZVĒLIES
Pašnesošie veidiSubconto.Line Number AS rindas numurs,
Pašatbalstoši Subconto.ViewSubconto AS tipsSubconto veidi,
Self-supportingTypesSubconto.TypeSubconto.Name AS nosaukums,
Self-supportingTypesSubconto.TypeSubconto.ValueType ASValueType,
Self-supportingTypesSubconto.OnlyTurnover AS OnlyApgrozījums,
Self-supportingTypesSubconto.Summary AS Summative
NO
Apakškontu veidi AS Pašuzskaites veidi
KUR
Self-supportingTypesSubaccount.Link = &Konts
KĀRTOT PĒC
Pašpietiekams TypesSubconto.NumberLines

Man tas izskatās šādi:

Tagad pāriesim pie vaicājumu noformētāja. Šeit mūs interesēs cilne “Pieprasīt paketi”:

Kā redzat, mums ir divu pieprasījumu pakete. Veicot dubultklikšķi uz jebkura no tiem, varat turpināt to rediģēt:

Noklikšķiniet uz pogas “Labi” un mēģiniet redzēt pakešu pieprasījuma rezultātu.

Iestatīsim parametru "Konts". Kontu plānā varat izvēlēties jebkuru kontu. Kā jūs droši vien jau uzminējāt, šai pieprasījumu pakotnei ir jāsaņem konta rekvizīti. Noklikšķiniet uz "Palaist" un skatiet rezultātu:

Metodes Run() un RunBatch()

1C GOODWILL uzņēmuma emuārs

1C Enterprise platforma ļauj vienlaikus izpildīt vairākus vaicājumus secīgi. 1C to sauc par pieprasījuma pakotni. Vienas pakotnes ietvaros katrs pieprasījums ir atdalīts ar semikolu.

Lai pakotnē panāktu vaicājumu soli pa solim izpildi, parasti sākotnēji tiek izveidotas pagaidu tabulas, pēc tam tiek izveidoti to koplietošanas nosacījumi, piemēram, filtri, pievienošanās un pievienošanās. Pateicoties tam, tiek sasniegts gala rezultāts. Pagaidu tabulas, kas iegūtas jebkuru vaicājumu rezultātā paketē, turpina pastāvēt līdz paketes beigām kopumā vai līdz tiek izpildīts vaicājums, kas iznīcina pagaidu tabulas.

Turklāt pakešu vaicājumu un pagaidu tabulu izmantošana ievērojami palielina visa šī koda segmenta lasāmību. Sarežģītus vaicājumus, kas satur arī ligzdotus vaicājumus, var būt ļoti grūti saprast. Tomēr, ja jūs sadalāt garu sarežģītu vaicājumu vairākos un pat izmantojat pagaidu tabulas, tas ne tikai uzlabos uztveri, bet vairumā gadījumu palielinās veiktspēju.

Vēl viena svarīga detaļa par labu pakešu vaicājumiem 1C ir tā, ka atšķirībā no ligzdotajiem vaicājumiem mēs varam atsevišķi iegūt katra vaicājuma rezultātu grupā.

Pieprasījumu paketes izveides piemērs 1C valodā

Lai redzētu piemēru, kā izveidot vaicājumu pakotni, mēs izmantosim vaicājumu noformētāju, ko skaidrības labad izsauksim no vaicājumu konsoles. Tādējādi mēs uzreiz varam redzēt pakotnes izpildes rezultātu.

Izveidosim vienkāršu pakešu pieprasījumu. Es iesaku nekavējoties ielīmēt pieprasījuma tekstu konsolē un pēc tam atvērt konstruktoru un redzēt, kā tiek veidota pieprasījuma pakotne. Pievienojiet jaunu pieprasījumu konsolei un ielīmējiet šādu tekstu:

Pašpietiekams. Vecāki,

Pašpietiekams kods.

Pašpietiekams ātrās atlases kods.

Pašpietiekams vārds,

Pašpietiekams. Tips,

Pašpietiekams ārpusbilances,

Pašpietiekams, kvantitatīvs.

Kontu plāns Self-supporting AS Self-supporting

////////////////////////////////////////////////////////////////////////////////

Pašnesošie veidiSubconto.Line Number AS rindas numurs,

Pašatbalstoši Subconto.ViewSubconto AS tipsSubconto veidi,

Self-supportingTypesSubconto.TypeSubconto.Name AS nosaukums,

Self-supportingTypesSubconto.TypeSubconto.ValueType ASValueType,

Self-supportingTypesSubconto.OnlyTurnover AS OnlyApgrozījums,

Self-supportingTypesSubconto.Summary AS Summative

Apakškontu veidi AS Pašuzskaites veidi

KĀRTOT PĒC

Pašpietiekams TypesSubconto.NumberLines

Man tas izskatās šādi:

Tagad pāriesim pie vaicājumu noformētāja. Šeit mūs interesēs cilne “Pieprasīt paketi”:

Kā redzat, mums ir divu pieprasījumu pakete. Veicot dubultklikšķi uz jebkura no tiem, varat turpināt to rediģēt:

Noklikšķiniet uz pogas “Labi” un mēģiniet redzēt pakešu pieprasījuma rezultātu.

Iestatīsim parametru "Konts". Kontu plānā varat izvēlēties jebkuru kontu. Kā jūs droši vien jau uzminējāt, šai pieprasījuma pakotnei ir jāsaņem konta rekvizīti. Noklikšķiniet uz "Palaist" un skatiet rezultātu:

Metodes Run() un RunBatch()

Papildus metodei Execute(), kas pa vienam izpildīs visus pieprasījumus sērijā un atgriezīs pēdējā pieprasījuma rezultātu, 1C ir ExecuteBatch() metode. Tas atgriež katra partijas pieprasījuma paraugu masīvu. Iepriekš minētajā piemērā šī ir tieši šī metode.

ArrayResults = Query.ExecuteBatch();

Selection1 = ArrayResults.Select();

Ja Select1.Next() Tad

//Darbības ar atlasi 1

endIf;

SelectionViewsSubconto = ArrayResults.Select();

Ziņa Darbs ar pakešu pieprasījumiem versijās 1C 8.3 un 8.2 pirmo reizi parādījās uzņēmuma 1C GOODWILL emuārā.

tie stipri palielina lasāmību, kas samazina kļūdu iespējamību => ar to vien man pietiek.

1C:Enterprise versijas 8.0 iebūvētajai vaicājumu valodai nebija iespējas izmantot pagaidu tabulas un rakstīt pakešu vaicājumus. Tajā pašā laikā bieži bija jāveic sarežģīti aprēķini viena pieprasījuma ietvaros (tas ir, viens mijiedarbības cikls starp klientu - 1C:Enterprise serveris - DBVS serveris). Lai atrisinātu šādas problēmas, tika izmantoti apakšvaicājumi – izsaukumi nevis uz metadatu objektiem, bet gan uz atlasēm no šiem objektiem. Parasti apakšvaicājumi tika veikti ar grupēšanu un bieži tika izmantoti savienojumos.

DBVS servera optimizētājs (neatkarīgi no tā, kuru DBVS izmantojat) ne vienmēr var pareizi optimizēt šādu vaicājumu. Šajā gadījumā optimizētāja problēma ir pareizā savienojuma metodes izvēle. Ir vairāki algoritmi divu paraugu savienošanai. Viena vai otra algoritma izvēle ir atkarīga no tā, cik ierakstu būs vienā un otrā paraugā. Ja jūs savienojat divas fiziskas tabulas, DBVS var viegli noteikt abu paraugu lielumu, pamatojoties uz pieejamo statistiku. Ja viena no pievienotajām atlasēm ir apakšvaicājums, kļūst ļoti grūti saprast, cik ierakstu tā atgriezīs. Šajā gadījumā DBVS var kļūdīties, izvēloties plānu, kas izraisīs katastrofālu vaicājuma veiktspējas kritumu.

Vaicājuma pārrakstīšana, izmantojot iepriekš minēto metodi, ir paredzēta, lai vienkāršotu DBVS optimizētāja darbu. Pārrakstītajā vaicājumā visas atlases, kas piedalās savienojumos, būs fiziskas tabulas, un DBVS varēs viegli noteikt katras atlases lielumu. Tas ļaus DBVS izvēlēties ātrāko no visiem iespējamiem plāniem. Turklāt DBVS veiks pareizo izvēli neatkarīgi no apstākļiem. Šādā veidā pārrakstīts vaicājums vienlīdz labi darbosies jebkurā DBVS, kas ir īpaši svarīgi, izstrādājot aprites risinājumus. Turklāt šādi pārrakstīts vaicājums ir labāk lasāms, vieglāk saprotams un atkļūdojams.

Jāsaprot, ka šādi pārrakstot vaicājumu, iespējams, esam tajā ieviesuši zināmu palēnināšanos papildu pieskaitāmās izmaksas - pagaidu tabulu izveides dēļ. Ja DBVS nekļūdās, izvēloties plānu, iespējams, tā izpildīs veco vaicājumu ātrāk nekā jauno. Tomēr šī palēnināšanās vienmēr būs ārkārtīgi maza. Palēnināšanās lielums ir atkarīgs no izmantotās DBVS un aparatūras veiktspējas. Tipiskā gadījumā vienas pagaidu tabulas izveide var aizņemt vairākas milisekundes. Tas nozīmē, ka šiem palēninājumiem nevar būt ievērojama ietekme uz sistēmas veiktspēju, un, kā likums, tos var ignorēt.