Mehanizem ločevanja podatkov 1s. Uporaba mehanizma za skupno rabo podatkov namesto RLS

Pozor! Tukaj je poskusna različica lekcije, katere gradivo morda ni popolno.

Prijavite se kot študent

Za dostop do šolske vsebine se prijavite kot študent

Notranji programski jezik 1C 8.3 za programerje začetnike: format v 1C

Pri programiranju v 1C morate pogosto prikazati (v istih poročilih) vrednosti različnih vrst (nizi, datumi, številke ...). Vsaka od vrednosti ima različne predstavitve.

Na primer, isti datum "01/01/2005" je lahko predstavljen kot niz kot:

  1. "01.01.2005"
  2. "1. januar 2005"
  3. "01.01.05"

Vse so nizovne predstavitve iste vrednosti. za oblikovanje katerega se v 1C uporablja posebna funkcija Oblika.

Uporaba funkcije Format v 1C

Onemogoči združevanje števk

Recimo, da želimo natisniti število 10000.

Če napišemo:

Formatni niz je na splošno sestavljen iz dveh delov, ločenih z enačajem. Levo od enakovrednosti je ime parametra, ki ga nastavljate (glejte pomoč ali primere), desno pa je vrednost tega parametra.

V zgornjem primeru ima niz zapisa »NG=0« parameter NG in vrednost 0. Ta kombinacija razdruži števke števila. In kot lahko vidite, je zdaj prikazano 10000.

Odstranjevanje začetnih ničel

Pogosta naloga je tudi izpis začetnih ničel pred števko. Na primer, recimo, da želite prikazati številko 5 z začetno ničlo, to je v obliki "05":

Poročilo(Format(5 , "FH=2; FH=" ) ) ; // izhodi 05

Razčlenimo formatni niz "FZ=2; HVN=". Sestavljen je iz dveh formatnih nizov, ločenih s podpičji. Analizirajmo vsakega od njih posebej.

Vrstica "CHT=2" nastavi skupno število prikazanih decimalnih mest za cele in ulomke. Tako bo skupno število mest, ki jih bo število zasedlo pri izpisu, enako 2.

Niz "HVN=", kot izhaja iz pomoči, nakazuje funkciji formata, da če številka ne doseže deklarirane dolžine v dolžini (kot v našem primeru, ker smo navedli 2 položaja, 5 pa zaseda samo eno), potem uporabiti je treba vodilne ničle. Posebnost tega formatnega niza je, da ima le ime parametra in enačaj, nima pa vrednosti. Berete poskusno različico lekcije, najdete celotne lekcije.

Kombinacija dveh formatnih nizov nam da rezultat, ki ga potrebujemo "05", namesto "5".

Spremenite decimalno ločilo

Recimo, da moramo ulomke prikazati z ločilom z zvezdico namesto s piko. To pomeni, da je 25,46 prikazano kot "25 * 46":

Oblikovni niz je parameter DF in vrednost dddd, ki označuje funkcijo Oblika izpiše dolgo predstavitev dneva v tednu (upoštevajte, koliko "d" vsebuje).

Mesečna predstavitev datuma

Opis meseca po datumu je prikazan na naslednji način:

Poročilo (Oblika ("20050101" , "DF=MMMM" ) ); // natisne januar

Oblikovni niz ima enak parameter DF kot v prejšnjem primeru. Toda pomen je drugačen. Zdaj je MMMM.

Opravite test

Začni test

1. Format("19050505", "DF=MMMM") bo vrnjen

2. Oblikujte niz tako, da ločilo decimalnih in celih števil spremenite v ^

3. Da funkcija Format vrne "00005" namesto 5, je niz formata primeren

4. Če želite, da funkcija Format vrne "10000" namesto 10.000, bo zadostoval formatni niz

5. Funkcija Format vrne vrednost vrste

Mehanizem za izmenjavo podatkov omogoča shranjevanje podatkov več neodvisnih organizacij v eni informacijski bazi.

To postane mogoče zaradi dejstva, da se skupni atributi konfiguracijskih objektov lahko uporabljajo ne samo kot "isti atribut, ki ga imajo vsi objekti", ampak tudi kot identifikator, da podatki pripadajo enemu od več neodvisnih področij. To lahko razložimo z naslednjim primerom.

