Bezpečnost 

Mechanismus separace dat 1s. Separace dat, mechanismus. Měsíční reprezentace data

Mechanismus sdílení dat umožňuje ukládat data několika nezávislých organizací v jedné infobázi.

To je možné díky skutečnosti, že společné atributy konfiguračních objektů lze použít nejen jako „stejný atribut, který mají všechny objekty“, ale také jako identifikátor, že data patří do jedné z několika nezávislých oblastí. To lze vysvětlit na následujícím příkladu.

Předpokládejme, že v konfiguraci je společný atribut "Organizace". To znamená (zjednodušeně), že každý adresář, dokument nebo jiný konfigurační objekt bude mít také atribut "Organizace".

Ke všem datům uloženým v této databázi má přitom přístup každý uživatel infobáze bez ohledu na to, jaká organizace je uvedena např. v konkrétním dokumentu.

Nyní upřesněme, že společný atribut "Organizace" bude oddělovačem.

Poté (zjednodušeně) bude v infobázi vytvořeno několik nezávislých datových oblastí, z nichž každá bude ukládat data pouze pro jednu konkrétní organizaci:

Nyní při vstupu do programu uživatel nezíská přístup ke všem informacím, které jsou v infobázi, ale pouze k údajům „jeho“ oblasti, v tento případ na dokumenty, referenční knihy atd. vaší organizace.

Je možná i jiná varianta použití tohoto mechanismu, kdy je v infobázi několik nezávislých datových oblastí a spolu s tím jsou data dostupná všem uživatelům programu. Obsahují například adresář bank, který je stejný pro všechny organizace.

V tomto případě má uživatel přístup do „své“ datové oblasti a do nesdílené datové oblasti, která je společná pro všechny uživatele.

Mechanismus sdílení dat je poměrně flexibilní a univerzální:

  • umožňuje vám použít ne jeden, ale několik oddělovačů;
  • existují různé způsoby využití sdílených dat; liší se v tom, jak je řešena situace, kdy není specifikována hodnota oddělovače;
  • použití společného atributu jako oddělovače lze ovládat během provozu programu z vestavěného jazyka bez změny konfigurace; toto se nazývá podmíněné rozdělení.

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

Po /Z specifikujeme obecné detaily v pořadí. Protože naše standardní účetnictví má již dva společné systémové detaily, uvedeme u nich hodnotu -0, aby se nepoužívaly, a jako třetí (který jsme vytvořili) předáme DIČ.

1000 a 1 zaškrtávací políčko

Nyní je třeba určit, jaká část dat bude společná pro všechny oblasti. To vše se konfiguruje přes konfigurátor. Ve vlastnostech obecných rekvizit, které jsme právě vytvořili, je položka „Composition“, která otevírá malý seznam 800 parametrů:

Výběr parametrů necháme na vašem uvážení, uvážení a prostředí. Zde je naše verze (pozor, je tam 20 000 pixelů).

Separátor také umožňuje nastavit pro každou databázi samostatný seznam uživatelů - to se může hodit, pokud máte stovky uživatelů - při vstupu do určité databáze nemusíte listovat tímto seznamem až ke krvavým mozolům. Toto nepoužíváme, protože máme nastavenou transparentní autorizaci.

Nahrávání dat z aktuálních databází

Pro nahrávání dat z aktuálních databází využíváme univerzální XML výměnu. Základnu nemůžete jen tak vzít a vyložit, musíte si nastavit pravidla výměny, jinak může (a určitě dojde) při načítání k chybám a konfliktům a druhá základna prostě neproleze. Připomeňme, že rozdělujeme základní oblasti pro každou organizaci a v našem případě taková pravidla výměny fungují. Pokud se rozhodnete použít jiný oddělovač, budete muset použít mozek a zaškrtávací políčka. Hlavní věcí je nepoužívat standardní vykládání - to povede k duplikaci všech předdefinovaných záznamů.

Poznámka pro hostesku: Adresáře a dokumenty je lepší nahrávat samostatně – vyhnete se tak zbytečným chybám v době nahrávání.

Načítání dat do sdílené databáze

Spouštíme 1C s parametrem / Z "-0, -0, +% váš oddělovač%", což označuje oddělovač organizace, jejíž data budeme stahovat. Spouštíme univerzální výměnu a dodáváme do ní soubory přijaté během nahrávání: nejprve adresáře, pak dokumenty. Tuto operaci opakujeme pro každou základní plochu.

