gifts2017

Прямые запросы и вставка данных в таблицы 1С 8

Опубликовал Василий Казьмин (awk) в раздел Программирование - Теория программирования

Прямая запись в базы данных 1С

Поводом для этой статьи стал комментарий цитирую:

 

Трактор 05.12.2009 00:32:59

  1. Ненадо приписывать web сервисам несуществующие минусы.
    >> 1. Не кроссплатформенно
    B под линуксом и под виндовсом работают прекрасно. На FreeBSD ты сам говоришь тоже работают.

    >> 1С ключезависимо (дорого).
    web сервисы не проверяют наличие ключа. http://infostart.ru/forum/messages/fo...sage330063


    При прямом доступе в базу 1С писать нельзя однозначно. Иначе рискуешь огрести кучу неприятностей.
    - оперативная отметка времени (ее значение должно быть уникальным, а в рассматриваемом случае может оказаться не уникальным);
    - полнотекстовый поиск будет работать неверно;
    - неуникальность номеров и кодов практически гарантирована;
    - блокировки объектов (используются в методе Заблокировать прикладных объектов 1С:Предприятия и при их редактировании в диалогах);


    Кроме того при прямом доступе недоступен весь функционал 1С. Например в поле Представление адреса в регистре контактной информации это самое представление нужно писать в том виде в каком его возвращает функция глобального модуля, иначе адрес будет трактоваться как иностранный.
    Придётся дублировать часть функционала 1С на сайте. А это гемор.

  2.  

 

Он доступен здесь: http://infostart.ru/public/62143/?PAGEN_1=1

 

Попробую опровергнуть по пунктам, но сначала я хочу предупредить: НИКОГДА НЕ ДЕЛАЙТЕ ТО В ЧЁМ НЕ УВЕРЕНЫ!!!

 

  1. При прямом доступе нельзя писать однозначно.

  2. Оперативная отметка не будет уникальной.

  3. Полнотекстовый поиск будет работать не верно.

  4. Не уникальность кодов и номеров.

  5. Блокировки объектов при записи в базу.

  6. Недоступен функционал.

 

Первый пункт о невозможности записи. В большинство баз данных писать можно. Для этого существует операторы INSERT и UPDATE. Неприятности мы можем получить и при не правильном конфигурировании 1С.

 

Второй пункт это вообще интересно. Как формируется ссылка 1С. Это GUID записанный в базу в двоичном виде. Простите за отклонение от темы, но почему его нельзя было писать в нормальном виде, а не bytea(16), я не знаю. Что же такое GUID? GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (3,4028×10^38), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, достаточно мала. Хотя три прецедента уже были.

Структура идентификатора:

 GUID STRUCT
Data1 dd
Data2 dw
Data3 dw
Data4 dw
Data5 db 6
GUID ENDS

Например, '22345200-abe8-4f60-90c8-0d43c5f6c0f6' соответствует шестнадцатеричному 128-битному числу 0x00523422E8AB604F90C80D43C5F6C0F6

Таким образом правильно сгенерированный GUID будет уникален с достаточно большой долей вероятности.

Как же его пишет 1С? Я в интернете нашел только одну страницу. http://www.itland.ru/forum/lofiversion/index.php/t8595.html. То есть генерируя ссылку 1С мы должны сначала GUID вида 22345200-abe8-4f60-90c8-0d43c5f6c0f6 преобразовывать к виду 90c80d43c5f6c0f64f60abe822345200 и только потом в binary(16). И здесь я должен извиниться за отсутствие кода. Вариантов реализации очень много, а алгоритм не мой, и разрешения на его использования в данной статье у меня нет.

Перейдем к третьему пункту. Полнотекстовый поиск будет работать верно, если мы строки будем вставлять в базу данных в правильной кодировке.

Четвертое. Как же нам добиться уникальности номера? И надо ли? Во первых не все документы и справочники должны иметь уникальные номера и коды. А во вторых не вижу причин что бы не проверить перед записью в базу данных какие номера уникальны, а какие нет.

 

Например:

 

...

 

CREATE TABLE #temp(code as varchar(9))

 

...

INSERT INTO #temp values(...)

...

 

SET @C = SELECT COUNT(*)

FROM _ReferenceXXX

INNER JOIN #temp

ON #temp.code = ReferenceXXX.code

 

IF @C <> 0 THEN ...

ELSE ...

 

Пятое. Блокировки. Тут выбор настолько велик, что надо читать документацию и выбирать. Как вариант почитать http://www.cybersecurity.ru/manuals/data/mysql/1924.html.

И только шестой пункт я опровергать не буду. Это не оспоримо. Функционал доступный вне 1С гораздо богаче. Но если нужен функционал 1С, возьмите 1С. Зачем пытаться скальпелем валить деревья? 1С подходит в 90% случаев. Более того скорость разработки с ее помощью ОЧЕНЬ высока. Поэтому прибегать к чему-то нестандартному надо только в КРАЙНИХ случаях. С каждой версией 1С таких случаев все меньше.

Однако 2 часа ночи и пора спать. Спасибо Трактору — 90% статьи его.

 

P.S.

Добравшись до работы, я таки решил проверить как это работает. Написав Функцию для постгреса:

CREATE OR REPLACE function guid_to_bytea(text)
RETURNS text AS $$
    my ($s1,$s2,$s3,$s4,$s5) = split('-',$_[0],5);
    my @guid = split('',"\U$s4$s5$s3$s2$s1\E");
    my $result = "";
    for($i = 0 ; $i < $#guid ; $i++) {
        $result .= "\\".sprintf("%03o",hex("0x$guid[$i]$guid[$i+1]"));
        $i++;
    }

   return $result;
$$ LANGUAGE plperl;

 

Я вставил запись в справочник:

 

INSERT INTO _reference7(
            _idrref, _marked, _ismetadata, _code, _description)
    VALUES (guid_to_bytea('22345200-abe8-4f60-90c8-0d43c5f6c0f6')::bytea, false, false, '000000002', 'query');

Потом создал новый элемент в 1С. Был приятно удивлен. 1С действительно не контролирует вставку данных в свою базу. Так что если будете вставлять напрямую данные, то за нумерацию и уникальность придется нести ответственность вам. Осталось проверить блокировки.

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Трактор Трактор (Трактор) 06.12.09 12:32
Думаю что это скорее статья в блоге, чем публикация.
Хочу сказать что большинство обсуждаемых пунктов сформулированы не мной, а разработчиком платформы 1С. http://partners.v8.1c.ru/forum/thread.jsp?id=557242#558206 Я их лишь немного привёл к виду, подходящему к случаю.
Разработчик давал комментарии по поводу одновременной работы нескольких кластеров 1С с одной базой данных. Практически это возможно, но не одобряется 1С. Вот дословная цитата:
При обращении к одной базе данных из нескольких регистраций информационной базы (из нескольких кластеров) возможна неверная работа механизмов, за которые отвечает менеджер кластера. Кроме нумерации к ним относятся:
- оперативная отметка времени (ее значение должно быть уникальным, а в рассматриваемом случае может оказаться не уникальным);
- некоторые профайлы (сохраненные в них значения могут теряться или периодически оказываться недоступными);
- индексы полнотекстового поиска окажутся задублированы и могут оказаться различными;
- если механизм регламентных заданий включен в нескольких кластерах, то одно регламентное задание сможет быть запущено в нескольких экземплярах;
- управляемые блокировки (в рассматриваемом случае не используются);
- блокировки объектов (используются в методе Заблокировать прикладных объектов 1С:Предприятия и при их редактировании в диалогах);
- каждый кластер имеет свой журнал регистрации.
Все автоматические блокировки реализуются средствами управления транзациями СУБД. Поэтому наличие нескольких кластеров не оказывает влияние на транзакционный механизм базы данных.

И это всё при том что 1С умеет работать со своей базой :-)

awk, про УИДы всё ясно, тут возражений нет. Генери, пиши и настанет счастье.

С номерами/кодами интереснее. Я провёл эксперимент и попробовал создать новые документы в одну базу из двух кластеров 1С. Номера задвоились. Предполагаю что причина задвоения в том что сервер 1С самостоятельно выдаёт новые номера и не проверяет уникальность нового номера в базе. В этом случае избежать задвоения номеров при записи со стороны не удастся никак.

Из разъяснений 1С я понял что управляемые блокировки накладываются средствами 1С, а не СУБД, поэтому могут быть конфликты при записи со стороны.
Maks_Alexey; +1 Ответить
2. Герман (German) 06.12.09 19:58
3. gilv (Gilev.Vyacheslav) 06.12.09 20:20
ну и нарушение ЛС тоже надо упомянуть
4. Вячеслав Кадацкий (marsohod) 06.12.09 22:19
+ за очень ценную мысль: "...скорость разработки с ее (1С) помощью ОЧЕНЬ высока. Поэтому прибегать к чему-то нестандартному надо только в КРАЙНИХ случаях."
а также за то, что Вас это волнует в 2 часа ночи в воскресенье... :D
5. Василий Казьмин (awk) 07.12.09 09:23
(3) Лицензионное соглашение 1С противоречит законодательству РФ (и здравому смыслу), поэтому может быть оспорено.
Трактор; German; +2 Ответить 1
6. gilv (Gilev.Vyacheslav) 07.12.09 17:09
(5) противоречит или нет - предлагаю не обсуждать, а просто информировать об этом
далеко не всем будет интересно продолжать наработки , если выясниться, что нужно идти доказывать свою правоту в суде

думаю, очень мало будет желающих судиться с 1С
рекомендую почитать партнерский форум, чтобы сформировать представление о настроениях в 1С
Maks_Alexey; awk; +2 Ответить
7. lucius (lucius) 09.12.09 12:41
Редкостная по плотности наполнения здравым смыслом и полезным содержанием статья. Жаль не могу поставить 8 плюсов.
(допускаю, что позднее время способствовало высокому качеству текста :о))
8. Василий Казьмин (awk) 09.12.09 13:19
(7) Спасибо за оценку, но статью я бы хотел переписать. Очень много новых данных которые я получил, много примеров кода по теме, которые не вставил. Например: о невозможности удалить не штатными средствами 1С элемент. В выходные может перепишу. Всё зависит не от меня, а от того дадут ли мне на это время жена и дети.
9. Serj (Serj1C) 07.06.10 13:39
(8) Эх, не дали времени... )
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа