Redaktori i formularit përdoret për të krijuar dhe modifikuar forma të objekteve të zgjidhjes së aplikacionit. Format e objekteve përdoren nga sistemi për të shfaqur vizualisht të dhënat e objektit gjatë punës së përdoruesit.
Çdo formë është një kombinim i tre komponentëve:
- dialogu i formës - një dritare që do të shfaqet në ekran;
- moduli i formës - një program në gjuhën e integruar që është përgjegjës për punën me kontrollet e formularit dhe trajtimin e ngjarjeve;
- atributet e formës - një grup objektesh që i përkasin formës, të dhënat e të cilave përdor në punën e tij.
Redaktori i formularit siguron drejtpërdrejt redaktimin e dialogut të formularit, atributet e tij dhe thërret redaktorin e teksteve dhe moduleve për të redaktuar modulin e formularit.
Dritarja e redaktuesit të formularit përmban tre skeda që ofrojnë redaktimin e të tre komponentëve të formularit.
Redaktimi i një Dialogu Formular
Redaktori i formularit i lejon zhvilluesit të përfitojë plotësisht nga një gamë e gjerë veçorish dialogu. Ne rendisim kryesoret e këtyre mundësive:
Panelet, faqet, faqeshënuesit
Redaktori i dialogut i lejon zhvilluesit të vendosë kontrolle të veçanta në formular që ndihmojnë për t'i dhënë formës stilin e vet të dallueshëm, për ta bërë aksesin e të dhënave të thjeshtë dhe të kuptueshëm dhe për të përshtatur një sasi të madhe informacioni në një zonë të kufizuar.
Redaktori ju lejon të vendosni disa panele në formular, secila prej të cilave mund të përmbajë disa faqe. Për shembull, një formular dokumenti mund të përmbajë një panel me dy faqe: Produktet dhe Shtesat:
Zhvilluesi ka aftësinë të caktojë modalitetin në të cilin faqet do të lëvizin brenda panelit ose të përdorë faqeshënuesit për të kaluar ndërmjet faqeve. Redaktori ju lejon të përcaktoni një numër të madh opsionesh të ndryshme për vendndodhjen dhe shfaqjen e faqeshënuesve:
Për shembull, faqerojtësit mund të vendosen horizontalisht në krye:
Ose mund t'i rregulloni faqeshënuesit në të majtë vertikalisht:
Kontrollet
Redaktori ju lejon të vendosni një shumëllojshmëri të gjerë kontrollesh në formular. Ju mund të vendosni kontrolle duke zvarritur ose duke përdorur një dialog të veçantë për futjen e kontrolleve, i cili ju lejon të vendosni njëkohësisht vetitë e dëshiruara të kontrollit të zgjedhur:
Në rastin kur formulari përmban një numër të madh kontrollesh, zhvilluesi mund të përdorë mënyrën e shfaqjes së kontrolleve në listë, e cila ju lejon të lundroni shpejt në kontrollin e dëshiruar:
Redaktori ofron mundësinë për të specifikuar rendin në të cilin përdoruesi do të anashkalojë kontrollet e formularit kur fut dhe redakton të dhënat. Është e mundur të vendosni rendin automatik të kalimit ose të vendosni manualisht rendin e kalimit në një listë të veçantë kontrollesh, ose duke klikuar drejtpërdrejt në formular:
Rrjeti, shtrirja
Redaktori i formularit ka mundësi të mëdha për të kontrolluar vendosjen e elementeve në formular. Në veçanti, ai mbështet punën me një rrjet faqosjeje, kur kufijtë dhe madhësitë e kontrolleve përputhen me rrjetin e paraqitjes të vendosur në formë. Zhvilluesi ka aftësinë të ndryshojë ndarjen e rrjetit të paraqitjes dhe në këtë mënyrë të arrijë një vendndodhje më të saktë të kontrolleve:
Redaktori gjithashtu mbështet përdorimin e linjave të shtrirjes, të cilat përdoren për të lehtësuar shtrirjen dhe pozicionin relativ të kontrolleve të formës. Për shembull, në ilustrimin e mëposhtëm, linjat e shtrirjes përdoren për të pozicionuar kontrollet në faqen e avancuar:
Zhvilluesi ka aftësinë të vendosë numrin e kërkuar të linjave të shtrirjes horizontale ose vertikale në faqe, si dhe të përdorë linja të padukshme të shtrirjes. Redaktori krijon linja të padukshme të shtrirjes automatikisht pasi dy ose më shumë kontrolle janë rreshtuar në ndonjë nga kufijtë. Për shembull, nëse dy fusha me të njëjtën madhësi janë lënë të rreshtuara, atëherë do të krijohet një vijë e padukshme e shtrirjes përgjatë kufijve të rreshtuar djathtas të atyre fushave.
Rreshtimi i kontrolleve mund të bëhet gjithashtu duke përdorur shënues të veçantë që tregojnë drejtimin e dëshiruar të zhvendosjes së kontrolleve. Dorezat shfaqen kur dy kontrolle janë në afërsi të njëri-tjetrit.
Dorezat blu të shtrirjes tregojnë drejtimin e dëshiruar për të lëvizur kontrollin për ta rreshtuar atë me një nga kufijtë e kontrollit ngjitur:
Dorezat e shtrirjes me ngjyrë të kuqe tregojnë drejtimin e dëshiruar që kontrolli të lëvizë kur mbivendoset me një kontroll tjetër:
Duhet të thuhet gjithashtu se redaktori mbështet operacionet e shtrirjes, ndryshimit të madhësisë dhe renditjes për një grup kontrollesh:
Lidhjet
Redaktori i formularit ju lejon të personalizoni sjelljen e kontrolleve të vendosura në formë në mënyrë që kur forma ndryshohet, informacioni perceptohet natyrshëm: një pjesë e elementeve mbetet në vend, pjesa tjetër lëviz së bashku me kufijtë e formularit dhe e treta pjesa ndryshon madhësinë e saj në përputhje me ndryshimin e madhësisë së formës.
Për të vendosur një sjellje të tillë të elementeve të formës, zhvilluesi mund të përshkruajë lidhjet - varësia e pozicionit të kufijve të kontrolleve nga pozicioni i kufijve të formularit. Kufiri i një kontrolli mund të ankorohet ose në kufirin ose qendrën e formularit, ose në kufirin ose qendrën e një kontrolli tjetër.
Redaktori mbështet një gamë të gjerë llojesh të ndryshme fotografish dhe mund t'i shfaqë ato në mënyrë grafike:
Ndarësit
Ndarësit janë kontrolle të veçanta që mund të përdoren për të rishpërndarë hapësirën e formës pa ndryshuar madhësinë e saj. Në modalitetin 1C: Enterprise, ndarësi ka aftësinë të "kapet" nga miu dhe të lëvizë brenda formës brenda kufijve të tij, duke marrë parasysh mundësinë e vendosjes së kontrolleve të tjera dhe orientimin e ndarësit:
Kur lëvizni ndarësin, të gjitha kontrollet e lidhura me ndarësin do të ndryshojnë madhësinë ose do të lëvizin sipas grupit të ankorave:
ActiveX
Redaktori ju lejon të vendosni kontrollet ActiveX në formën, të cilën zhvilluesi mund t'i personalizojë dhe t'i menaxhojë më tej duke përdorur mjetet e integruara të gjuhës:
Redaktimi i një moduli formulari
Për të redaktuar modulin e formularit, konfiguruesi thërret redaktorin e teksteve dhe moduleve. Ky redaktues i ofron zhvilluesit një shumëllojshmëri të gjerë opsionesh për krijimin dhe modifikimin e tekstit të modulit.
Redaktimi i detajeve të formularit
Atributet e formularit redaktohen në listë, e cila ju lejon të krijoni atribute të reja, të ndryshoni ato ekzistuese dhe të fshini atributet e panevojshme:
Nëse forma ka një atribut kryesor që përcakton sjelljen e formularit, të ndryshëm nga ai tipik, ai theksohet me shkronja të zeza. Zhvilluesi mund të vendosë kursorin në atributin e dëshiruar dhe, duke përdorur komandën e menusë, të shkojë menjëherë në dialogun e formularit, në elementin e kontrollit që korrespondon me atributin e zgjedhur.
informacion shtese
Mund të njiheni me përdorimin e redaktuesit të formularit në kohë reale. Për ta bërë këtë, mund të shkarkoni një video demo "Shembull i zhvillimit të një mini-sistemi tregtar", i cili tregon procesin e zhvillimit të një mini-sistemi tregtar duke përdorur këtë redaktues për të krijuar formularët e dokumentit "Faturë", "Faturë" dhe formularët e raportit " Analiza e shitjeve" dhe "Analiza e shitjeve sipas periudhave.
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.
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:
- "01.01.2005"
- "1 janar 2005"
- "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":
| Raporti(Format(5, "FH=2; FH=") ); // nxjerr 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ë:
| Raporti(Format("20050101" , "DF=MMMM") ); // shtyp janar |
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
Një veçori funksionale relativisht e re e 1C, e lidhur me teknologjitë cloud. Pas shfaqjes së funksionalitetit, kompania 1C finalizoi BSP. Të njëjtat përmirësime u përfshinë në konfigurimet standarde të bazuara në BSP, për shembull, UNF dhe UT11.
Ishte e nevojshme të organizohej marrja e raporteve të përgjithshme nga disa degë me të njëjtat konfigurime. Vendosa të provoj zhvillimet nga BSP në fushën e ndarjes së të dhënave. Ideja ishte që të ngarkoheshin të dhënat e secilës degë në zonën e vet të të dhënave dhe të gjeneroheshin raporte për të gjitha fushat menjëherë. Duhet të them menjëherë se problemi nuk ka qenë ende i mundur, por vetë përpjekja për ta zgjidhur atë zbuloi probleme dhe funksionalitet të dyshimtë në BSP.
Përpunimi i është bashkangjitur artikullit, i cili sjell funksionalitetin e fshehur të operacioneve me zonat e të dhënave në një formë të veçantë.
Ekzistojnë dy kufij kontabël në BSP: Zona kryesore e të dhënave dhe zona e të dhënave ndihmëse. Mbetet një mister pse këta 2 kufizues u referohen të njëjtave parametra të sesionit: DataAreaValue, DataAreaUsage.
Ndezja e mekanizmit
Nëse konfigurimi juaj i shkruar vetë bazohet në BSP, atëherë, ka shumë të ngjarë, përpara se ta aktivizoni, duhet të zbatoni bibliotekën misterioze "1C: Biblioteka e Teknologjisë së Shërbimit". Është e çuditshme që edhe Google nuk di për një produkt të tillë 1C. Dhe në konfigurimet tipike, nuk ka asnjë procedurë CheckAbility to Use ConfigurationInServiceModel në modulin WorkInServiceModel. Me shumë mundësi, ju mund të gjeni pjesët që mungojnë nga kjo bibliotekë në konfigurime tipike të bëra në bazë të BSP. Në veçanti, një nga nënsistemet quhet StandardSubsystems > RunInServiceModel > UploadUploadData.
Mekanizmi i ndarjes së të dhënave aktivizohet duke vendosur konstantën UseSplitByDataArea. Mund të vendoset nëpërmjet artikullit të menysë Të gjitha funksionet.
Krijimi i përdoruesve të rajonit të të dhënave
Ky artikull është opsional nëse jeni duke përdorur futjen e formularit në zonën e të dhënave. Përdoruesit krijohen në modalitetin e konfiguruesit. Një përdorues me të drejta administrative duhet të ketë të gjithë ndarësit e pacaktuar të të dhënave në skedën "Ndarja e të dhënave". Për përdoruesit e tjerë, në skedën "Ndarja e të dhënave", duhet të vendosen të dhënat kryesore të zonës ndarëse të të dhënave. Ky ndarës duhet të specifikohet në mënyrë eksplicite në vijën e komandës kur fillon 1C.
Nisni 1C me një parametër të linjës së komandës
Ky artikull nuk kërkohet nëse jeni duke përdorur hyrjen në zonën e të dhënave nëpërmjet formularit të hyrjes.
1C mund të lansohet menjëherë në modalitetin e ndarjes së të dhënave. Opsioni i linjës së komandës /Z ofrohet. Për shembull, parametri "/Z-,+1" tregon se 1C është nisur me vlerën e të dhënave kryesore të zonës së të dhënave të barabartë me 1, ndarësi i të dhënave ndihmëse të zonës së të dhënave nuk është vendosur.
Metoda është shumë jo e besueshme. Gjatë nisjes, ndodh një gabim në procedurën WorkInServiceModel. WhenCheckingEnableSecureSharingMode. Nuk gjeta asgjë më të mirë sesa të komentoja këtë procedurë. Procedura kontrollon nëse përdoruesi ka të drejtë të ndryshojë zonën aktuale të të dhënave, nëse të drejtat e tij janë të kufizuara dhe nëse ndikon në sigurinë.
Më tej, gjatë fillimit, ka disa gabime midis tyre: "Përdoruesve të ndarë nuk mund t'u caktohet roli i Administratorit të Sistemit", "Përdoruesve të ndarë nuk mund t'u caktohet roli i fillimit të një klienti të trashë".
Përdoruesi nuk u gjet në drejtorinë e përdoruesve - problemi nuk mund të kapërcehej. Në skenarin tradicional, Përdoruesi regjistrohet në hyrjen e parë. Dyshoj se kur ndahen të dhënat, Përdoruesit krijohen përmes një aplikacioni tjetër 1C Fresh.
Plotësoni regjistrin e informacionit të zonës së të dhënave
Për çdo zonë, duhet të plotësoni një hyrje në regjistrin e informacionit të Zonës së të Dhënave, duke caktuar numra zonave dhe statusin "E përdorur". Përpunimet mund të kontrollojnë për regjistrime në këtë regjistër përpara se të fillojnë ekzekutimin.
Hyrja në zonën e të dhënave
Administrimi - Shërbimi - Hyrja në zonën e të dhënave (Zona CommonForm.EnteringData)
Lejon përdoruesin të ndryshojë zonën aktuale të të dhënave. Regjistrimi në zonë është i mundur në emër të një përdoruesi të filluar pa specifikuar kufijtë. Kur një zonë e të dhënave ndryshohet, ajo kontrollon statusin e saj në regjistrin e informacionit të zonës së të dhënave.
Shkarkimi i të dhënave nga një zonë
Zona aktuale shkarkohet përmes CommonForm. Ngarkimi i të dhënave. Para se ta përdorni, duhet të identifikoheni në zonën e dëshiruar të të dhënave. Formulari nuk shfaqet në ndërfaqen e përdoruesit në seksionin Administrimi.
Të dhënat serializohen nga konfigurimi në formatin XML dhe paketohen në ZIP. Kjo do të thotë, arkivimi nuk bëhet duke përdorur konfiguruesin 1C, si shkarkim tradicional.
Ngarko të dhëna në zonë
Komanda e përgjithshme.LoadDataToRegion
Për t'u shfaqur në Shërbimin Administrim, duhet të vendosni dukshmërinë përmes Konfiguratorit si pjesë e nënsistemit Setup and Administration.
Të dhënat ngarkohen në zonën e zgjedhur. Para kësaj, ato duhet të ngarkohen në formatin XML.
konkluzionet
Nisja e sistemit dështoi duke vendosur kufijtë në vijën e komandës. Sistemi refuzoi të funksiononte për shkak të një përdoruesi të paregjistruar në drejtorinë e Përdoruesve. Nuk ishte e mundur të arrini në drejtori për arsye se sistemi nuk lejon përdoruesit me të drejta administrative. Mendoj se ky skenar parashikon një lidhje të detyrueshme me 1CFresh.
Eksperiencat me hyrjen në zona të ndryshme, në zonat e shkarkimit dhe ngarkimit ishin të suksesshme. Një përpjekje për të marrë të gjitha organizatat për të gjitha rajonet e të dhënave dështoi. Gabim: "Nuk mund të përdoret tabela pa specifikuar të gjithë kufijtësit me përdorim të pavarur të të dhënave të përbashkëta." Raporti funksionon në një fushë, nëse hyni në ndonjë zonë.
Problemi mbeti i paqartë, si të ngarkohen të dhënat nga një bazë të dhënash pa ndarës në një zonë të caktuar të të dhënave të një baze të dhënash tjetër.
Do të ishte interesante të mësohej për idenë dinake të autorëve të BSP në lidhje me parametrat e sesionit të përgjithshëm për dy ndarës, nëse thirrja është me parametrat: "/Z-,+1", "/Z+1,+1 " dhe "/Z+1,-" .
1. Parathënie.
Kishte nevojë të organizohej kontabiliteti për dy organizata në një IB. 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ë konfigurime standarde.