Pro zjednodušení úlohy provádíme hromadné nahrávání po spuštění mírně opraveného standardního zpracování pomocí příkazového řádku (/Execute c:\upload.epf). Poté ručně nahrajeme přijaté soubory do sdílené databáze.

Jak trávit více času trávit méně času

Proces separace není rychlá věc. Připomeňme, že nyní máme více než 500 organizací, ale za pár týdnů se nám podařilo sdílet pouze 70. S jistotou však víme, že za šest měsíců poděkujeme svému minulému já za odvedenou práci a spoustu ušetřeného času a snaha.

Účetní nezaznamenávají přechod organizací z běžné základny na rozdělenou, pro ně je tento proces bezbolestný. Pálení zadků jen pro adminy :)

Vedlejší efekty: úspora místa 1 až 20, nepřímé zvýšení rychlosti - neocenitelné. V absolutních číslech zabírá 50 organizací v SQL 2 GB místa, zatímco jedna jednotlivá databáze zabírá 800 MB.

Slíbená moucha, dokonce čtyři:

  • pokud jeden z uživatelů pokazil data v jedné organizaci, musíte vrátit zpět celou rozdělenou databázi - nemůžete jen vzít a vrátit zpět jednu datovou oblast
  • musíte důkladněji testovat aktualizace, zejména ty, které přidávají nebo mění adresáře
  • pokud potřebujete přenést databázi na klienta (nebo sloučit daňovou :), musíte udělat obrácený postup: vyložit organizaci z rozdělené databáze pomocí univerzální burzy, poté ji načíst do prázdné běžné databáze a uložit z to do. dt soubor
  • v rozdělené databázi není možné spravovat naplánované úlohy (například nebude možné automaticky aktualizovat směnné kurzy)
První tři lžičky nejsou tak hořké – jen nás nutí dávat větší pozor. Co ale dělat se čtvrtým, to zatím nevíme, ale pilně pátráme.

1. Preambule.

Vznikla potřeba organizovat účetnictví pro dvě organizace v jednom ZS. Situace není ojedinělá, ale stalo se, že naše velmi netypické 250 GB UPP fungovalo dost pomalu, a tak jsme se místo RLS rozhodli vyzkoušet separaci dat. Co to je, je popsáno např. popř. Stručně řečeno, pokud RLS podmiňuje SQL dotazy, pak je oddělovač dat dalším sloupcem v tabulkách na úrovni DBMS, díky kterému by měl rozdělovací mechanismus fungovat rychleji než RLS.

Takže v databázi, kde byly vedeny záznamy pro OOO č. 1, je nutné přenést informace ze samostatné databáze OOO č. 2 a organizovat společnou práci. Stejně jako na obrázku:

Prostí smrtelníci pracují pouze se svou LLC a hlavní účetní se někdy dívá na údaje o dvou právnických osobách. V režimu přístupu do obou LLC můžete data pouze číst, takže hlavní účetní by měl mít možnost interaktivně přepínat mezi režimy „číst vše“ / „zapisovat pouze pro jednu organizaci“ a vybrat LLC (tj. nastavit hodnotu společný atribut) provádět například kalkulaci nákladů.

2. Realizace

Platforma 8.2.19.90, žádný režim kompatibility. DBMS - MSSQL Server 2008 R2 Standard.

Vytvořili jsme společný atribut Organizační oddělovač typu "číslo", souhlasili s návrhem na vytvoření parametrů relace, vyplnili složení atributu (včetně několika adresářů, všech dokumentů, akumulačních, účetních a kalkulačních registrů). Oddělení dat – „Nezávisle a společně“. Hodnota parametru relace se nastavuje z výchozího uživatelského nastavení v proceduře SetSessionParameters v modulu relace:

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

V rozhraní hlavního účetního vytvořili formulář s možností přepínat mezi organizacemi a povolit / zakázat režim oddělení:

Když je rozdělení vypnuto, když SessionParameters.OrganizationSeparatorUsage = False, platforma odmítne zapisovat dokumenty a vyhodí chyby jako "SDBL Error: očekávaný výraz (pos=12)", takže nemůžete uživateli umožnit zapisovat dokumenty pomocí této možnosti. Kvůli spolehlivosti jsme vytvořili předplatné události „Před záznamem“ pro objekty, které jsou součástí společného atributu:

If SessionParameters.OrgDelimiterUse = False Then
#If Client Then
Warning("Nelze zapisovat, protože je zakázáno sdílení dat!");
#EndIf
Odmítnutí = pravda;
EndIf;

Náš akční plán byl následující: připravíme konfiguraci přijímače IB č. 1, zapíšeme hodnoty společného atributu = 1, načteme data z IB č. 2, po načtení pro všechny objekty s prázdnou (rovná se 0) hodnota oddělovače, nastavte oddělovač organizace = 2.

Konfigurace byla připravena, vyvstala otázka, jak nastavit hodnotu společného atributu pro doklady a jejich pohyby v uzavřených obdobích a to rychle a bez rizika, že čísla v zůstatku poletí? Prostřednictvím objektového modelu 1C je nemožné napsat oddělovač odděleně od objektu, takže jsem musel porušit licenční smlouvu, abych se dostal ven a napsal dotaz pro MS SQL. Protože ve společném atributu je mnoho objektů a pro tyto objekty je v lícní kosti ještě více tabulek, napsali jsme zpracování, které generuje dotaz pro SQL (pro každý objekt metadat, který je součástí oddělovače, jsme napsali „aktualizace“ + DB_name + ".dbo._" + TableName + " set _" + Field GeneralAttribute + " = 1";)

Hodnota byla nastavena, část dat byla přenesena z IB č. 2 a začalo testování.

Výsledek byl zklamáním. Za prvé, problémy s účetním registrem. Když je oddělení povoleno, analytika není viditelná:

Je to dáno tím, že účetní registr na úrovni DBMS je uložen jako několik tabulek a ne všechny tabulky měly hodnotu společného atributu (pro zobrazení struktury bylo použito zpracování).


Hodnotu separátoru položíme přes MS SQL, vidíme analytiku. Nyní hlášení nefungují. Ukazuje se, že dochází k problémům s dotazy do virtuálních tabulek účetního registru "Obraty" a "ObratyDtKt":

(Fld27033 je pouze běžný atribut v tabulce účetního registru)

Oddělovač je nastaven ve všech tabulkách, je vidět na úrovni DBMS, co by mohla být chyba, není jasné. Nasadíme typické prázdné SCP, provedeme konfigurační změny popsané výše, zadáme pár dokumentů (v této volbě platforma sama zapíše hodnotu oddělovače do všech tabulek účetního registru), ale chyby se reprodukují. Je to špatné, ale vyřazujeme účetní registry z obecných náležitostí, pokračujeme v testování.

Dále se ukazuje, že posuvný mechanismus pro výpočetní registry přestal fungovat. Plány na typy kalkulací jsme neoddělovali, snažíme se hledat problém v tabulkách kalkulačního registru a v přepočtech. Zkontrolujeme, zapíšeme hodnotu hlavního atributu, provedeme T&I - bez úspěchu.

Po cestě diagnostikujeme problém při zápisu informací do nezávislých registrů z formuláře seznamu. V tomto případě jsou data zaznamenána, lze je vidět po restartu. Problém je reprodukován na testovací základně:


Informační registry nebylo možné "opravit" manipulací s SQL (hodnota oddělovače je nastavena ve všech tabulkách), takže byly jednoduše vyloučeny z obecného atributu. Po několika dnech experimentování jsou pokusy o obnovení pracovní kapacity výtlaku rovněž neúspěšné.

V tuto chvíli se rozhodneme vypnout sdílení dat a nadále používat RLS. Při nastavení rozdělení na "nepoužívat" narazíme na chyby "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX ukončen, protože pro index byl nalezen duplicitní klíč...". To znamená, že není tak snadné vrátit se do stavu před rozchodem. Problém s indexy přepočtových tabulek, nastavení pro ukládání součtů a další. Faktem je, že tabulky ukládají stejné řádky, které se liší pouze hodnotou společného atributu. Při odstraňování společného atributu se objeví nejedinečné položky. Nepotřebné záznamy budete muset mazat přímo v MS SQL, něco takového (pro tabulku přepočtu):

uživatelská základna;
ALTER TABLE_CRgRecalc1399
PŘIDAT id INT IDENTITY(1,1);
JÍT
DELETE FROM_CRgRecalc1399
KDE id< (SELECT MAX(id)
OD _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef a
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] a
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] a
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] a
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] a
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
JÍT
ALTER TABLE_CRgRecalc1399
ID SLOUPCE DROP;

A teprve po vyčištění několika desítek tabulek je možné vypnout dělení dat. Po vypnutí separace nejsou žádné problémy.

3. Závěry.

Byla naděje, že problémy 8.3 byly vyřešeny. Nelenili jsme, zkontrolovali jsme 8.3.4.482 (s vypnutým režimem kompatibility). Podívali jsme se na téměř typický SCP-shke se změnami v konfiguraci pouze pro obecné rekvizity. Na této testovací bázi bylo dělení povoleno ještě před zadáním informace, tzn. platforma musela správně zapsat hodnotu oddělovače do všech tabulek, sami nic přímo do MS SQL nezapsali.

Výsledek:

    Problém s dotazy na virtuální tabulky "Turnovers" a "TurnoversDtKt" je reprodukován.

    Problém preempce je reprodukovatelný.

    Problém se zápisem do nezávislých informačních registrů je reprodukován.

    Problém s vypnutím separace - nebude fungovat zbavit se toho jedním kliknutím tlačítka!

Proto se nám nepodařilo nahradit RLS novým mechanismem. Tento mechanismus byl zjevně koncipován pro cloudové služby a v případě použití sdílených dat „nezávisle“ snad oddělení bude fungovat, ale potřebujeme společný NSI. Zbývá vidět, kdy 1C opraví chyby, nebo ještě lépe implementuje typický mechanismus pro dělení podle organizací ve standardních konfiguracích.

Pozornost! Zde je zkušební verze lekce, jejíž materiály nemusí být kompletní.

Přihlaste se jako student

Pro přístup k obsahu školy se přihlaste jako student

Interní programovací jazyk 1C 8.3 pro začínající programátory: formát v 1C

Při programování v 1C musíte často zobrazovat (ve stejných sestavách) hodnoty různé typy(řetězce, data, čísla...). Každá z hodnot má různé reprezentace.

Například stejné datum „01/01/2005“ může být reprezentováno jako řetězec jako:

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

Všechny jsou řetězcové reprezentace stejné hodnoty. pro jehož vytvoření se v 1C používá speciální funkce Formát.

Pomocí funkce Formát v 1C

Zakázat seskupování číslic

Předpokládejme, že chceme vytisknout číslo 10000.

Pokud napíšeme:

Formátovací řetězec se obecně skládá ze dvou částí oddělených rovnítkem. Vlevo od rovná se název nastavovaného parametru (podívejte se do nápovědy nebo příkladů) a vpravo hodnota tohoto parametru.

Ve výše uvedeném příkladu má formátovací řetězec "NG=0" parametr NG a hodnotu 0. Tato kombinace rozdělí číslice čísla. A jak vidíte, nyní je zobrazeno 10 000.

Odstranění úvodních nul

Je také běžným úkolem vypisovat úvodní nuly před číslici. Řekněme například, že chcete zobrazit číslo 5 s úvodní nulou, tedy ve tvaru „05“:

Report(Format(5 , "FH=2; FH=" ) ) ; // výstupy 05

Pojďme analyzovat formátovací řetězec "FZ=2; HVN=". Skládá se ze dvou formátovacích řetězců oddělených středníkem. Pojďme analyzovat každý z nich samostatně.

Řetězec "CHT=2" určuje celkový počet zobrazená desetinná místa celých a zlomkových částí. Celkový počet pozic, které bude číslo při výstupu obsazovat, se tedy bude rovnat 2.

Řetězec "HVN=", jak vyplývá z nápovědy, udává funkci format, že pokud číslo nedosahuje délky deklarované délky (jako v našem případě, protože jsme zadali 2 pozice a 5 zabírá pouze jednu), pak měly by být použity úvodní nuly. Zvláštností tohoto formátovacího řetězce je, že má pouze název parametru a rovnítko, ale nemá žádnou hodnotu. Čtete zkušební verzi lekce, úplné lekce jsou umístěny.

Kombinace dvou formátovacích řetězců nám dává výsledek, který potřebujeme "05", místo "5".

Změňte oddělovač desetinných míst

Předpokládejme, že potřebujeme zobrazit zlomková čísla s oddělovačem hvězdička místo tečky. To znamená, že 25,46 se zobrazí jako "25 * 46":

Formátovací řetězec je parametr DF a hodnota dddd, která označuje funkci Formát výstup dlouhého znázornění dne v týdnu (všimněte si, kolik "d" obsahuje).

Měsíční reprezentace data

Popis měsíce podle data se zobrazí takto:

Report(Format("20050101" , "DF=MMMM" ) ) ; // tiskne leden

Formátovací řetězec má stejný parametr DF jako v předchozím případě. Ale význam je jiný. Nyní je to MMMM.

Udělej test

Spustit test

1. Vrátí se Format("19050505", "DF=MMMM").

2. Naformátujte řetězec změnou oddělovače desetinných míst a celých čísel na ^

3. Aby funkce Format vrátila „00005“ místo 5, je vhodný formátovací řetězec

4. Aby funkce Format vrátila „10 000“ místo 10 000, bude stačit formátovací řetězec

5. Funkce Format vrací hodnotu typu

Obecné rekvizity v 1C 8.3 je objekt metadat platformy, který vám umožňuje používat jeden atribut pro mnoho konfiguračních objektů (adresáře, dokumenty, účtové osnovy atd.). Objekt vznikl především pro usnadnění práce vývojáře a separaci dat.

Obecné podrobnosti byly původně implementovány ve verzi 1C 7.7, ale vývojáři je okamžitě nezahrnuli do platformy 8 verze. Mechanismus společných detailů byl představen vývojáři 1C až ve verzi 8.2.14.

Obecné atributy je velmi vhodné přidat, aby se neměnily standardní objekty v konfiguraci, často je používám spolu s .

Po přidání společného atributu jej lze použít v dotazech a zobrazit na formuláři objektů − navenek se neliší od běžných rekvizit.

Jediným omezením společných atributů je, že je nelze použít v .

Podívejme se na hlavní nastavení a vlastnosti běžných atributů, které se liší od ostatních konfiguračních objektů:

Sloučenina— seznam objektů, pro které bude použit společný atribut, nastavení připomíná nastavení směnného plánu.

Získejte zdarma lekce videa 267 1C:

Automatické použití— nastavení určuje, zda bude použit společný atribut pro ty objekty, které mají v kompozici zadaný režim použití "Automatický".

Oddělení dat Toto nastavení zvážíme samostatně.

Oddělení dat v 1C pomocí společného atributu

Oddělení dat- mechanismus podobný mechanismu. Výkon tohoto mechanismu je však efektivnější a snáze se konfiguruje.

Mechanismus umožňuje konfigurovat zobrazení pouze prvků, které uživatel vidí. Můžete například rozlišovat mezi všemi objekty (dokumenty, adresáře atd.), kde je nainstalována určitá organizace.

Nastavení oddělení dat pomocí běžných detailů 1C

Chcete-li nastavit v obecném atributu, musíte zadat oddělení dat − Rozdělit. Ihned po kliknutí vás systém vyzve k vytvoření výchozích účetních parametrů:

V tomto případě bude nutné specifikovat parametry relace při startu systému, jak to udělat, s příkladem, bylo popsáno v článku.

Tím je nastavení dokončeno – uživatel bude mít přístup pouze k informacím, které jsou uvedeny ve vybraných parametrech relace.

Příklad použití společného atributu

Pojďme analyzovat nastavení obecných podpěr v 1C 8.3 pomocí příkladu konfigurace drátového modelu a podpěr Organizace:

V systému jsou 3 doklady, u kterých je nutné uvést požadovanou organizaci: jedná se o Fakturu, Výdejku, Mzdu.

Nastavení je jednoduché:

  1. Vytvořte nový obecný atribut, zadejte typ — DirectoryLink.Organization.
  2. Ve složení zařizujeme pro naše dokumenty - Použití.

Všechno, nastavení je u konce!

Podívejme se na výsledek:

Systém zobrazuje společný atribut „jako svůj vlastní“: jak v požadavcích, tak v atributech formuláře a na dalších místech. To je takové kouzlo! 🙂

Obecné rekvizity 1C 8.3 nejsou přidány

chyba: Obsah je chráněn!!