Recimo, da je v konfiguraciji skupni atribut "Organizacija". To pomeni (poenostavljeno), da bo imel vsak imenik, dokument ali drug konfiguracijski objekt tudi atribut "Organizacija".

Hkrati ima vsak uporabnik informacijske baze dostop do vseh podatkov, shranjenih v tej bazi podatkov, ne glede na to, katera organizacija je navedena, na primer v določenem dokumentu.

Zdaj pa določimo, da bo skupni atribut "Organizacija" ločilo.

Nato bo (poenostavljeno) v informacijski bazi ustvarjenih več neodvisnih podatkovnih področij, od katerih bo vsako hranilo podatke samo za eno določeno organizacijo:

Zdaj uporabnik z vstopom v program ne bo dobil dostopa do vseh informacij, ki so v informacijski bazi, temveč le do podatkov "svojega" področja, v tem primeru do dokumentov, imenikov itd. njegove organizacije.

Možna je tudi druga različica uporabe tega mehanizma, ko je v informacijski bazi več neodvisnih podatkovnih področij in poleg tega obstajajo podatki, ki so na voljo vsem uporabnikom programa. Vsebujejo na primer imenik bank, ki je enak za vse organizacije.

V tem primeru ima uporabnik dostop do »svojega« podatkovnega področja in do nedeljenega podatkovnega področja, ki je skupno vsem uporabnikom.

Mehanizem izmenjave podatkov je precej prilagodljiv in univerzalen:

  • omogoča uporabo ne enega, ampak več ločil;
  • obstajajo različni načini uporabe skupnih podatkov; razlikujejo se v tem, kako se obravnava situacija, ko vrednost ločila ni podana;
  • uporabo skupnega atributa kot ločila je mogoče nadzorovati med delovanjem programa iz vgrajenega jezika brez spreminjanja konfiguracije; to se imenuje pogojna delitev.

[Gumb 7710967300 BUX RB] Connect=Srvr="%servername%";Ref="%base_name%"; Dodatni parametri=/Z "-0,-0,+7710967300";

Za /Z podajamo splošne podrobnosti po vrstnem redu. Ker ima naše standardno računovodstvo že dva skupna sistemska podatka, jima določimo vrednost -0, da se ne uporabljata, kot tretjega (ki smo ga ustvarili) pa posredujemo TIN.

1000 in 1 potrditveno polje

Zdaj morate določiti, kateri del podatkov bo skupen vsem področjem. Vse to se nastavi prek konfiguratorja. V lastnostih splošnih rekvizitov, ki smo jih pravkar ustvarili, je postavka »Sestava«, ki odpre majhen seznam 800 parametrov:

Izbiro parametrov prepuščamo vaši presoji, presoji in okolju. Tukaj je naša različica (bodite previdni, ima 20.000 slikovnih pik).

Ločevalnik omogoča tudi nastavitev ločenega seznama uporabnikov za vsako bazo - to vam lahko pride prav, če imate na stotine uporabnikov - ko vnesete določeno bazo, vam po tem seznamu ni treba listati do krvavih žuljev. Tega ne uporabljamo, ker imamo nastavljeno transparentno avtorizacijo.

Nalaganje podatkov iz trenutnih baz podatkov

Za nalaganje podatkov iz trenutnih podatkovnih baz uporabljamo univerzalno izmenjavo XML. Ne morete samo vzeti in raztovoriti baze, morate nastaviti pravila izmenjave, sicer lahko med nalaganjem (in se bodo zagotovo pojavile) napake in konflikti, druga baza pa preprosto ne bo prilezla skozi. Spomnimo se, da razdelimo osnovna območja za vsako organizacijo in v našem primeru takšna pravila izmenjave delujejo. Če se odločite za drugo ločilo, boste morali uporabiti možgane in potrditvena polja. Glavna stvar je, da ne uporabljate standardnega raztovarjanja - to bo vodilo do podvajanja vseh vnaprej določenih zapisov.

Opomba gostiteljici: imenike in dokumente je bolje naložiti ločeno - tako se lahko izognete nepotrebnim napakam pri nalaganju.

