Funkce přijímá 3 parametry:

1. FileName - řetězec název databázového souboru.
2. DataTable - tabulka hodnot obsahující data.
3. Popis tabulky - struktura popisující pole a název tabulky.

Pro práci s databází je vytvořeno nám již známé spojení. Po připojení vytvoříme objekt zodpovědný za provádění instrukcí SQL. Dále uspořádáme smyčku přes řádky tabulky hodnot (parametr funkce č. 2) a vnořenou smyčku přes sloupce tabulky. Počítadlo řádků bude použito k indexování řádků. Počítadlo sloupců bude sloužit k vyhledání popisu pole ve struktuře popisu tabulky (parametr č. 3). Procházením sloupců dalšího řádku analyzujeme jejich typy (podle popisu tabulky) a provedeme příslušné transformace. Ve výsledku máme připravený sql příkaz pro zápis řádku do databáze. Aplikujeme přijaté sql instrukce, objekt ADODB.Command. Na konci procesu zavřete připojení a vymažte paměť.

Bohužel se mi na tomto webu nepodařilo připojit zpracování pro tlustého klienta, do kterého lze nahrávat libovolné adresáře přístup k databázi. Ale můžete si jej stáhnout na disku Yandex: http://yadi.sk/d/UzK_PAsJ3vjTS. Toto zpracování zahrnuje všechny části univerzálního vykládacího mechanismu. Tento mechanismus se samozřejmě neomezuje pouze na toto zpracování. Můžete jej bezpečně zkopírovat jak do samostatného modulu, tak do vlastního zpracování. Nevylučuji chybné situace, které by mohly vést k selhání nahrávání, ale nejedná se o komerční projekt. Můžete volně upravovat tento mechanismus aby vyhovoval vašim potřebám. Níže jsou uvedeny 2 přílohy popisující konstanty adox. Doufám, že vám tento mechanismus bude užitečný. Přeji vám úspěch ve vaší profesionální kariéře!

Příloha 1 seznam další vlastnosti přístupová pole tabulky:

AutoIncrement

Nastaví typ pole na "Počítadlo" s hodnotou, která se automaticky zvýší při přidání záznamu.

Výchozí

Výchozí hodnota pole.

Popis

Popis oboru.

Pevná délka

Určuje, zda bude pole pevné délky nebo proměnné.

Přírůstek

Hodnota, o kterou se pole typu čítače zvýší.

S možností nulování

Určuje, zda pole nemůže obsahovat žádnou hodnotu, jinými slovy, zda má být pole povinné.

Semínko

Hodnota, od které začne počítání v prvním záznamu pro pole typu "počítadlo".

Tryska OLEDB: Povolit nulovou délku

Určuje, zda textová pole mohou obsahovat řetězce nulové délky. Ignorováno u polí bez znaků.

Jet OLEDB:AutoGenerate

Určuje, zda se pro pole typu adGUID automaticky vygeneruje nová hodnota GUID.

Jet OLEDB: Pravidlo ověření sloupce

Výraz, který určuje správnost hodnoty zapsané v poli, musí být zapsán ve formátu SQL WHERE, ale bez klíčové slovo KDE.

Jet OLEDB: Text ověření sloupce

Text, který se zobrazí, pokud hodnota zadaná do pole neodpovídá pravidlu definovanému pro toto pole (Pravidlo).

Jet OLEDB: Komprimované řetězce UNICODE

Určuje, zda bude Microsoft Jet komprimovat řetězce UNICODE při zápisu na disk. Ignorováno, pokud databáze není ve formátu Microsoft Jet verze 4.0.

Jet OLEDB:Hyperlink

Určuje, že data v poli jsou hypertextový odkaz. Ignorováno pro pole s jiným typem než adLongVarWChar.

Jet OLEDB:IISAM není poslední sloupec

U Installable-ISAM tato vlastnost informuje I-ISAM, že po tomto sloupci budou přidány další sloupce do tabulky. Pokud používáte ITableDefinition::AddColumn nebo ITableDefinition::CreateTable, je nutné, abyste tuto vlastnost nastavili pro všechny.

Jet OLEDB: Jeden BLOB na stránku

Určuje, zda mají být data uložena na samostatných stránkách (True) nebo zda lze použít sdílené databázové stránky pro úsporu místa na disku. Funguje pouze s poli adLongVarBinary.

Příloha 2 seznam typů hodnot používaných v ADOX

adDouble, typ 5 - zlomkové číslo

adDate, typ 7 - datum/čas

adCurrency, typ 6 - celé číslo

adInteger, typ 3 - celé číslo bez znaménka

adBoolean, typ 11 - boolean

adVarWChar, typ 202 – řetězec unicode dlouhý 255 znaků

adLongVarWChar("memo"), typ 203 - řetězec unicode neomezený řetězec

V tomto článku budeme hovořit o nastavení uživatelských přístupových práv k objektům systému 1C.

V 1C 8 se používá k řízení přístupu uživatelů samostatný objekt metadata, která se nazývá Role.

Poznámka! Tento článek byl napsán, aby pomohl programátorům. Nastavení práv v uživatelském režimu na příkladu 1C Accounting je diskutováno v.

Role definuje sadu práv, která má uživatel. Mechanismus rolí je velmi podobný mechanismům práv Windows Active Directory. Pro každý z objektů (adresáře, dokumenty) nastavuje vývojář vlastní sadu práv - čtení / zápis / přidání / změna / ...

Sada dostupných práv - shromažďování všech oprávnění v uživatelských rolích.

Pokud otevřeme objekt metadat Role, můžeme vidět následující obrázek:

Objekt má dvě záložky – Práva a Šablony omezení. Práva - hlavní záložka, Šablony - záložka pro nastavení práv na úrovni záznamu v 1C ( RLS). Toto je velmi důležité téma, které se pokusím popsat v dalších článcích.

Budeme uvažovat pouze o tab Práva.

• Objekty— seznam, pro který budou nastavena práva.
• Práva— seznam možných nastavení práv pro nastavení.
• Omezení přístupu k datům— pole rolí pro přizpůsobení

Věnujte prosím pozornost zaškrtávacím políčkům ve spodní části:

• Nastavte práva pro nové objekty— je-li pro roli nastaven příznak, budou automaticky nastavena permisivní práva pro nové objekty metadat. Doporučuji nainstalovat, pokud často zapomínáte nastavit oprávnění pro nové objekty.
• Nastavte práva pro podrobnosti a tabulkové části výchozí— příznak, pokud je nastaven, detaily a tabulkové části zdědí práva vlastníka (adresář, dokument atd.)
• Nezávislá práva podřízených objektů— pokud je nastaven příznak, pak systém vezme v úvahu práva k nadřazenému objektu při určování práv ke konfiguračnímu objektu

Nastavení oprávnění pro celou konfiguraci

Pokud otevřeme Role a klikneme na kořen konfigurace, uvidíme následující nastavení:

Více podrobností o každém z nich práva na celou konfiguraci:

Získejte 267 videolekcí na 1C zdarma:

• Správa— administrativa informační základna(vyžaduje právo „Správa dat“)
• Správa dat— právo na administrativní úkony týkající se údajů
• Aktualizace konfigurace databáze- právo na
• Monopolní režim— použití exkluzivního režimu
• Aktivní uživatelé— zobrazit seznam aktivních uživatelů
• — kniha jízd
• - spustit vpravo tenký klient
• - právo na spuštění webového klienta
• Tlustý klient— přímo do role spuštění tlustého klienta
• Vnější spoj— právo zahájit externí připojení
• Automatizace— právo používat automatizaci
• Režim všech funkcí— v režimu řízené aplikace
• Ukládání uživatelských dat— povolení nebo zákaz ukládání uživatelských dat (nastavení, oblíbené položky, historie). To platí zejména pro spravované formuláře 1C.
• Interaktivní objevování vnější ošetření — otevření externího zpracování
• Interaktivní otevírání externích reportů— otevírání externích zpráv
• Závěr— tisk, záznam a kopírování do schránky

Nastavení práv 1C 8.2 k dalším objektům metadat

Pro ostatní hlavní objekty (adresáře, konstanty, dokumenty, registry...) je sada práv pro roli zcela standardní:

• Čtení- čtení (software)
• Přidání- přidání (softwaru)
• Změna- změnit (software)
• Odstranění- odstranění (software)
• Pohled- Pohled
• Interaktivní doplněk- interaktivní doplněk
• Editace— editace
• Interaktivní příznak smazání— interaktivní značka pro smazání
• Interaktivně zrušte označení smazání— zrušení označení pro smazání
• Interaktivní odstranění označených— mazání označených objektů
• Linkový vstup— pomocí režimu řádkového vstupu
• Interaktivní odstranění— přímé smazání (shift + del)

Práva pouze pro dokumenty:

• Interaktivní dirigování— provádění
• Zrušení— zrušení dokladů
• Interaktivní vedení neoperativní— držení (pomocí standardních formulářových příkazů) dokumentu v neprovozním režimu
• Interaktivní zrušení— interaktivní zrušení
• Interaktivní změna útraty— úprava odeslaného dokumentu. Pokud není nastaveno právo role, uživatel nemůže odstranit zaúčtovaný dokument, nastavit příznak odstranění, znovu jej odeslat nebo jej zrušit. Formulář takového dokumentu se otevře v režimu prohlížení

P.S. Pokud stále nemůžete zjistit uživatelské role, můžete si objednat .
Video s příkladem nastavení práv v 1C Accounting 3.0:

Nedávno jsem potřeboval stáhnout všechna data z jedné jednoduché Access databáze do vlastní konfigurace (1C:Enterprise. Nebylo mnoho informací k přenosu a v zásadě bylo možné tento fascinující proces přenést na uživatele, ale Rozhodl jsem se pomoci svým již tak vytíženým zaměstnancům.

Pomoc spočívala v kompletní automatizaci tohoto procesu. Musel jsem napsat jednoduché zpracování, které vše udělalo během pár sekund. Před tímto úkolem jsem nemusel pracovat s kombinací 1C + Access, takže než jsem popadl klávesnici a začal plácat kód, rozhodl jsem se přečíst si manuály.

Od samého začátku jsem věděl, že veškerá interakce bude zahrnovat použití příslušných poskytovatelů, ale přesto jsem se rozhodl prozkoumat příklady.

Dlouho jsem přemýšlel, v jakém duchu tuto poznámku napsat. Nakonec jsem se zastavil u samého jednoduchá verze– uveďte kód mého řešení. I když to není příliš optimální, pro většinu úkolů je více než dostačující.

Začněme se tedy na vše dívat popořadě. Vytvoříme nové zpracování a hodíme na něj jedinou komponentu – „TableField“. Tuto komponentu jsem natáhl přes celý formulář. Výsledkem je, že moje forma vypadala jako na obrázku 1.

Obrázek 1. Formulář pro zpracování

V tomto okamžiku můžeme předpokládat, že návrh formuláře je připraven. Sloupce nebudeme vytvářet ručně, ale tento postup provedeme dynamicky. Naštěstí to není nic těžkého. Vytvořte obslužnou rutinu události „Při kliknutí“ pro tlačítko „Spustit“ a napište do něj následující kód:

//Vymažte pole tabulky TableField1.Clear(); TableField1.Columns.Clear(); //Příprava připojovacího řetězce pro MS Access //Cesta k databázi je uvedena úplně na konci Connection string = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="+"C:\mydb.mdb"; ConnectionWithBase = Nový COMObject("ADODB.Connection"); //Connect ConnectionWithBase.Open(ConnectionString); //Získejte sadu záznamů z tabulky demo_tableRecords Collection = New COMObject("ADODB.Recordset"); RecordsCollection.Open("vybrat * z demo_tabulky", DatabaseConnection, 1); //přečtěte si strukturu polí tabulky //V tabulce hodnot vytvořte všechny sloupce, které jsou v Access tabulce For count = 0 podle Records Collection.Fields.Count - 1 cyklus TableField1.Columns.Add("Column" + počet, Řádek(Sbírka záznamů .Pole.Položka (počet).Název)); (TableField1.Columns[počet].Value; EndCycle.MoveNext(); Konec cyklu; //Zobrazení dat ze specifikace v TableFieldFormElements.TableField1.Value = TableFormElements.TableField1.CreateColumns();

Ukázalo se, že kód není příliš velký, ale docela užitečný. Nedělal jsem žádné vazby na konkrétní strukturu. Kód funguje skvěle na široké škále tabulek. Víc k tomu nemám co dodat, tak se loučím

Zkrátka – v žádném případě. Ve všem, co souvisí s interakcí s vládními úřady (ať už jde o daně, účetní výkaznictví, nejrůznější spotřební daně atd.), nelze 1C ničím nahradit a snažit se o to je přinejmenším nekonstruktivní.

Ale nepřestávejte číst tento článek, to není hlavní myšlenka. Hlavní věcí je nespadnout do logické pasti a považovat 1C za zcela nepostradatelné v jakékoli části automatizace všech procesů v podniku. Zde je o čem polemizovat a co nabídnout. Chci mluvit o jedné úspěšné zkušenosti s automatizací různých aspektů obchodních aktivit počítačové společnosti a samozřejmě o propojení tohoto řešení s 1C. Práce vyrostla z potřeby propojit vlastní vyvinutý systém s programem 1C, ale tento přístup (rozdělení do 2 programových bloků) lze rozvinout v plnohodnotnou filozofii budování informačního systému obecně.

Úkol byl zpočátku následující. Byl tam napsán podnikový automatizační systém Microsoft Access. Za mnoho let svého vývoje pohltil téměř všechny každodenní úkony - vedení banky, vystavování faktur, příprava účetních dokladů k expedici, údržba skladu, účtování komponentů sériová čísla, vypracování technologických map pro výrobu atp. V poslední době byly do možností systému přidány následující doplňky: vytváření bankovních plateb přímo na základě došlých faktur, automatické generování ceníky v různých formátech pro zveřejnění na webových zdrojích, aktualizaci webových stránek společnosti a přípravu smluv na základě existujících šablon (tzv. automatizace kanceláří). Plus přítomnost velkého množství analýz a vedení veškerého manažerského účetnictví. To vše učinilo systém zcela nenahraditelným - přenesení všech těchto funkcí do 1C by zabralo spoustu času a peněz.

Na druhou stranu program 1C-Enterprise sloužil pouze pro potřeby účetního oddělení pro vedení účetnictví a účetních záznamů a podávání zpráv. Tím byl 1C „odvázán“ z každodenního fungování společnosti a hotové dokumenty byly do databáze vloženy a posteriori.

Co je na tomto schématu dobrého? Existuje několik výhod:
- vyloučení manažerů a dalších (ne)zodpovědných osob ze „svatyně svatých“ - účetní databáze, kterou by měli tvořit pouze zaměstnanci, kteří tématu rozumí; přesné vedení adresářů,
- odstranění z 1C všeho, co s tím nesouvisí: od manažerských úkolů, které nevyžadují reflexi v účetnictví, po všechny ostatní body, které jsou specifické pro společnost a ke kterým by neměly mít přístup cizí osoby,
- úspory na licencích: pracovní stanice 1C stojí značné peníze,
- důležitý bod: při implementaci všech výše popsaných doplňkových funkcí přímo „uvnitř“ 1C existuje neustálá potřeba jejich zlepšování, když jsou vydány aktualizace produktu. To samozřejmě zaručuje téměř konstantní zaměstnání pro programátory 1C, ale je to místo, kde můžete výrazně ušetřit.

No a velkým mínusem je samozřejmě nutnost dvojité kontroly všech dokumentů a aktualizace adresářů.

Vlastně to byl hlavní úkol – dostat se pryč od dvojí práce.

Nejprve se musíte vypořádat se všemi druhy adresářů - v první řadě je to adresář dodavatelů a položek. Problém synchronizace adresářů, který u programů tohoto druhu tak často vyvstává, je dostatečně propracován a je při implementaci pochopitelný. V tomto případě však bylo učiněno rázné rozhodnutí nepoužívat 2 adresáře se vzájemnou synchronizací, ale mít jednu počáteční verzi - tu zadanou v MS Access a jednoduše ji replikovat v 1C ( Zpětná vazba- jedná se pouze o označení v MS Access, že tato pozice již byla uvolněna).
Tento přístup značně zjednodušuje úkol. Pro čistě účetní potřeby potřebujete v takových adresářích velmi málo pozic – a navíc se zadávají v externím programu, aby nedošlo k porušení formulovaného principu. Je tak možné eliminovat další častý problém – nesmírnou nabubřelost referenční knihy použité nomenklatury. Níže je uvedena skupina produktů „Monitory“

Načítání takové hrůzy do adresáře 1C (a nové modely monitorů se objevují téměř každý týden) lze nakonfigurovat tak, aby všechny spadly do jedné polohy, protože nuance barvy rámu kolem obrazovky a počet pixelů jsou pro účetnictví zcela bezvýznamné! A upřímně řečeno, velikost úhlopříčky je ještě větší, pokud se liší o půl palce.

Dále v externím programu můžete vyřešit sloučení duplicitních pozic v adresářích, zejména v adresáři protistran, s mnohem menšími ztrátami, protože v 1C to trvá velký počet snaha.

Do 1C se tedy nahrávají pouze „rafinovaná“, vyčištěná a převedená data do správné formy. Vykládání lze provádět s určitou frekvencí - porcování vám umožňuje odladit práci účetního oddělení a vyhnout se zbytečné práci, pokud během dne (nebo delšího období) bylo něco zrušeno, změněno, provedeno znovu - všechny tyto věci se dějí v pracovním procesu Databáze MS Access a pouze „zřízena“ „Stav věcí je hlášen 1C. Navíc lze tento druh vykládání synchronizovat s operacemi zálohování a vždy si můžete být jisti, že aktuální stav databáze 1C je správný.

Je jasné, že dokumenty přicházejí bez automatického zaúčtování (i když to lze nakonfigurovat). Mimochodem, samotná databáze MS Access kontroluje dostupnost potřebného zboží na skladě - pro odepisování k expedici (dilema je ujistit se, že faktura může být vystavena dnešní datumže všechny položky nutné k odpisu jsou na skladě - tedy nakoupené nebo vyrobené - potřebujete... doklad zaúčtovat v 1C. Zjevně byste to neměli věřit manažerům - nebo účetní zaměstnanec by měl vždy stát za manažerem)

Nyní o implementaci. Programy 1C podporují rozhraní pro výměnu dat prostřednictvím mechanismu ADO. Na straně 1C se k vytváření prvků referenčních knih a dokumentů používá standardní softwarové rozhraní, takže fungování tohoto mechanismu nezávisí na interních detailech implementace 1C, které se mohou měnit od verze k verzi a od aktualizace k aktualizaci. . Na druhou stranu, hlavním vývojovým sloganem bylo „maximálně využít schopnosti 1C, kde je to možné“. V konečné implementaci balíčku se proto z MS Access načetlo pouze jméno a DIČ protistrany - data byla „vytažena“ z Jednotného státního rejstříku právnických osob a fyzických osob pomocí mechanismu zabudovaného do 1C (tzv. totéž platí pro bankovní detaily– jsou aktualizovány pomocí BIC).

v vnější základna Byly vytvořeny MS Access dotazy (Query), které připraví všechna potřebná data pro načtení do 1C - vezměte je a uspořádejte do dokumentů a polí.

Schéma vykládky se skládá ze dvou fází. Nejprve se načtou nové pozice v adresářích protistran a položek. GUID přiřazená k 1C se vrátí do MS Access, takže při nahrávání všech dokumentů ve druhé fázi lze nastavit správné odkazy na adresáře. Vypadá to takhle

Věříme, že taková ideologie stavby informační systémy lze vzít za základ nejen v těch společnostech, kde existují starší systémy non-1C, ale také při organizaci práce nových právnické osoby, protože máme bohaté zkušenosti s MS Access. Výhody tohoto přístupu jsou popsány výše.