Mekanizmi i ndarjes së të dhënave 1s. Përdorimi i Mekanizmit të Ndarjes së të Dhënave në vend të RLS

Kujdes! Këtu është një version provë i mësimit, materialet e të cilit mund të mos jenë të plota.

Hyni si student

Identifikohu si student për të hyrë në përmbajtjen e shkollës

Gjuha e brendshme e programimit 1C 8.3 për programuesit fillestar: formati në 1C

Kur programoni në 1C, shpesh duhet të shfaqni (në të njëjtat raporte) vlera të llojeve të ndryshme (vargjet, datat, numrat ...). Secila prej vlerave ka paraqitje të ndryshme.

Për shembull, e njëjta datë "01/01/2005" mund të përfaqësohet si një varg si:

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

Ato janë të gjitha paraqitje të vargjeve me të njëjtën vlerë. për formimin e të cilave në 1C përdoret një funksion i veçantë Formati.

Përdorimi i funksionit Format në 1C

Çaktivizo grupimin e shifrave

Supozoni se duam të shtypim numrin 10000.

Nëse shkruajmë:

Vargu i formatit në përgjithësi përbëhet nga dy pjesë të ndara me një shenjë të barabartë. Në të majtë të barazimeve është emri i parametrit që vendoset (shikoni ndihmën ose shembujt), dhe në të djathtë është vlera e këtij parametri.

Në shembullin e mësipërm, vargu i formatit "NG=0" ka parametrin NG dhe vlerën 0. Ky kombinim çgrupon shifrat e numrit. Dhe siç mund ta shihni, tani shfaqet 10000.

Heqja e zerave kryesore

Është gjithashtu një detyrë e zakonshme nxjerrja e zerave kryesore përpara një shifre. Për shembull, le të themi se dëshironi të shfaqni numrin 5 me një zero të parë, domethënë në formën e "05":

Le të analizojmë vargun e formatit "FZ=2; HVN=". Ai përbëhet nga dy vargje formati të ndara me pikëpresje. Le të analizojmë secilën prej tyre veç e veç.

Rreshti "CHT=2" përcakton numrin total të numrave dhjetorë të shfaqur për pjesët e plota dhe thyesore. Kështu, numri i përgjithshëm i pozicioneve që numri do të zërë gjatë daljes do të jetë i barabartë me 2.

Vargu "HVN=", siç vijon nga ndihma, i tregon funksionit të formatit që nëse numri nuk arrin gjatësinë e deklaruar në gjatësi (si në rastin tonë, sepse kemi treguar 2 pozicione, dhe 5 zë vetëm një), atëherë duhet të përdoren zerat kryesore. E veçanta e këtij vargu të formatit është se ka vetëm emrin e parametrit dhe një shenjë të barabartë, por nuk ka vlerë. Po lexoni një version provë të mësimit, janë vendosur mësimet e plota.

Kombinimi i dy vargjeve të formatit na jep rezultatin që na nevojitet "05", në vend të "5".

Ndryshoni ndarësin dhjetor

Supozoni se duhet të shfaqim numra thyesorë me një ndarës yll në vend të një pike. Kjo do të thotë, në mënyrë që 25.46 të shfaqet si "25 * 46":

Vargu i formatit është parametri DF dhe vlera dddd, e cila tregon funksionin Formati nxirrni një paraqitje të gjatë të ditës së javës (vini re sa "d" përmban).

Paraqitja mujore e një date

Përshkrimi i muajit sipas datës shfaqet si më poshtë:

Vargu i formatit ka të njëjtin parametër DF si në rastin e mëparshëm. Por kuptimi është i ndryshëm. Tani është MMMM.

Merrni testin

Filloni testin

1. Formati ("19050505", "DF=MMMM") do të kthehet

2. Formatoni vargun duke ndryshuar ndarjen dhjetore dhe të plotë në ^

3. Që funksioni Format të kthejë "00005" në vend të 5, vargu i formatit është i përshtatshëm

4. Që funksioni Format të kthejë "10000" në vend të 10.000, një varg formati do të bëjë

5. Funksioni Format kthen një vlerë të llojit

Mekanizmi i ndarjes së të dhënave ju lejon të ruani të dhënat e disa organizatave të pavarura në një bazë informacioni.

Kjo bëhet e mundur për shkak të faktit se atributet e përbashkëta të objekteve të konfigurimit mund të përdoren jo vetëm si "i njëjti atribut që kanë të gjitha objektet", por edhe si një identifikues që të dhënat i përkasin një prej disa zonave të pavarura. Kjo mund të shpjegohet me shembullin e mëposhtëm.

Supozoni se ekziston një atribut i përbashkët "Organizimi" në konfigurim. Kjo do të thotë (e thjeshtuar) që çdo direktori, dokument ose objekt tjetër konfigurimi do të ketë gjithashtu atributin "Organizimi".

Në të njëjtën kohë, çdo përdorues i bazës së informacionit ka qasje në të gjitha të dhënat e ruajtura në këtë bazë të dhënash, pavarësisht se cila organizatë është e specifikuar, për shembull, në një dokument të veçantë.

Tani le të specifikojmë se atributi i përbashkët "Organizimi" do të jetë një ndarës.

Më pas (të thjeshtuara) do të krijohen disa zona të pavarura të të dhënave në infobazë, secila prej të cilave do të ruajë të dhëna vetëm për një organizatë specifike:

Tani, duke hyrë në program, përdoruesi nuk do të ketë akses në të gjithë informacionin që ndodhet në infobazë, por vetëm në të dhënat e zonës "të tij", në këtë rast, në dokumente, drejtori, etj. të organizatës së tij.

Një variant tjetër i përdorimit të këtij mekanizmi është gjithashtu i mundur, kur ka disa zona të pavarura të të dhënave në infobazë dhe, së bashku me këtë, ka të dhëna që janë të disponueshme për të gjithë përdoruesit e programit. Për shembull, ato përmbajnë një drejtori bankash, e cila është e njëjtë për të gjitha organizatat.

Në këtë rast, përdoruesi ka akses në zonën e të dhënave "të tij" dhe në zonën e të dhënave të pandarë, e cila është e zakonshme për të gjithë përdoruesit.

Mekanizmi i ndarjes së të dhënave është mjaft fleksibël dhe universal:

• ju lejon të përdorni jo një, por disa ndarës;
• ekzistojnë mënyra të ndryshme të përdorimit të të dhënave të përbashkëta; ato ndryshojnë në mënyrën se si trajtohet situata kur vlera e kufirit nuk është e specifikuar;
• përdorimi i një atributi të përbashkët si ndarës mund të kontrollohet gjatë funksionimit të programit nga gjuha e integruar pa ndryshuar konfigurimin; kjo quhet ndarje e kushtëzuar.

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

Pas /Z ne specifikojmë detajet e përgjithshme sipas radhës. Meqenëse kontabiliteti ynë standard tashmë ka dy detaje të zakonshme të sistemit, ne specifikojmë vlerën -0 për to në mënyrë që ato të mos përdoren, dhe si e treta (që kemi krijuar) kalojmë TIN-in.

1000 dhe 1 kuti zgjedhjeje

Ne e lëmë zgjedhjen e parametrave në diskrecionin, diskrecionin dhe mjedisin tuaj. Këtu është versioni ynë (kujdes, ka 20,000 piksele).

Ndarësi bën gjithashtu të mundur vendosjen e një liste të veçantë përdoruesish për secilën bazë të dhënash - kjo mund të jetë e dobishme nëse keni qindra përdorues - kur hyni në një bazë të dhënash të caktuar, nuk keni pse të lëvizni nëpër këtë listë në kallo të përgjakshme. Ne nuk e përdorim këtë sepse kemi krijuar autorizim transparent.

Ngarkimi i të dhënave nga bazat e të dhënave aktuale

Shënim për zonjën: është më mirë të ngarkoni drejtoritë dhe dokumentet veç e veç - në këtë mënyrë mund të shmangni gabimet e panevojshme në kohën e ngarkimit.

Ngarkimi i të dhënave në një bazë të dhënash të përbashkët

Për të thjeshtuar detyrën, ne kryejmë ngarkime me shumicë, pasi kemi kryer një përpunim standard paksa të korrigjuar përmes linjës së komandës (/Execute c:\upload.epf). Pastaj ne ngarkojmë manualisht skedarët e marrë në bazën e të dhënave të përbashkët.

Si të shpenzoni më shumë kohë për të shpenzuar më pak kohë

Kontabilistët nuk e vërejnë kalimin e organizatave nga një bazë e rregullt në një të ndarë, për ta procesi është pa dhimbje. Prapa digjet vetëm për administratorët :)

Efektet anësore: kursime hapësire 1 deri në 20, rritje indirekte e shpejtësisë - e paçmueshme. Në terma absolute, 50 organizata zënë 2 GB hapësirë ​​në SQL, ndërsa një bazë e të dhënave individuale zë 800 MB.

Miza e premtuar në vaj, madje katër:

• nëse një nga përdoruesit ngatërron të dhënat në një organizatë, ju duhet të riktheni të gjithë bazën e të dhënave të ndarë - nuk mund të merrni dhe riktheni vetëm një zonë të të dhënave
• ju duhet të testoni përditësimet më tërësisht, veçanërisht ato që shtojnë ose ndryshojnë drejtoritë
• nëse duhet të transferoni bazën e të dhënave te klienti (ose të bashkoni atë tatimor :), duhet të bëni procedurën e kundërt: shkarkoni organizatën nga baza e të dhënave të ndarë duke përdorur shkëmbimin universal, pastaj ngarkoni atë në një bazë të dhënash të rregullt boshe dhe ruani nga atë për të. skedar dt
• në një bazë të dhënash të ndarë, është e pamundur të menaxhohen detyrat e planifikuara (për shembull, nuk do të jetë e mundur të përditësohen automatikisht kurset e këmbimit)

Elementi ndarës 1C nevojitet për të rishpërndarë zonat e formularit, pasi është i përshtatshëm për përdoruesin për momentin. Pothuajse çdo përdorues i Windows ka aftësinë për të përdorur ndarësit. Le të themi se keni krijuar një formë të thjeshtë me dy kontrolle.

Tradicionalisht, artikujt e çdo liste mund të vendosen në anën e majtë. Në anën e djathtë, përkatësisht, ekziston një specifikim i detajuar i pikërisht këtyre pikave. Nëse lista e majtë përbëhet nga emra të shkurtër, është logjike që kjo kolonë të zvogëlohet në minimum. Prandaj, në këtë rast, lexueshmëria e anës së djathtë do të rritet. Dhe anasjelltas, nëse ka emra të gjatë në anën e majtë, kolona duhet të zgjerohet. Ndarësit lejojnë përdoruesin të personalizojë formën në mënyrë arbitrare thjesht duke zvarritur kufirin me miun.

Kjo metodë kontrolli përdoret kur redaktoni tabela në Word dhe Excel. Kur krijoni një formë, mund të krijoni një element të formës ndarëse vertikale dhe horizontale. Në përgjithësi, është më e preferueshme të krijohen forma që janë vizualisht brenda ekranit.

Separator 8.2, 8.3 (forma të menaxhuara)

Ju nuk mund të shtoni një ndarës në një formë të menaxhuar 1c, ai shtohet automatikisht nga programi para / pas fushës së tabelës

1. Parathënie.

Kishte nevojë të organizohej kontabiliteti për dy organizata në një IS. Situata nuk është unike, por ndodhi që UPP-ja jonë jo tipike 250 GB funksionoi mjaft ngadalë, kështu që në vend të RLS vendosëm të provonim ndarjen e të dhënave. Ajo që është përshkruar, për shembull, ose. Shkurtimisht, nëse RLS kushtëzon pyetjet SQL, atëherë delimituesi i të dhënave është një kolonë shtesë në tabela në nivelin DBMS, ku mekanizmi ndarës duhet të jetë më i shpejtë se RLS.

Pra, në bazën e të dhënave ku mbaheshin shënimet për OOO nr. 1, është e nevojshme të transferohet informacioni nga një bazë e veçantë e të dhënave të OOO nr. 2 dhe të organizohet puna e përbashkët. Ashtu si në foto:

Të vdekshmit e thjeshtë punojnë vetëm me LLC-në e tyre, dhe llogaritari kryesor ndonjëherë shikon të dhënat për dy persona juridikë. Në modalitetin e hyrjes në të dy LLC-të, ju mund të lexoni vetëm të dhëna, kështu që llogaritari kryesor duhet të jetë në gjendje të kalojë në mënyrë interaktive midis mënyrave "lexo të gjitha" / "shkruaj vetëm për një organizatë" dhe të zgjedhë LLC (d.m.th. të vendosë vlerën e atribut i përbashkët) për të kryer, për shembull, llogaritjen e kostos.

2. Zbatimi

Platforma 8.2.19.90, pa modalitet përputhshmërie. DBMS - MSSQL Server 2008 R2 Standard.

Ne krijuam një atribut të përbashkët Ndarës Organizimi të llojit "numër", ramë dakord me propozimin për krijimin e parametrave të sesionit, të plotësuar në përbërjen e atributit (përfshirë disa drejtori, të gjitha dokumentet, regjistrat e akumulimit, kontabilitetit dhe llogaritjes). Ndarja e të dhënave - "Në mënyrë të pavarur dhe të përbashkët". Vlera e parametrit të sesionit vendoset nga cilësimet e paracaktuar të përdoruesit në procedurën SetSessionParameters në modulin e sesionit:

Organizata = UserManagement.GetDefaultValue(glCurrentUser,"Organizimi Kryesor");
SessionParameters.OrgDelimiterValue = Organizata.DelimiterValue;

Në ndërfaqen e llogaritarit kryesor, ata krijuan një formular me aftësinë për të kaluar midis organizatave dhe për të aktivizuar / çaktivizuar mënyrën e ndarjes:

Me ndarjen të çaktivizuar, kur SessionParameters.OrganizationSeparatorUse = False, platforma refuzon të shkruajë dokumente, duke hedhur poshtë gabime si "Gabim SDBL: shprehja e pritshme (pos=12)", kështu që nuk mund ta lini përdoruesin të shkruajë dokumente në këtë opsion. Për besueshmëri, ne krijuam abonime në ngjarjen "Para regjistrimit" për objektet që janë pjesë e atributit të përbashkët:

Nëse SessionParameters.OrgDelimiterUse = False Pastaj
#Nëse Klient Atëherë
Paralajmërim ("Nuk mund të shkruhet sepse ndarja e të dhënave është e çaktivizuar!");
#FundNëse
Refuzim = i vërtetë;
FundNëse;

Plani ynë i veprimit ishte si më poshtë: ne përgatisim konfigurimin e marrësit të IB nr. 1, vendosim vlerat e atributit të përbashkët = 1, ngarkojmë të dhënat nga IB nr. 2, pasi ngarkojmë për të gjitha objektet me një bosh (të barabartë me 0) vlera e ndarësit, vendosni Organizimin Separator = 2.

Konfigurimi u përgatit, lindi pyetja, si të vendosni vlerën e atributit të përgjithshëm për dokumentet dhe lëvizjet e tyre në periudha të mbyllura, dhe shpejt dhe pa rrezikun që numrat në bilanc do të fluturojnë? Përmes modelit të objektit 1C, është e pamundur të shkruhet një ndarës veçmas nga objekti, kështu që më duhej të prishja marrëveshjen e licencës për të dalë dhe për të shkruar një pyetje për MS SQL. Meqenëse ka shumë objekte në atributin e përbashkët dhe ka edhe më shumë tabela në mollëza për këto objekte, ne kemi shkruar një përpunim që gjeneron një pyetje për SQL (për çdo objekt meta të dhënash që është pjesë e ndarësit, kemi shkruar "përditësim" + DB_name + ".dbo._" + Emri i tabelës + "set _" + Fusha Atributi i Përgjithshëm + " = 1";)

Vlera u vendos, disa nga të dhënat u transferuan nga IB nr. 2 dhe testimi filloi.

Rezultati ishte zhgënjyes. Së pari, problemet me regjistrin e kontabilitetit. Kur aktivizohet ndarja, analitika nuk është e dukshme:

Kjo për faktin se regjistri i kontabilitetit në nivelin DBMS ruhet si disa tabela, dhe jo të gjitha tabelat kishin vlerën e një atributi të përbashkët (përpunimi u përdor për të parë strukturën).

Epo, ne vendosim vlerën e ndarësit përmes MS SQL, shohim analitikën. Tani raportet nuk funksionojnë. Rezulton se ka probleme me pyetjet në tabelat virtuale të regjistrit të kontabilitetit "Turnovers" dhe "TurnoversDtKt":

(Fld27033 është vetëm një atribut i zakonshëm në tabelën e regjistrit të kontabilitetit)

Ndarësi është vendosur në të gjitha tabelat, mund të shihet në nivelin DBMS, çfarë mund të jetë një gabim, nuk është e qartë. Ne vendosim një SCP tipike të zbrazët, bëjmë ndryshimet e konfigurimit të përshkruara më sipër, futim disa dokumente (në këtë opsion, vetë platforma vendos vlerën e ndarësit në të gjitha tabelat e regjistrave të kontabilitetit), por gabimet riprodhohen. Është keq, por ne i përjashtojmë regjistrat e kontabilitetit nga kushtet e përgjithshme, vazhdojmë testimin.

Më tej, rezulton se mekanizmi i zhvendosjes për regjistrat e llogaritjes ka pushuar së punuari. Ne nuk kemi ndarë plane për llojet e llogaritjeve, po përpiqemi të kërkojmë një problem në tabelat e regjistrit të llogaritjes dhe në rillogaritjet. Ne kontrollojmë, vendosim vlerën e atributit kryesor, bëjmë T&I - pa dobi.

Gjatë rrugës, ne diagnostikojmë problemin kur shkruajmë informacion në regjistra të pavarur nga formulari i listës. Në këtë rast, të dhënat regjistrohen, ato mund të shihen pas rifillimit. Problemi riprodhohet në bazën e provës:

Regjistrat e informacionit nuk mund të "riparoheshin" duke manipuluar SQL (vlera e ndarësit është vendosur në të gjitha tabelat), kështu që ata thjesht u përjashtuan nga atributi i përgjithshëm. Pas disa ditësh eksperimentimi, përpjekjet për të rivendosur kapacitetin e punës të zhvendosjes janë gjithashtu të pasuksesshme.

Në këtë pikë, ne vendosim të çaktivizojmë ndarjen e të dhënave dhe të përdorim përsëri RLS. Kur vendosim ndarjen në "mos përdor", hasim gabime "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX u ndërpre sepse u gjet një çelës dublikatë për indeksin...". Kjo do të thotë, nuk është aq e lehtë të ktheheni në gjendjen para ndarjes. Problem me indekset e tabelave të rillogaritjes, cilësimet për ruajtjen e totaleve dhe të tjera. Fakti është se tabelat ruajnë rreshta identike që ndryshojnë vetëm në vlerën e atributit të përbashkët. Kur fshini një atribut të përbashkët, shfaqen hyrje jo unike. Ju do të duhet të fshini të dhënat e panevojshme direkt në MS SQL, diçka si kjo (për tabelën e rillogaritjes):

baza e përdorimit;
ALTER TABLE_CRgRecalc1399
SHTO ID IDENTITETIN INT (1,1);
SHKO
FSHI NGA_CRgRecalc1399
KU ID< (SELECT MAX(id)
NGA _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef dhe
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] dhe
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] dhe
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] dhe
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] dhe
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
SHKO
ALTER TABLE_CRgRecalc1399
HIQ KOLONA id;

Dhe vetëm pas pastrimit të disa dhjetëra tabelave, është e mundur të çaktivizohet ndarja e të dhënave. Pas fikjes së ndarjes, nuk ka probleme.

3. Përfundime.

Kishte shpresë se 8.3 probleme u zgjidhën. Ne nuk ishim shumë dembelë, kontrolluam në 8.3.4.482 (me modalitetin e pajtueshmërisë të çaktivizuar). Ne shikuam një SCP-shke pothuajse tipike, me ndryshime në konfigurim vetëm për mbështetësit e përgjithshëm. Në këtë bazë testimi, ndarja u aktivizua përpara se të futej informacioni, d.m.th. platforma duhej të shkruante saktë vlerën e ndarësit në të gjitha tabelat, ata nuk shkruanin asgjë drejtpërdrejt në MS SQL vetë.

Rezultati:

Riprodhohet problemi me pyetjet në tabelat virtuale "Turnovers" dhe "TurnoversDtKt".

Problemi i parandalimit është i riprodhueshëm.

Problemi me shkrimin në regjistrat e pavarur të informacionit riprodhohet.

Problemi me fikjen e ndarjes - nuk do të funksionojë për ta hequr atë me një klik të butonit!

Kështu, ne nuk arritëm të zëvendësonim RLS me një mekanizëm të ri. Ky mekanizëm u konceptua, me sa duket, për shërbimet cloud, dhe në rastin e përdorimit të të dhënave të përbashkëta "në mënyrë të pavarur", ndoshta ndarja do të funksionojë, por ne kemi nevojë për një NSI të përbashkët. Mbetet të presim që 1C të korrigjojë gabimet, dhe akoma më mirë, të zbatojë një mekanizëm tipik për ndarjen sipas organizatave në konfigurimet standarde.