Nalaganje podatkov v skupno bazo podatkov

Zaženemo 1C s parametrom / Z "-0, -0, +% vaš ločilo%", ki označuje ločilo organizacije, katere podatke bomo prenesli. Zaženemo univerzalno izmenjavo in ji dodamo datoteke, prejete med nalaganjem: najprej imenike, nato dokumente. To operacijo ponovimo za vsako osnovno površino.

Za poenostavitev naloge izvedemo nalaganje v velikem obsegu, potem ko zaženemo rahlo popravljeno standardno obdelavo prek ukazne vrstice (/Execute c:\upload.epf). Nato prejete datoteke ročno naložimo v skupno bazo podatkov.

Kako porabiti več časa, da bi porabili manj časa

Postopek ločitve ni hiter. Spomnimo se, da imamo zdaj več kot 500 organizacij, vendar smo jih v nekaj tednih uspeli deliti le 70. Zagotovo pa vemo, da se bomo v šestih mesecih zahvaljevali sebi za opravljeno delo in veliko prihranjenega časa in trud.

Računovodje ne opazijo prehoda organizacij iz redne baze v razdeljeno, za njih je proces neboleč. Butt burns samo za admine :)

Stranski učinki: prihranek prostora 1 proti 20, posredno povečanje hitrosti – neprecenljivo. V absolutnem znesku 50 organizacij zavzame 2 GB prostora v SQL, medtem ko ena posamezna baza podatkov zavzame 800 MB.

Obljubljena muha v mazlu, celo štiri:

  • če je eden od uporabnikov pokvaril podatke v eni organizaciji, morate povrniti celotno razdeljeno bazo podatkov - ne morete samo vzeti in vrniti nazaj enega podatkovnega področja
  • morate temeljiteje testirati posodobitve, zlasti tiste, ki dodajajo ali spreminjajo imenike
  • če morate bazo prenesti na stranko (ali združiti davčno :), morate storiti obratni postopek: razbremenite organizacijo iz razdeljene baze z univerzalno izmenjavo, nato jo naložite v prazno navadno bazo in shranite iz to za. dt datoteka
  • v razdeljeni bazi podatkov ni mogoče upravljati načrtovanih opravil (npr. ne bo mogoče samodejno posodabljati menjalnih tečajev)
Prve tri žlice niso tako grenke – samo poskrbijo, da smo bolj pozorni. Kaj pa s četrtim, še ne vemo, a pridno raziskujemo.

Ločevalni element 1C je potreben za prerazporeditev območij obrazca, saj je trenutno primeren za uporabnika. Skoraj vsak uporabnik sistema Windows zna uporabljati ločila. Recimo, da ste ustvarili preprost obrazec z dvema kontrolnikoma.

Tradicionalno se lahko elementi katerega koli seznama nahajajo na levi strani. Na desni strani je podrobna specifikacija prav teh točk. Če je levi seznam sestavljen iz kratkih imen, je logično, da ta stolpec zmanjšate na minimum. Skladno s tem se bo v tem primeru povečala berljivost desne strani. In obratno, če so na levi strani dolga imena, je treba stolpec razširiti. Razdelilniki omogočajo uporabniku poljubno prilagajanje oblike s preprostim vlečenjem obrobe z miško.

Ta način nadzora se uporablja pri urejanju tabel v Wordu in Excelu. Ko ustvarjate obrazec, lahko ustvarite element obrazca z navpičnim in vodoravnim ločilom. Na splošno je najbolj zaželeno ustvariti oblike, ki so vizualno znotraj zaslona.

Ločilo 8.2, 8.3 (upravljani obrazci)

V upravljanem obrazcu 1c ne morete dodati ločila, samodejno ga doda program pred/za poljem tabele

1. Preambula.

Pojavila se je potreba po organizaciji računovodstva za dve organizaciji v enem IS. Situacija ni edinstvena, vendar se je zgodilo, da je naš zelo neobičajen 250 GB UPP deloval precej počasi, zato smo se namesto RLS odločili poskusiti z ločevanjem podatkov. Kaj to je, je opisano npr., oz. Skratka, če RLS pogojuje poizvedbe SQL, potem je ločilo podatkov dodaten stolpec v tabelah na ravni DBMS, pri čemer bi moral biti mehanizem ločila hitrejši od RLS.

