Механизъм за разделяне на данни 1s. Използване на механизъм за споделяне на данни вместо RLS

внимание! Ето пробна версия на урока, чиито материали може да не са пълни.

Влезте като студент

Влезте като ученик за достъп до училищно съдържание

Вътрешен език за програмиране 1C 8.3 за начинаещи програмисти: формат в 1C

Когато програмирате в 1C, често трябва да показвате (в едни и същи отчети) стойности от различни типове (низове, дати, числа ...). Всяка от стойностите има различни представяния.

Например същата дата "01/01/2005" може да бъде представена като низ като:

1. "01.01.2005"
2. "1 януари 2005 г."
3. "01.01.05"

Всички те са низови представяния с една и съща стойност.за формирането на които в 1C се използва специална функция формат.

Използване на функцията Format в 1C

Деактивирайте групирането на цифри

Да предположим, че искаме да отпечатаме числото 10000.

Ако напишем:

Форматиращият низ обикновено се състои от две части, разделени със знак за равенство. Вляво от равни е името на зададения параметър (вижте в помощта или примерите), а вдясно е стойността на този параметър.

В примера по-горе форматиращият низ "NG=0" има параметър NG и стойност 0. Тази комбинация разгрупира цифрите на числото. И както можете да видите, сега се показва 10 000.

Премахване на водещи нули

Също така обичайна задача е извеждането на водещи нули преди цифра. Например, да приемем, че искате да покажете числото 5 с водеща нула, тоест под формата на "05":

Нека анализираме форматиращия низ "FZ=2; HVN=". Състои се от два форматиращи низа, разделени с точка и запетая. Нека анализираме всеки от тях поотделно.

Редът "CHT=2" задава общия брой показани десетични знаци за целите и дробните части. Така общият брой позиции, които числото ще заеме при извеждане ще бъде равен на 2.

Низът "HVN=", както следва от помощта, показва на функцията за форматиране, че ако числото не достигне декларираната дължина по дължина (както в нашия случай, защото посочихме 2 позиции, а 5 заема само една), тогава трябва да се използват водещи нули. Особеността на този форматен низ е, че има само името на параметъра и знак за равенство, но няма стойност. Четете пробна версия на урока, намират се пълни уроци.

Комбинацията от два форматиращи низа ни дава резултата, от който се нуждаем "05", вместо "5".

Променете десетичния разделител

Да предположим, че трябва да покажем дробни числа с разделител със звездичка вместо точка. Това означава, че 25,46 се показва като "25 * 46":

Форматиращият низ е параметърът DF и стойността dddd, която показва функцията форматизведе дълго представяне на деня от седмицата (забележете колко "d" съдържа).

Месечно представяне на дата

Описанието на месеца по дата се показва, както следва:

Форматиращият низ има същия DF параметър, както в предишния случай. Но смисълът е друг. Сега е ММММ.

Направете теста

Стартирайте теста

1. Format("19050505", "DF=MMMM") ще се върне

2. Форматирайте низ, като промените десетичния и целочисления разделител на ^

3. За да върне функцията Format "00005" вместо 5, форматиращият низ е подходящ

4. За да върне функцията Format "10 000" вместо 10 000, низът за форматиране ще свърши работа

5. Функцията Format връща стойност от тип

Механизъм за споделяне на данниви позволява да съхранявате данни на няколко независими организации в една информационна база.

Това става възможно благодарение на факта, че общите атрибути на конфигурационните обекти могат да се използват не само като "един и същ атрибут, който имат всички обекти", но и като идентификатор, че данните принадлежат към една от няколко независими области. Това може да се обясни със следния пример.

Да предположим, че в конфигурацията има общ атрибут "Организация". Това означава (опростено), че всяка директория, документ или друг конфигурационен обект също ще има атрибута "Организация".

В същото време всеки потребител на информационната база има достъп до всички данни, съхранявани в тази база данни, независимо коя организация е посочена, например в конкретен документ.

Сега нека уточним, че общият атрибут "Организация" ще бъде разделител.

След това (опростено) в информационната база ще бъдат създадени няколко независими области с данни, всяка от които ще съхранява данни само за една конкретна организация:

Сега, влизайки в програмата, потребителят няма да получи достъп до цялата информация, която се намира в информационната база, а само до данните от "неговата" област, в този случай до документи, директории и т.н. на неговата организация.

Възможен е и друг вариант на използване на този механизъм, когато в информационната база има няколко независими области с данни и заедно с това има данни, които са достъпни за всички потребители на програмата. Например те съдържат директория на банките, която е еднаква за всички организации.

В този случай потребителят има достъп до "своята" област с данни и до несподелената област с данни, която е обща за всички потребители.

Механизмът за споделяне на данни е доста гъвкав и универсален:

• ви позволява да използвате не един, а няколко разделителя;
• има различни режими на използване на споделени данни; те се различават по начина, по който се обработва ситуацията, когато стойността на разделителя не е посочена;
• използването на общ атрибут като разделител може да се контролира по време на работа на програмата от вградения език, без да се променя конфигурацията; това се нарича условно разделяне.

[Бутон 7710967300 BUX RB] Connect=Srvr="%servername%";Ref="%base_name%"; Допълнителни параметри=/Z "-0,-0,+7710967300";

След /Z уточняваме общите подробности по ред. Тъй като нашето стандартно счетоводство вече има два общи системни детайла, за тях посочваме стойност -0, за да не се използват, а като трети (който създадохме) подаваме TIN.

1000 и 1 отметка

Оставяме избора на параметри на Вашата преценка, преценка и среда. Ето нашата версия (внимавайте, има 20 000 пиксела).

Разделителят също така дава възможност да се създаде отделен списък с потребители за всяка база данни - това може да бъде полезно, ако имате стотици потребители - когато влезете в определена база данни, не е нужно да превъртате този списък до кървави мазоли. Ние не използваме това, защото сме настроили прозрачно разрешение.

Качване на данни от текущи бази данни

Забележка към домакинята: по-добре е да качвате директории и документи отделно - по този начин можете да избегнете ненужни грешки по време на качването.

Зареждане на данни в споделена база данни

За да опростим задачата, ние извършваме групови качвания, след като стартираме леко коригирана стандартна обработка през командния ред (/Execute c:\upload.epf). След това ръчно качваме получените файлове в споделената база данни.

Как да прекарваме повече време, за да прекарваме по-малко време

Счетоводителите не забелязват прехода на организациите от редовна база към разделена, за тях процесът е безболезнен. Бут гори само за админи :)

Странични ефекти: спестяване на място 1 към 20, индиректно увеличаване на скоростта - безценно. В абсолютно изражение 50 организации заемат 2 GB пространство в SQL, докато една отделна база данни заема 800 MB.

Обещаната муха в мехлема, дори четири:

• ако някой от потребителите е объркал данните в една организация, трябва да върнете цялата разделена база данни - не можете просто да вземете и върнете назад една област с данни
• трябва да тествате актуализациите по-задълбочено, особено тези, които добавят или променят директории
• ако трябва да прехвърлите базата данни на клиента (или да обедините данъчната :), трябва да направите обратната процедура: разтоварете организацията от разделената база данни с помощта на универсалния обмен, след това я заредете в празна обикновена база данни и запишете от то да. dt файл
• в разделена база данни е невъзможно да се управляват планирани задачи (например няма да е възможно автоматично да се актуализират обменните курсове)

Разделителният елемент 1C е необходим, за да се преразпределят зоните на формата, тъй като е удобно за потребителя в момента. Почти всеки потребител на Windows има умението да използва разделители. Да приемем, че сте създали проста форма с две контроли.

Традиционно елементите от всеки списък могат да бъдат разположени от лявата страна. От дясната страна, съответно, има подробна спецификация на тези точки. Ако левият списък се състои от кратки имена, логично е тази колона да се намали до минимум. Съответно в този случай четливостта на дясната страна ще се увеличи. И обратното, ако има дълги имена от лявата страна, колоната трябва да се разшири. Разделителите позволяват на потребителя да персонализира произволно формата, като просто плъзне границата с мишката.

Този контролен метод се използва при редактиране на таблици в Word и Excel. Когато създавате формуляр, можете да създадете както вертикален, така и хоризонтален разделителен елемент на формуляр. Като цяло, най-предпочитано е да създавате форми, които са визуално в рамките на екрана.

Разделител 8.2, 8.3 (управлявани форми)

Не можете да добавите разделител в управлявана форма 1c, той се добавя автоматично от програмата преди / след полето на таблицата

1. Преамбюл.

Възникна необходимост от организиране на счетоводство за две организации в една ИС. Ситуацията не е уникална, но се случи така, че нашият много нетипичен 250 GB UPP работи доста бавно, така че вместо RLS решихме да опитаме разделяне на данни. Какво представлява е описано например или. Накратко, ако RLS обуславя SQL заявки, тогава разделителят на данни е допълнителна колона в таблици на ниво СУБД, при което механизмът на разделителя трябва да е по-бърз от RLS.

И така, в базата данни, където се водят записи за ООО № 1, е необходимо да се прехвърли информация от отделна база данни на ООО № 2 и да се организира съвместна работа. Точно като на снимката:

Простосмъртните работят само със своето LLC, а главният счетоводител понякога преглежда данни за две юридически лица. В режим на достъп до двете LLC можете само да четете данни, така че главният счетоводител трябва да може интерактивно да превключва между режимите „четене на всички“ / „запис само за една организация“ и да избира LLC (т.е. да зададе стойността на общ атрибут), за да извършите например изчисляване на разходите.

2. Внедряване

Платформа 8.2.19.90, без режим на съвместимост. СУБД - MSSQL Server 2008 R2 Standard.

Създадохме общ атрибут Организационен разделител от типа "номер", съгласихме се с предложението за създаване на параметри на сесията, попълнени в състава на атрибута (включени няколко директории, всички документи, регистри за натрупване, счетоводство и изчисление). Разделяне на данни - "Самостоятелно и съвместно". Стойността на параметъра на сесията се задава от потребителските настройки по подразбиране в процедурата SetSessionParameters в модула на сесията:

Организация = UserManagement.GetDefaultValue(glCurrentUser,"MainOrganization");
SessionParameters.OrgDelimiterValue = Организация.DelimiterValue;

В интерфейса на главния счетоводител те направиха формуляр с възможност за превключване между организации и активиране / деактивиране на режима на разделяне:

При деактивирано разделяне, когато SessionParameters.OrganizationSeparatorUse = False, платформата отказва да пише документи, изхвърляйки грешки като „SDBL грешка: очакван израз (pos=12)“, така че не можете да позволите на потребителя да пише документи в тази опция. За надеждност създадохме абонаменти за събитието „Преди запис“ за обектите, които са част от общия атрибут:

Ако SessionParameters.OrgDelimiterUse = False Тогава
#Ако клиент тогава
Предупреждение ("Не може да се пише, защото споделянето на данни е деактивирано!");
#EndIf
Отхвърляне = вярно;
EndIf;

Нашият план за действие беше следният: подготвяме конфигурацията на приемника на IB № 1, записваме стойностите на общия атрибут = 1, зареждаме данни от IB № 2, след зареждане за всички обекти с празно (равно на 0) стойност на разделител, задайте Организационен разделител = 2.

Конфигурацията беше подготвена, възникна въпросът как да се зададе стойността на общия атрибут за документи и техните движения в затворени периоди и бързо и без риск числата в баланса да летят? Чрез обектния модел 1C е невъзможно да напиша разделител отделно от обекта, така че трябваше да наруша лицензионното споразумение, за да изляза и да напиша заявка за MS SQL. Тъй като има много обекти в общия атрибут и има още повече таблици в скулата за тези обекти, написахме обработка, която генерира заявка за SQL (за всеки обект на метаданни, който е част от разделителя, написахме „актуализация“ + DB_name + ".dbo._" + TableName + " set _" + Поле GeneralAttribute + " = 1";)

Стойността беше зададена, част от данните бяха прехвърлени от IB № 2 и тестването започна.

Резултатът беше разочароващ. Първо, проблеми със счетоводния регистър. Когато разделянето е активирано, анализите не се виждат:

Това се дължи на факта, че счетоводният регистър на ниво СУБД се съхранява като няколко таблици и не всички таблици имат стойност на общ атрибут (обработката е използвана за преглед на структурата).

Е, записваме стойността на разделителя чрез MS SQL, виждаме анализа. Сега отчетите не работят. Оказва се, че има проблеми със заявки към виртуалните таблици на счетоводния регистър "Обороти" и "ОборотиDtKt":

(Fld27033 е просто общ атрибут в таблицата на счетоводния регистър)

Разделителят е зададен във всички таблици, вижда се на ниво СУБД, какво може да е грешка, не е ясно. Разполагаме типичен празен SCP, правим конфигурационните промени, описани по-горе, въвеждаме няколко документа (в тази опция самата платформа задава стойността на разделителя във всички таблици на счетоводни регистри), но грешките се възпроизвеждат. Лошо е, но ние изключваме счетоводните регистри от общите реквизити, продължаваме да тестваме.

Освен това се оказва, че механизмът за изместване на изчислителните регистри е спрял да работи. Не сме отделяли планове за видове изчисления, опитваме се да търсим проблем в таблиците на регистъра на изчисленията и в преизчисленията. Проверяваме, записваме стойността на основния атрибут, правим T&I - без резултат.

По пътя ние диагностицираме проблема, когато записваме информация в независими регистри от формата на списък. В този случай данните се записват, те могат да се видят след рестартиране. Проблемът се възпроизвежда на тестовата база:

Информационните регистри не могат да бъдат "поправени" чрез манипулиране на SQL (стойността на разделителя е зададена във всички таблици), така че те просто бяха изключени от общия атрибут. След няколкодневни експерименти опитите за възстановяване на работоспособността на изместването също са неуспешни.

В този момент решаваме да изключим споделянето на данни и да продължим да използваме RLS. Когато зададете разделянето на „не използвайте“, срещаме грешки „Microsoft OLE DB доставчик за SQL Server: CREATE UNIQUE INDEX прекъснато, тъй като дублиран ключ беше намерен за индекс...“. Тоест не е толкова лесно да се върнете към състоянието преди раздялата. Проблем с индекси на таблици за преизчисление, настройки за съхранение на суми и други. Факт е, че таблиците съхраняват идентични редове, които се различават само по стойността на общия атрибут. При изтриване на общ атрибут се появяват неуникални записи. Ще трябва да изтриете ненужните записи директно в MS SQL, нещо подобно (за таблицата за преизчисляване):

база за използване;
ALTER TABLE_CRgRecalc1399
ADD id INT IDENTITY(1,1);
ОТИВАМ
ИЗТРИВАНЕ FROM_CRgRecalc1399
WHERE id< (SELECT MAX(id)
ОТ _CRgRecalc1399 КАТО T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef и
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] и
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] и
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] и
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] и
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
ОТИВАМ
ALTER TABLE_CRgRecalc1399
ПУСКАНЕ НА КОЛОНА id;

И само след почистване на няколко десетки таблици е възможно да изключите разделянето на данни. След изключване на разделянето няма проблеми.

3. Изводи.

Имаше надежда, че 8.3 проблеми са решени. Не бяхме твърде мързеливи, проверихме на 8.3.4.482 (с деактивиран режим на съвместимост). Разгледахме почти типичен SCP-shke, с промени в конфигурацията само за общите подпори. На тази тестова база разделянето беше активирано преди въвеждането на информация, т.е. платформата трябваше да напише правилно стойността на разделителя на всички таблици, те не записаха нищо директно в MS SQL самостоятелно.

Резултат:

Възпроизвежда се проблемът със заявки към виртуалните таблици "Обороти" и "ОборотиDtKt".

Проблемът с изпреварването е възпроизводим.

Възпроизвежда се проблемът с записването в независими информационни регистри.

Проблемът с изключването на разделянето - няма да работи да се отървете от него с едно щракване на бутона!

Така не успяхме да заменим RLS с нов механизъм. Този механизъм е замислен, очевидно, за облачни услуги и в случай на използване на споделени данни „независимо“, може би разделянето ще работи, но имаме нужда от общ NSI. Остава да изчакаме 1C да коригира грешките и още по-добре да внедри типичен механизъм за разделяне по организации в стандартни конфигурации.