Здравствуйте. Первый раз на вашем форуме.
В настоящее время назрело решение уйти от стандартного проведения документов в 1С.
Имеется  сетевая 1С  SQL версии (7.7.). В базе работает около 100 пользователей (около 30 постоянно создают или модифицируют существующие документы). В связи с этим в базе периодически случаются практически мертвые транзакции.
Необходимо переписать проведение документов на чистый SQL.
Может кто ни будь сталкивался с подобной проблемой и может описать алгоритм такого проведения?

Разрешаю... Делай ...

Обязательно закупи ведер 10 вазелина ...

Что значит перевести проведение в чистый SQL? Напрямую в SQL-таблицы планируешь писать?

2be-may: А ты представляешь сколько в 1С связанных таблиц?????

P.S. А не подумать ли тебе о "восьмерке"?

(1) - Не все так плохо. Половина отчетов уже переписаны на SQL.

(2) - Да. Напрямую. Хочу попробовать.По сути проведение, что это? Запись в журнал(ы), проведение по регистрам,  бух. итоги.. Что еще? Индексирование?

(3) У нас 7.7. полностью переписана. От базовой остались "рожки да ножки".

(5)Делали... Но только подготовку к проведению (формирование списка движений) на чистом SQL, само проведение - штатными методами 1С...

если делать запросы на изменение и получение данных напрямую к базе, зачем 1С вообще? - стандартные объекты не используются, а формы лучше в VB или Delphi рисовать

2sss: А как быть со структурой (файл md, или как он там называется в SQL-версии 1С) ???  А вообще вопрос здравый...

Не... вопрос не здравый ;-))

(8) md он и в Африке md... Вместо dd в SQL - dds...
(7) ню-ню...

(7) - Зачем изобретать велосипед?
В 1С все уже есть (формы документов). Плюс не нужно обучать пользователей.
Т.е. по сути 1С использовать как внешний интерфейс доступа к SQL базе.
А по существу! Кто-нибудь действительно пробовал заниматься подобным?
Кто-нибудь разбирался с механизмами, запускающимися при проведении документов?
Затраты на разработку окупаются за счет увеличения производительности...

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

у меня есть мдшник конфы где сделано нечто подобное, писал не я. Просто стырил в одном месте в целях образования. Пишите на мыло. Пришлю. Только, возможно, не сегодня, и не завтра т.к. в коммандировку еду.

Основа конечного приложения - плоская таблица. Пусть независимая от СУБД,
пусть с метаданными и методами, но плоская и тупая.
Например, 1С-программист ничего не знает о реляционной модели. Он оперирует
действительно объектами, максимально приближенными к предметной области
(учет и анализ). Например - иерархический справочник (дерево). Да еще с
поддержкой истории изменения атрибутов. Или - многомерный накопительный
регистр. Накапливает ресурсы в разрезе аналитик. Или документ - допустимы
вложенные таблицы (документы). Понятно, почему создание простого склада на
1C - это день работы. Реляционная схема хранения создается автоматически,
пусть неоптимально, тормознуто (есть над чем работать), но суть в том, что
реляционная модель чрезвычайна бедна для отображения реальных понятий учета
и анализа.

переходя на прямой доступ к данным вы отказываетесь от стандартных механизмов системы(неважно какой: 1С, Аттейна Аксапты). Ссылочной целостности в этих системах не предусмотрено (точнее на уровне приложения). Следовательно ее надо реализовывать самому.
Вопрос чем это отличается от связки Oracle + Forms или Interbase + Delphi?

(14)Извлечение данных ничем не нарушает ссылочную целостность, значительно повышая, тем не менее, производительность...

"Извлечение данных ничем не нарушает ссылочную целостность, значительно повышая, тем не менее, производительность... "
да, но большинство проблем то при проведении, т.е. при ЗАПИСИ

(14) Не буду спорить.
Речь несколько не о том.
Задача не стоит 'с нуля'. Есть готовая работающая база. Существует проблема в транзакциях в этой базе. При обработке проведения выполняется куча проверок. Из некоторых документов при проведении формируются другие. Все это перенести из 1С куда-то еще ..?! (Why? I do not know.. )
На SQL необходимо перенести только модификацию таблиц, т.к. это действительно выполняется быстрее (Не голословно. Проверено. Например, для некоторых отчетов производительность в 100-150 раз выше)

Связка "подготовка данных для проведения при помощи SQL" + "проведение штатными средствами 1С" прекрасно работает, существенно ослабляя остроту проблемы "ожидания транзакции"...

(17)Как связаны "модификация таблиц" и уменьшение времени формирования отчетов?

(18) - На практике?
(19) - Согласна. Ни как.
Подумалось, что по аналогии: "обращение к регистру через 'запрос' (стандартно)" - и - "обращение через SQL запрос"(через "1cpp.dll")

(20) Отчеты и расчет данных для проведения через sql запросы делай.
Само проведение лучше оставь 1с.
Почитай у Муму и toypaul
Опиши свою конфигурацию : операц система, sql, сеть, сервер есть ли терминал и.т.д.( чем подробней тем лучше )
Сейчас достаточно много хорошего железа за счет которого очень быстро и достаточно эффективно можно решить твои проблемы

(20)Естественно на практике...

(17)
Цитата "При обработке проведения выполняется куча проверок." - (ИМХО)
проверки лучше поставить ПриЗаписи, режим документа ПриЗаписиПерепроводить(1).
Цитата "Из некоторых документов при проведении формируются другие." - (ИМХО)
лучше моделировать тем или иным способом документ с несколькими многостроч.
частями чем при проведении одного документа проводить другие.

(23) - А при записи документа таблицы не блокируются?  Тем более с последующим перепроведением. Насчет многострочной части. Такой возможности нет, т. к. это повлечет за собой очень большие изменения в конфигурации и работе фирмы.
(21) - Все основные отчеты переписаны на SQL. До расчета данных для проведения дело пока не дошло, но это хорошая идея. За неё спасибо. (Интересно , а отмена проведения? Это размышления по ходу...). Вообще дело не в конфигурации железа. ОС- Advanced Server, SQL - 8.0, Citrix, 100 Mb-ая и гигабитная сеть, есть рабочая база в основном для \'активных\' пользователей, копия по вчерашний день.
P.S. Кто такие Муму и toypaul? toypaul - http://1csql.udmnet.ru/???

(24)Да, toypaul - это http://1csql.udmnet.ru

(24) Citrix и sql на разных серверах или на одном?
Что такое SQL - 8.0 я не знаю.
При записи документы также блокируются.В любой момент времени только один домумент может записываться (проводиться ) и в этот момент клиент 1с ( приложение 1с) ведет себя ну очень некоректно плохо. Особенно это проявляется
в Citrix или терминале при большом количестве пользователей.
Спасает от этого моя multex_1c лежит на hippo. Будут вопросы по ней пишите.
Отмена проведения много времени не занимает - бывает правда в "плохих"
конфигурациях такое наворотят приотменепроведения - но это очень редкий случай.
Поверь конфигурация железа сервера , настройка ОС, сеть очень много
значат особенно для работы  1c в cязки с  SQL.

(0) 1С, как вы понимаете, при проведении документа делает
ни что иное, как модифицирует SQL таблицы. Что изменится от того, что вы станете делать ТО ЖЕ САМОЕ напрямую? Ну может вдвое выростет производительность за счет отказа от ODBC - но вашу проблему надо решать более кардинально, а не пытаться "оптимизировать пузырьковую сортировку".

Zl абсолютно прав - нельзя из дока при проведении создавать другие доки и лучше не выполнять там никакие проверки. Все это тормозня, а другие юзера в это время ждут завершения транзакции. Все такие вещи надо делать в ПриЗаписи().

(0) а БР не пробовали? (http://www.vtools.ru/fastreg.htm)

(26)Citrix и sql на одном сервере. Ms. SQL server 2000, версия SQL 8.00.
Цитата: \'Поверь конфигурация железа сервера , настройка ОС, сеть очень много
значат особенно для работы  1c в cязки с  SQL\'. -> Все это проверено и перепроверено. Этим занимались сис. админы. Поверьте, вопрос бы не стоял так остро, если бы не были использованы другие способы(в плоть до покупки нового сервера). Под Citrix-ом работает ограниченное число пользователей(только те, кому \'ну очень\' надо (4-5 человек))

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

(28) Спасибо за ссылку. Заинтересовало. Встречный вопрос. А вы пробовали?

(29) на работающих проектах - не приходилось. А так, поиграться... Интересные идеи там. На Т1С была как-то большая ветка по БР.

(29) Я бы исключил любые длительные обработки в модуле проведения.
Это требование есть в Желто-Красных Книгах.
Их надо вынести из модуля проведения куда-нибудь в ПриЗаписи() например.
Это резко уменьшит торможение и взаимоблокировки в SQL базе.

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

Почту отправить не удалось - попробую дома...

Ну все по полочкам разложил... Выдержат ли...

(32) Ну если комбайн суслика выдержал, то полочки уж точно выдержат. :-)

(33)Про какого суслика ты все время талдычишь?

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

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

Так что рекламируй книжки Болдырева - у тебя это лучше получается...

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

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

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

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

Ветку с книгами Болдырева OFF: Русское чудо - секреты экономической отсталости завел не я, а Волшебник. Человек даже нарушил Правила своего же Форума "Не публикуйте материалы, нарушающие авторские и имущественные права, а также ссылки на них". А вы говорите, книги плохие. :-)

Попытки пристроить двигатель от танка с вертикальным взлетом на старый ЖопоРожец окончились неудачей....

(35)Советы из ЖКК говоришь... Похоже разработчики типовой ТиС 9.хх обкурились этих советов, в результате чего программное и интерактивное проведение документов стало различаться словно небо и земля....

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

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

(37) В ТиС при проведении задним числом вроде бы обязательно надо смотреть итоги по регистру не на ТА. Отсюда тормозня при проведении не через Операции-Провести. Но она не так важна, т.к. правка задним числом вообще по хорошему не самая приятная вещь в учете. Я бы юзерам эту операцию еще больше затруднил: пусть сначала создаст документ отмены (отката ТА), а потом уже правит. Что-то типа того. Тогда бы, кстати, и такого вопроса не возникло.
...
Точнее я сталкивался (сильно тормозил запрос), тоже думал, а не поюзать ли SQL, но остановился на регистре без ресурсов. По быстродействию выборка летает (по сравнению с тем запросом, который был у меня до этого). Если посмотреть внутреннюю структуру таблиц, то это как бы одно и то же с тем, что я хотел сделать в SQL.

(all) Да, почитал я ваши разговоры и понял, что дельного совета можно не дождаться. Хочу высказать свое мнение.
  Во первых, 1С создана, чтобы на ней конфы создавать, а не впихивать заплатки на Delphi, SQL или ещё каком нибудь языке.
  Во вторых, в 1С есть механизм замера времени выполнения. С помощью этого механизма можно выявлять места тормоза в процедуре проведения(распроведения) и их менять на оптимизированный код.
  В третих, недавно меня попросили ускорить проведение. С помощью п.2 удалось выяснить, что дело во временном расчете регистра (1 оператор). Оказывается его тоже можно оптимизировать с помощью \\\\\\\"УстановитьЗначениеФильтра\\\\\\\". Эффект времявыполнения этого операнда (РасчитатьПо) снизился с 98% до 43-45% времени (на моей машине с 73-80 сек до 1.6 сек)

(39)Ну все... Умыл всех...
Теперь вся утка наша...(с)

(39)Мдя... Типа разъяснил лохам, чо да как... Спасиб, век не забуду...

(39) Угу, дельный совет. Но только тормоза при временном расчете регистров ни для кого не секрет. Втыкаешь несколько "сообщить()" и понимаешь, какой участок кода больше всего тормозит (шутка ли - 80 секунд).

Насчет трюка с установкой фильтра - да, хороший трюк, но тут по-моему все, начиная с (0), назвали свои хорошие трюки (которые многократно ускоряют проведение или запрос в той или иной ситуации). Ситуация в (39) - не единственная, и наверняка в (0) она не подойдет... Так что фраза "я тут единственный, кто способен предложить верное решение" вряд ли делает человека гусаром...

(+42) или хотя бы не п...м :-)