Torej, v podatkovni zbirki, kjer so se vodili zapisi za OOO št. 1, je treba prenesti podatke iz ločene baze podatkov OOO št. 2 in organizirati skupno delo. Tako kot na sliki:

Navadni smrtniki delajo samo s svojim LLC, glavni računovodja pa včasih pogleda podatke o dveh pravnih osebah. V načinu dostopa do obeh LLC-jev lahko samo berete podatke, zato mora imeti glavni računovodja možnost interaktivnega preklapljanja med načinoma »preberi vse« / »zapiši samo za eno organizacijo« in izberite LLC (tj. nastavite vrednost skupni atribut) za izvedbo na primer izračuna stroškov.

2. Izvedba

Platforma 8.2.19.90, ni načina združljivosti. DBMS - MSSQL Server 2008 R2 Standard.

Ustvarili smo skupni atribut Organisation Separator tipa "številka", se strinjali s predlogom za ustvarjanje parametrov seje, izpolnili sestavo atributa (vključuje več imenikov, vse dokumente, akumulacijske, računovodske in obračunske registre). Ločevanje podatkov - "Samostojno in skupno". Vrednost parametra seje se nastavi iz privzetih uporabniških nastavitev v postopku SetSessionParameters v modulu seje:

Organizacija = UserManagement.GetDefaultValue(glCurrentUser,"MainOrganization");
SessionParameters.OrgDelimiterValue = Organizacija.DelimiterValue;

V vmesniku glavnega računovodje so naredili obrazec z možnostjo preklapljanja med organizacijami in omogočanja / onemogočanja načina ločevanja:

Ko je razdelitev onemogočena, ko je SessionParameters.OrganizationSeparatorUse = False, platforma noče pisati dokumentov in vrže napake, kot je »Napaka SDBL: pričakovani izraz (pos=12)«, zato uporabniku ne morete dovoliti pisanja dokumentov v tej možnosti. Zaradi zanesljivosti smo ustvarili naročnine na dogodek "Pred snemanjem" za objekte, ki so del skupnega atributa:

If SessionParameters.OrgDelimiterUse = False Potem
#If Client Potem
Opozorilo ("Ne morem pisati, ker je deljenje podatkov onemogočeno!");
#EndIf
Zavrnitev = res;
EndIf;

Naš akcijski načrt je bil naslednji: pripravimo konfiguracijo sprejemnika IB št. 1, zapišemo vrednosti skupnega atributa = 1, naložimo podatke iz IB št. 2, po nalaganju za vse objekte s praznim (enako 0) vrednost ločila, nastavite ločilo organizacije = 2.

Konfiguracija je bila pripravljena, pojavilo se je vprašanje, kako nastaviti vrednost splošnega atributa za dokumente in njihove premike v zaprtih obdobjih ter hitro in brez tveganja, da bodo številke v bilanci letele? Skozi objektni model 1C je nemogoče napisati ločilo ločeno od predmeta, zato sem moral prekiniti licenčno pogodbo, da sem prišel ven in napisal poizvedbo za MS SQL. Ker je v skupnem atributu veliko objektov, v ličniku za te objekte pa je še več tabel, smo napisali procesiranje, ki generira poizvedbo za SQL (za vsak metapodatkovni objekt, ki je del ločila, smo zapisali "posodobi" + DB_name + ".dbo._" + TableName + " set _" + Field GeneralAttribute + " = 1";)

Vrednost je bila nastavljena, del podatkov je bil prenesen iz IB št. 2 in začelo se je testiranje.

Rezultat je bil razočaran. Prvič, težave z računovodskim registrom. Ko je ločevanje omogočeno, analitika ni vidna:

To je posledica dejstva, da je računovodski register na ravni DBMS shranjen kot več tabel in vse tabele niso imele vrednosti skupnega atributa (za ogled strukture je bila uporabljena obdelava).


No, vpišemo vrednost ločila prek MS SQL, vidimo analitiko. Zdaj poročila ne delujejo. Izkazalo se je, da obstajajo težave s poizvedbami v virtualnih tabelah računovodskega registra "Promet" in "PrometDtKt":

(Fld27033 je samo pogost atribut v tabeli računovodskega registra)

Ločilo je nastavljeno v vseh tabelah, to se vidi na ravni DBMS, kaj bi lahko bila napaka, ni jasno. Razmestimo tipičen prazen SCP, izvedemo zgoraj opisane konfiguracijske spremembe, vnesemo nekaj dokumentov (pri tej možnosti platforma sama nastavi vrednost ločila v vseh tabelah računovodskega registra), vendar se napake reproducirajo. Slabo je, vendar računovodske registre izločimo iz splošnih potrebščin, nadaljujemo s testiranjem.

Nadalje se izkaže, da je mehanizem premika za računske registre prenehal delovati. Načrtov nismo ločevali po vrstah obračunov, težavo skušamo iskati v tabelah obračunskega registra in v preračunih. Preverjamo, vpisujemo vrednost glavnega atributa, izvajamo T&I - brez uspeha.

Ob tem diagnosticiramo težavo pri zapisovanju informacij v neodvisne registre iz obrazca seznama. V tem primeru so podatki zabeleženi, vidni pa so po ponovnem zagonu. Težava je reproducirana na testni osnovi:


Informacijskih registrov ni bilo mogoče "popraviti" z manipulacijo SQL (vrednost ločila je nastavljena v vseh tabelah), zato so bili preprosto izločeni iz splošnega atributa. Po večdnevnem eksperimentiranju so neuspešni tudi poskusi obnovitve delovne sposobnosti odmika.

Na tej točki se odločimo, da izklopimo skupno rabo podatkov in še vedno uporabljamo RLS. Pri nastavitvi delitve na "ne uporabljaj" naletimo na napake "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX prekinjeno, ker je bil za indeks najden podvojen ključ...". To pomeni, da se ni tako enostavno vrniti v stanje pred ločitvijo. Težava z indeksi preračunskih tabel, nastavitvami za shranjevanje vsot in drugo. Dejstvo je, da so v tabelah shranjene enake vrstice, ki se razlikujejo le po vrednosti skupnega atributa. Pri brisanju skupnega atributa se prikažejo neenolični vnosi. Nepotrebne zapise boste morali brisati direktno v MS SQL, nekako takole (za tabelo preračunavanja):

usebase;
ALTER TABLE_CRgRecalc1399
ADD id INT IDENTITY(1,1);
POJDI
IZBRIŠI FROM_CRgRecalc1399
KJE id< (SELECT MAX(id)
IZ _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef in
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] in
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] in
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] in
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] in
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
POJDI
ALTER TABLE_CRgRecalc1399
DROP COLUMN id;

In šele po čiščenju več deset tabel je mogoče izklopiti particioniranje podatkov. Po izklopu ločitve ni težav.

3. Sklepi.

Bilo je upanje, da so težave 8.3 rešene. Nismo bili preveč leni, preverili smo na 8.3.4.482 (z onemogočenim načinom združljivosti). Ogledali smo si skoraj tipično SCP-shke, s spremembami v konfiguraciji samo za splošne rekvizite. Na tej testni bazi je bilo razdeljevanje omogočeno pred vnosom informacij, tj. platforma je morala pravilno zapisati vrednost ločila v vse tabele, sami niso ničesar zapisali neposredno v MS SQL.

rezultat:

    Reproduciran je problem s poizvedbami v virtualnih tabelah "Promet" in "PrometDtKt".

    Problem predhodne uporabe je ponovljiv.

    Reproducira se problem vpisovanja v neodvisne registre informacij.

    Težava z izklopom ločitve - z enim klikom na gumb se je ne bo mogoče znebiti!

Tako nam ni uspelo zamenjati RLS z novim mehanizmom. Ta mehanizem je bil očitno zasnovan za storitve v oblaku in v primeru uporabe skupnih podatkov "neodvisno" bo morda ločitev delovala, vendar potrebujemo skupni NSI. Ostaja še počakati, da 1C popravi napake in še bolje implementira tipičen mehanizem za delitev po organizacijah v standardnih konfiguracijah.



Povezani članki: