Вход | Регистрация


1С:Предприятие ::

Метки:документы

cvvПроведение документов НЕ используя СТАНДАРТНЫЕ средства 1С

Я
   be-may
 
02.06.04 - 09:29
Здравствуйте. Первый раз на вашем форуме.
В настоящее время назрело решение уйти от стандартного проведения документов в 1С.
Имеется  сетевая 1С  SQL версии (7.7.). В базе работает около 100 пользователей (около 30 постоянно создают или модифицируют существующие документы). В связи с этим в базе периодически случаются практически мертвые транзакции.
Необходимо переписать проведение документов на чистый SQL.
Может кто ни будь сталкивался с подобной проблемой и может описать алгоритм такого проведения?
 
 
   SiMazx
 
2 - 02.06.04 - 09:38
Что значит перевести проведение в чистый SQL? Напрямую в SQL-таблицы планируешь писать?
   VladZagorsky
3 - 02.06.04 - 09:44
2be-may: А ты представляешь сколько в 1С связанных таблиц?????

P.S. А не подумать ли тебе о "восьмерке"?
   be-may
 
4 - 02.06.04 - 09:46
(1) - Не все так плохо. Половина отчетов уже переписаны на SQL.

(2) - Да. Напрямую. Хочу попробовать.По сути проведение, что это? Запись в журнал(ы), проведение по регистрам,  бух. итоги.. Что еще? Индексирование?
   be-may
 
5 - 02.06.04 - 09:48
(3) У нас 7.7. полностью переписана. От базовой остались "рожки да ножки".
   SnarkHunter
 
6 - 02.06.04 - 09:56
(5)Делали... Но только подготовку к проведению (формирование списка движений) на чистом SQL, само проведение - штатными методами 1С...
   sss
7 - 02.06.04 - 10:11
если делать запросы на изменение и получение данных напрямую к базе, зачем 1С вообще? - стандартные объекты не используются, а формы лучше в VB или Delphi рисовать
   BorisG
 
9 - 02.06.04 - 10:27
Не... вопрос не здравый ;-))
   SiMazx
 
10 - 02.06.04 - 10:31
(8) md он и в Африке md... Вместо dd в SQL - dds...
(7) ню-ню...
 
  Рекламное место пустует
   be-may
 
11 - 02.06.04 - 10:33
(7) - Зачем изобретать велосипед?
В 1С все уже есть (формы документов). Плюс не нужно обучать пользователей.
Т.е. по сути 1С использовать как внешний интерфейс доступа к SQL базе.
А по существу! Кто-нибудь действительно пробовал заниматься подобным?
Кто-нибудь разбирался с механизмами, запускающимися при проведении документов?
Затраты на разработку окупаются за счет увеличения производительности...
   SnarkHunter
 
12 - 02.06.04 - 10:35
Увеличение производительности будет заметно только на тысячах движений по документу...
   DimG
 
13 - 02.06.04 - 10:38
у меня есть мдшник конфы где сделано нечто подобное, писал не я. Просто стырил в одном месте в целях образования. Пишите на мыло. Пришлю. Только, возможно, не сегодня, и не завтра т.к. в коммандировку еду.
   sss
14 - 02.06.04 - 10:38
Основа конечного приложения - плоская таблица. Пусть независимая от СУБД,
пусть с метаданными и методами, но плоская и тупая.
Например, 1С-программист ничего не знает о реляционной модели. Он оперирует
действительно объектами, максимально приближенными к предметной области
(учет и анализ). Например - иерархический справочник (дерево). Да еще с
поддержкой истории изменения атрибутов. Или - многомерный накопительный
регистр. Накапливает ресурсы в разрезе аналитик. Или документ - допустимы
вложенные таблицы (документы). Понятно, почему создание простого склада на
1C - это день работы. Реляционная схема хранения создается автоматически,
пусть неоптимально, тормознуто (есть над чем работать), но суть в том, что
реляционная модель чрезвычайна бедна для отображения реальных понятий учета
и анализа.

переходя на прямой доступ к данным вы отказываетесь от стандартных механизмов системы(неважно какой: 1С, Аттейна Аксапты). Ссылочной целостности в этих системах не предусмотрено (точнее на уровне приложения). Следовательно ее надо реализовывать самому.
Вопрос чем это отличается от связки Oracle + Forms или Interbase + Delphi?
   SnarkHunter
 
15 - 02.06.04 - 10:45
(14)Извлечение данных ничем не нарушает ссылочную целостность, значительно повышая, тем не менее, производительность...
   sss
16 - 02.06.04 - 10:53
"Извлечение данных ничем не нарушает ссылочную целостность, значительно повышая, тем не менее, производительность... "
да, но большинство проблем то при проведении, т.е. при ЗАПИСИ
   be-may
 
17 - 02.06.04 - 10:57
(14) Не буду спорить.
Речь несколько не о том.
Задача не стоит 'с нуля'. Есть готовая работающая база. Существует проблема в транзакциях в этой базе. При обработке проведения выполняется куча проверок. Из некоторых документов при проведении формируются другие. Все это перенести из 1С куда-то еще ..?! (Why? I do not know.. )
На SQL необходимо перенести только модификацию таблиц, т.к. это действительно выполняется быстрее (Не голословно. Проверено. Например, для некоторых отчетов производительность в 100-150 раз выше)
   SnarkHunter
 
18 - 02.06.04 - 10:57
Связка "подготовка данных для проведения при помощи SQL" + "проведение штатными средствами 1С" прекрасно работает, существенно ослабляя остроту проблемы "ожидания транзакции"...
   SnarkHunter
 
19 - 02.06.04 - 10:58
(17)Как связаны "модификация таблиц" и уменьшение времени формирования отчетов?
   be-may
 
20 - 02.06.04 - 11:23
(18) - На практике?
(19) - Согласна. Ни как.
Подумалось, что по аналогии: "обращение к регистру через 'запрос' (стандартно)" - и - "обращение через SQL запрос"(через "1cpp.dll")
   Z1
21 - 02.06.04 - 12:06
(20) Отчеты и расчет данных для проведения через sql запросы делай.
Само проведение лучше оставь 1с.
Почитай у Муму и toypaul
Опиши свою конфигурацию : операц система, sql, сеть, сервер есть ли терминал и.т.д.( чем подробней тем лучше )
Сейчас достаточно много хорошего железа за счет которого очень быстро и достаточно эффективно можно решить твои проблемы
   SnarkHunter
 
22 - 02.06.04 - 12:11
(20)Естественно на практике...
   Z1
23 - 02.06.04 - 12:28
(17)
Цитата "При обработке проведения выполняется куча проверок." - (ИМХО)
проверки лучше поставить ПриЗаписи, режим документа ПриЗаписиПерепроводить(1).
Цитата "Из некоторых документов при проведении формируются другие." - (ИМХО)
лучше моделировать тем или иным способом документ с несколькими многостроч.
частями чем при проведении одного документа проводить другие.
   be-may
 
24 - 02.06.04 - 13:28
(23) - А при записи документа таблицы не блокируются?  Тем более с последующим перепроведением. Насчет многострочной части. Такой возможности нет, т. к. это повлечет за собой очень большие изменения в конфигурации и работе фирмы.
(21) - Все основные отчеты переписаны на SQL. До расчета данных для проведения дело пока не дошло, но это хорошая идея. За неё спасибо. (Интересно , а отмена проведения? Это размышления по ходу...). Вообще дело не в конфигурации железа. ОС- Advanced Server, SQL - 8.0, Citrix, 100 Mb-ая и гигабитная сеть, есть рабочая база в основном для \'активных\' пользователей, копия по вчерашний день.
P.S. Кто такие Муму и toypaul? toypaul - http://1csql.udmnet.ru/???
   SnarkHunter
 
25 - 02.06.04 - 15:58
(24)Да, toypaul - это http://1csql.udmnet.ru
   Z1
26 - 02.06.04 - 17:12
(24) Citrix и sql на разных серверах или на одном?
Что такое SQL - 8.0 я не знаю.
При записи документы также блокируются.В любой момент времени только один домумент может записываться (проводиться ) и в этот момент клиент 1с ( приложение 1с) ведет себя ну очень некоректно плохо. Особенно это проявляется
в Citrix или терминале при большом количестве пользователей.
Спасает от этого моя multex_1c лежит на hippo. Будут вопросы по ней пишите.
Отмена проведения много времени не занимает - бывает правда в "плохих"
конфигурациях такое наворотят приотменепроведения - но это очень редкий случай.
Поверь конфигурация железа сервера , настройка ОС, сеть очень много
значат особенно для работы  1c в cязки с  SQL.
   romix
 
27 - 02.06.04 - 20:43
(0) 1С, как вы понимаете, при проведении документа делает
ни что иное, как модифицирует SQL таблицы. Что изменится от того, что вы станете делать ТО ЖЕ САМОЕ напрямую? Ну может вдвое выростет производительность за счет отказа от ODBC - но вашу проблему надо решать более кардинально, а не пытаться "оптимизировать пузырьковую сортировку".

Zl абсолютно прав - нельзя из дока при проведении создавать другие доки и лучше не выполнять там никакие проверки. Все это тормозня, а другие юзера в это время ждут завершения транзакции. Все такие вещи надо делать в ПриЗаписи().
   Asmody
 
28 - 02.06.04 - 22:59
(0) а БР не пробовали? (http://www.vtools.ru/fastreg.htm)
   be-may
 
29 - 03.06.04 - 10:20
(26)Citrix и sql на одном сервере. Ms. SQL server 2000, версия SQL 8.00.
Цитата: \'Поверь конфигурация железа сервера , настройка ОС, сеть очень много
значат особенно для работы  1c в cязки с  SQL\'. -> Все это проверено и перепроверено. Этим занимались сис. админы. Поверьте, вопрос бы не стоял так остро, если бы не были использованы другие способы(в плоть до покупки нового сервера). Под Citrix-ом работает ограниченное число пользователей(только те, кому \'ну очень\' надо (4-5 человек))

(27) \'..но вашу проблему надо решать более кардинально..\' А как бы её решили Вы?
Можно пообщаться вне форума (e-mail).

(28) Спасибо за ссылку. Заинтересовало. Встречный вопрос. А вы пробовали?
   Asmody
 
30 - 03.06.04 - 13:10
(29) на работающих проектах - не приходилось. А так, поиграться... Интересные идеи там. На Т1С была как-то большая ветка по БР.
   romix
 
31 - 03.06.04 - 20:23
(29) Я бы исключил любые длительные обработки в модуле проведения.
Это требование есть в Желто-Красных Книгах.
Их надо вынести из модуля проведения куда-нибудь в ПриЗаписи() например.
Это резко уменьшит торможение и взаимоблокировки в SQL базе.

Насчет резкого (в 100 раз) ускорения отчетов - вы наверное их делаете простым перебором по документам или справочникам. А потом - бац - делаете на компилирующем языке. Естественно, это дает резкий рост производительности труда.

Почту отправить не удалось - попробую дома...
   SnarkHunter
 
32 - 03.06.04 - 20:41
Ну все по полочкам разложил... Выдержат ли...
   SnarkHunter
 
34 - 04.06.04 - 05:53
(33)Про какого суслика ты все время талдычишь?

А советы твои в (31) я бы поостерегся применять... Ибо вынесение кода в, к примеру, процедуру ПриЗаписи() ведет к одной весьма неприятной ситуации, когда у "тупых 1С-ников" широко открываются глаза, рот и прочие отверстия... При этом они начинают кричать: "Помогите!!!" и спрашивать: "Это глюк 1С???"...

По поводу запросов... Называть T-SQL компилирующим языком... Ну ладно, если нравится, то продолжай его так называть... А ускорение (в 100 раз) достигается совсем по другой причине - за счет более эффективного построения запросов к СКЛ-серверу, потому как трансляция "запрос 1С" -> "запрос СКЛ" может служить примером того, как не нужно писАть запросы... Почему это так реализовано - это другая тема...

Так что рекламируй книжки Болдырева - у тебя это лучше получается...
   romix
 
35 - 04.06.04 - 20:01
(34) См. поиск по слову "суслик" на этом форуме. :-) Если тема сусликов Вам уже не интересна (и снарк - это не суслик, а особое животное), то ну и ладно. Sorry, если мои слова читаются как наезд или некорректный прикол.

Это советы из ЖКК. Насчет того, что новички не смогут - ну не смогут, позовут кого-нибудь... Но по любому это действие должно быть выполнено, прежде чем обращаться к базе SQL напрямую (а также писать ассемблерные вставки).

Слово T-SQL в этой ветке я не нашел - запрос может быть выполнен и средствами стандартного ANSI SQL-92. Я имею в виду обработку полученного массива на клиентской стороне - торможение может быть еще и из-за этого (если, например, перебирают документы в цикле, чтобы получить отчет).

Насчет "1С не оптимизирован для запросов" - очень может быть. Правда, я не особо сталкивался с неисправимым торможением - в 1С почти всегда можно извернуться штатными средствами (например, регистрами без ресурсов - это почти полный аналог "плоских" SQL-таблиц), и сделать быстро за счет большего размера базы.

Ветку с книгами Болдырева OFF: Русское чудо - секреты экономической отсталости завел не я, а Волшебник. Человек даже нарушил Правила своего же Форума "Не публикуйте материалы, нарушающие авторские и имущественные права, а также ссылки на них". А вы говорите, книги плохие. :-)
   SnarkHunter
 
37 - 05.06.04 - 06:46
(35)Советы из ЖКК говоришь... Похоже разработчики типовой ТиС 9.хх обкурились этих советов, в результате чего программное и интерактивное проведение документов стало различаться словно небо и земля....

По поводу слова T-SQL... T-SQL = Transact-SQL, реализация фирмой MS стандарта ANSI SQL-92...

"Не сталкивался с неисправимым торможением"... Смотря какие объемы баз у тебя были до сих пор и сколько пользователей с ними работало... Когда-то и я не сталкивался...



Список тем форума
Рекламное место пустует  
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует