1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

В понедельник вообще с утра работать не могли. И так почти полтора часа.
Только когда я стал по очередности выгонять всех ввидимо отцепилась блокировка и
и все наконец заработали.

Заметил что 3 варианта блокировок:
1. при обмене урбд, попытка захвата доступа к 1SUPDTS
2. При попытке создать новый документ - попытка захвата 1SJOURN
3. При поытке создать элемент справочника - попытка заквата SC214 или 1SDNLOCK
3.1 Блокировка 1SDNLOCK возникает и при создании нового документа (видимо из-за нумерации что ли)

Ну с обменами не так часто и понятно потому что обмен я вижу.
С остальным все на так ясно.

Базы не малые, регистр RA328 подходит к 1.7 ГБ
Я так понимаю что многие проблемы из-за проведения документов задним числом ну и перепроведения если надо
Время ожидания захвата БД сброшено в ноль у всех вроде бы, но уточню. Может кого прозевал.
Заметил что в понедельник много потому что делают много приходов и в пятницу тоже.
Причем всем надо с утра.

На ПБ как-то особенно с этим всем проблем и нет а вот на ЦБ бывают, и неприятные
Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше.
В ЦБ банк касса розница енвд перемещения поступления оптовые реализации комплектации и т.д.
Магазины для себя в ЦБ делают большие перемещения с Центрального склада.

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!

SQL

(0) Как увидеть кто начал цепочку блокировок и его притормозить?

(1) А что в SQL таких проблем разве нет?
SQL хорошо но слишком много разом переписывать на прямые.
Да еще и на всех ПБ надо тогда SQL а там по 3-4 компа

(3) Зачем?

(4) А что - на них свертку делать?
Ведь если SQL то ЦБ может быть быть уже любого размера
а на ПБ как тогда быть?

Мне бы сейчас срочно увидеть кто начал цепочку блокировок и его притормозить?
Может с помощью 1С++ как-то это можно отловить?

(3) прекрасно работала центральная сиквельная (она тогда еще не очень большая была, гигов под 50) с четырьмя файловыми периферийками.

(5) в файловых - имхо, никак

(6) Практически вся инфа одинакова что в ЦБ что в ПБ
и регистра движения партий тот же вылезет за 2 ГБ и что тогда делать?

Если через журнал регистрации - писать туда инфу о действиях с БД?
Хотя итак вроде пишу.

Ну что кроме реально обмена (не очень уж он частый) может блокировать надолго доступ к базе данных?
Если время ожидания в ноль - значит сразу же должен отлетать. а другие как раз могут работать

(7) вроде как кернел33 я пользуюсь или 37 (ззабыл уже) чтобы проц в 100% не уходил, но как раз он и не уходит

(6) (7) и я про тоже, да в SQL  такой проблемы не будет ИМХО, по крайней мере у меня не стало после перехода скуль, до скуля было, но еще было -  переписать обработку проведения расходной накладной, их выписывают много и много народа, а расчет регитров в проведении стал тормозить, вот и была такая бяка, это помогло но не надолго, перевел на скуль и забыл

(8)
1. а зачем одинаковая инфа в ЦБ и ПБ? может, пересмотреть архитектуру системы, если не хочешь менять систему хранения?
2. в периферии все движения по партиям могут быть не нужны. в любом случае - надо смотреть архитектуру. ну, или переводить то, где большие объемы - на серверное хранилище.
3. запись в БД - не поможет.
4. время ожидания в ноль - он вроде как раз долбится  без ограничения по времени?
(9) как вариант, смотри чей сеанс в 99% (у тебя же терминал, насколько помню?), пытай пользователя

И да ПБ и ЦБ вообще фиолетово какие базы скуль или ббф

*дбф

(12) Не понял.
Насчет 99% процессора - надо поглядеть.
(11) Ну если приход весь на ЦБ то значит дальше все перемещениями на ПБ. Но ведь и приход тоже на ПБ уйдет иначе его уже не перепроведешь елси что. Все кроме РКО и строк выписки банка (расход) мигрирует во всех базах, ну еще Чек ККМ (место создания и центр)

(14)+ Читаю - все ж это было и раньше.
И советуют время ожидания захвата таблицы БД в ноль установить.
То есть по идее сразу идет сообщение о блокировке и никто не ждет

Там еще было такое
лучше даже так:

1. 0
2. либо править всем cfg, либо вк, хоть от trad для управления настройками, хоть вк приоритет
Это ЕПРСТ писал еще в 2013

А что править в CFG файле?

(14) ну и сделай, чтоб на периферию уходили только нужные документы. Рецептов минимум два.

?(16) А тогда надо модули проведения переделывать. Если периферийка чтоб на смотрела остатки по ЦБ при проведении перемещения.
Но тогда контроль остатков вообще улетит или нет?

(16) 2 рецепта - это какие?

(17) периферийка смотрит только на свои остатки. контроль остатков происходит в своей зоне ответственности (склады, кассы)
2 рецепта - это "пустышки с периферийки" и "чистка апдейтса".

(19) Пустышки - да, давно была идея ,с апдейтс сложнее - надо прямой запрос рисовать
Как-то стремно было - вроде ж работает в-осовном нормадьно и ладно. Даже писал программы
Ну и потом партии - фифо у нас. Магазины есть с оптовыми реализациями - значит надо партии чтоб они видели
Точнее свою маржу.

(20) на прямой запрос на чистку апдейтса в далеком 2008 я потратил с неделю - при этом в общем и подсказать было некому особо. Но при этом там была еще и настройка "какие объекты в какую базу" (была ИБ, в которой торговля была не только за нал с расчетом на месте, но и за безнал, который приходил в офис. поэтому уходили в эту базу расчеты только некоторых контрагентов. Ну и еще какие-то аналогичные правила. Плюс база была - "снежинка". точнее - "куст".)

ну свои партии магазины и увидят.

Функция УстановитьВ0ВемяОжидания()
    ВремяОжиданияЗахватаБазы =Константа.ВремяОжиданияЗахватаБазы;
    Если ВремяОжиданияЗахватаБазы < 0 тогда
        Возврат 1;
    КонецЕсли;
    
    ЛокВэйт=0;
    Попытка
        МойТекст1С=СоздатьОбъект("Текст");
        МойТекст1С.Открыть(КаталогПользователя()+"1Cv7.CFG");
        НомерСтрокиТекста = 1;
        Пока НомерСтрокиТекста <= МойТекст1С.КоличествоСтрок() Цикл
            СтрокаТекста = МойТекст1С.ПолучитьСтроку(НомерСтрокиТекста);
            Если Найти(СтрокаТекста, "LockWaitTime")>0 Тогда
                Если Найти(СтрокаТекста,Симв(34)+"LockWaitTime"+Симв(34)+","+Симв(34)+""+Константа.ВремяОжиданияЗахватаБазы+""+Симв(34))=0 Тогда
                    МойТекст1С.ЗаменитьСтроку(НомерСтрокиТекста,
                    "{"+Симв(34)+"LockWaitTime"+Симв(34)+","+Симв(34)+""+Константа.ВремяОжиданияЗахватаБазы+""+Симв(34)+"}}");
                    ЛокВэйт=-1;
                    Прервать;
                Иначе
                    ЛокВэйт=1;
                КонецЕсли;                                                
            КонецЕсли;                                                
            НомерСтрокиТекста=НомерСтрокиТекста+1;
        КонецЦикла;
        Если ЛокВэйт=-1 Тогда
            МойТекст1С.Записать(КаталогПользователя()+"1Cv7.CFG");
            Предупреждение("Пожалуйста, войдите в базу повторно",5);
            Возврат 0;
       КонецЕсли;
    Исключение        
    КонецПопытки;
    Если ЛокВэйт=0 Тогда
        Предупреждение("Пожалуйста, войдите в базу повторно",1);
        Возврат 0;
    КонецЕсли;
    Возврат 1;
КонецФункции


Процедура ПриНачалеРаботыСистемы()
    Если УстановитьВ0ВемяОжидания() = 0 Тогда
        СтатусВозврата(0);
        ЗавершитьРаботуСистемы();
    КонецЕсли;    
...

(22) к (15)

(23) Спасибо! Да пользовался я этим скриптом

(24) Кэширование констант из прошлой ветки тоже сделал? (1С 7.7 ТИС на SQL - взлетит? База большая, еще 6 перифериек,юзеров>40 терм режим)

(25) Нет. Работает же все )
По-сути это в начале все константы в список значений кроме периодических. (при начале работы системы)
Ну и

(25) Или периодические тоже?

(25) Поднимаю ветку  и буду глядеть. Тогд много ценного было. И время в ноль я устанавливал

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

(29) Посмотрю но что-то яне помню чтоб в модуле проведения настолько актиывно в цикле константу проверял
тем не менее гляну. Единственное - вопрос периодических констант. Но кстати цены-то тоже периодические - а к ним же все время идет обращение

Если не все мигрирует что касается партий и остатков - получаем незакрытые регистры. Кстати у меян книга продаж и книга покупок не закрывались. Я так-то вообще ими и не пользуюсь

(30) именно поэтому чуть не первый вопрос был - как оптимизировать работу с ценами. Там и варианты с регистром были, и еще какие-то, и кэширование одноуровневое и двухуровневое, кэширование с освежением кэша, еще какие-то интересные способы. и, конечно, чтение цен прямым запросом.

(31) ну и делаешь регламентное задание, которое раз в месяц тупо чистит эти регистры.
оно вообще секунды работает.

(33) чистит и движения и итоги?

(32) Заинтересовало. А что значит одноуровневое и двухуровневое?
Я делал в другой конторе давно типа такого универсального справочника и все вот эти данные заливал в него,
при начале работы считывал его в список значений, но опять же там не было необходимости в периодике

(29) Косвенно. При записи и при модули проведения очень часто идет обращение к константам. И чем быстрее будет получен результат тем меньше времени занимает транзакция.

(0)  1С 77 + SQL +TOYSQL  лечит вопрос, отключая часть блокировок.... Сам делаал лет 10 назад...

Много чего видно дописывал с неоптимальным кодом влезая куда не надо и не влезая куда надо. Особенно это проведение других документов в процедуре ПриЗаписи текущего документа. А у меня по кабельному учету и автоперемещениям с витрины много такого наворочено

(0)
>>>Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
>>>Тогда бы можно было его притормозить а другие бы работали дальше !!!

ну дык пиши в стороннюю базу блокировки, делов то, тип того:

http://catalog.mista.ru/1c/articles/74138/

Да и в жр, если он не отключен, за ненадобностю видно, у кого транзакция открыта

Ну тис то соптимизировать для полёта..недолго, всего то выкинуть лишнюю неиспользуемую аналитику, период выставить в 5 дней и ожидание блокировки захвата таблиц в 0.
В групповых обработках проведения втыкать счетчик на запись, допустим 20 попыток, в обработка исключения ловить, что если это ошибка блокировки журнала, например при транзакции, то долбить дальше.
Таким образом, если можно хоть всю базу ставить на перепровод, не мешая остальным человекам работать. Рано или поздно, в цикле влетит в перепровод, даже за меньше чем 10 попыток

да..много чего можно сделать

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

(42) Период итогов в 5 дней - это регистры остатков сильно вырастут ?

В ЖР у меня только "изменения и ошибки".
Видимо надо все флажки взводить!

Я вижу что бьются пользоватли за захват таблиц БД аж шум стоит, но с кого началось не видно же
Ну кто-то задним числом проводит здоровенное перемещение да еще через глобальную сеть - пока он это делает,
ничего не видно, у него блокировки же нет.

Или кто-то долбит документы а все стоят, а долбит впустую ибо один вид дока наезжает на другой.
Увидел это - тут же его отключил и все заработали.
Но как сделать чтобы аж визжал комп и ругался что Сидоров лупит черт что в одиночку

(42) Итоги по всем регистрам остатков 5 дней? Забыл уже, надо глянуть где устанавливается

(44) операции - управление итогами.
Тока, регистры должны быть закрытыми, иначе, можешь и не дождаться пересчета или открытия след периода

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

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

(47) Запросто из этих юзеров половина регулярно гоняет тяжелые отчеты
(0) Я же тебе в начале июня переписал списание партий и остатков на прямые запросы. Там оставалось на полдня шкуркой зачистить. Чего дожидаешься?

(48) Отчеты не блокируют, они - насколько помню - ждут окончания блокировки.
"списания на прямые" - ему не рановато? вдруг возникнут проблемы, а он не найдет по недопониманию... Начинать надо хотя бы с расчетов прямыми...
(47) была бы дикая скорость - база была бы побольше. у меня когда 8 тыщ доков в день хренячили - база чуть не на гиг в месяц приростала, если не больше.
единственное, что могут одновременно хренячить - "перед обедом" или "перед концом рабочего дня"
(43) что значит "один вид дока наезжает на другой"? Он хотя бы по понятиям наезжает, или по беспределу?

(49) Они не блокируют, но все равно нервный фон серваку создают. А списание партий и остатков - это две процедуры в ГМ. Ну и помощь зала никто не отменял - вроде здесь помогают оперативно

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

(50)
- Доктор, меня все игнорируют!
-- Следующий!!!
©

(50) вот что бы я переделал - это отчеты. особенно типа ведомости по контрагентам, или "продажи" в 100500 разрезах (ну, тот вообще на олап хорошо ложится)

(53) Отчетов много, а тут 2 процедуры и все. Много лет назад перед переходом на СКЛ собрал статистику за 3 месяца по отчетам/юзерам/времени выполнения. Удивились как народ любит "аналитические" отчеты за год запустить и идти курить.

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

(55) Все гениальное просто :)

(56) ну это то что проверено и работает. и сделать несложно, не переписывая конфигурацию.
дальше меры понятно по нарастающей надо применять если недостаточно будет.

(54) Особого смысла в этом не много. Все равно это не решает проблему блокировок вообще никак.
Простой пример в SQL делаем элементарный запрос:
запрос = СоздатьОбъект("Запрос");
запрос.Выполнить("
|Товар = Справочник.Номенклатура.ТекущийЭлемент;
|РодительТовара = Справочник.Номенклатура.Родитель;
|УСЛОВИЕ (РодительТовара = выбРодитель);
|Группировка Товар;
|");

Ловим в профилеровщике:
declare @p1 int
set @p1=180150025
declare @p3 int
set @p3=2
declare @p4 int
set @p4=1
declare @p5 int
set @p5=-1
exec sp_cursoropen @p1 output,N'select SC84.DESCR, SC84.PARENTID,SC84.ID,SC84.PARENTID
from  SC84 WITH (NOLOCK)
where SC84.ISFOLDER = 2 and (((SC84.PARENTID =''   RUJ001'')))',@p3 output,@p4 output,@p5 output
select @p1, @p3, @p4, @p5

Особое внимание: WITH (NOLOCK).
Т.е. отчеты вообще ничего никогда не блокируют и даже не смотрят на блокировки.

Решение проблемы блокировок решается исключительно переделкой на управляемые блокировки SQL. Все остальное полумеры.

(53) да отчеты переписать, это фигня, сперва надо заставить базу работать как надо, чтобы за ночь, она вся перепроводилаь, например. У нас была комплексная, двойной учет. Были задвоенны или записи в регистре или сами регистры, если в размер не влазили. 2 плана счетов. И ничего, перепроводилась вся за ночь. Правда, за место уриба был мод.

(58) с его объемами, это лишнее

(58) "отчеты вообще ничего никогда не блокируют
Shared-то по-любому будут ))

(54) ну и формировать аналитические кубики ночью, а днем давать доступ только к кубику типа https://radikal.ru/lfp/s010.radikal.ru/i311/1510/4d/8e08b02e4265.jpg/htm
(59) у меня только себестоимость пересчитывалась. но в часы наименьших нагрузок, когда всего десяток юзверей в базе, ну и немонопольно, конечно. вся, конечно, не перепроводилась за отведенное время, но несколько месяцев успевала. год, емнип, трое суток догонялся.

(55) ДА, планирование закупок и закзаы поставщикам давно уже вынес в отдельную периферийку. Еще переводим всех менеджеров на проводную сеть а то раньше была радиосеть - видимо растет документоооборот в базе и уже вай-фай не выдерживает таких нагрузок.

(63) так у вас это через вафлю? ну-ну...

(63) Напомни - терминал-сервер или по сети работают?

(65) Конечно терминальный сервер и довольно мощный.
(64) Ну да, хотели когда-то чтоб было красивво и мобильно, без проводов, ну а теперь переделываем на провод

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

Если все в терминалке - то способ подключения не важен. Не гоняете же вы базу по сети...

(46) Я попробовал убрать одно измерение с регистра, очень долго убирал. Ну на копии.

(68) Не гоняем, но тем не менее после того как часть вернули на провод - шума по поводу зависаний и прочего стало меньше

(69) убрать измерение с регистра..минут 10 на все, вместе с переписыванием кода.

Руками, разумеется, а не штатной реструктуризацией

Загрузка выписки из клиент-банка - вот еще источник транзакций ибо много чего создается один чохом и другие затыкаются

(66) если терминал, то способ подключения пофиг. хоть LTE
(67) почему ж "юмор"? пиши даты перепроводимых документов, и анализируй. вангую, что в пятницу они "хренячат план", а в понедельник они "подчищают хвосты за пятницу"

(74) В понедельник приход больщой вводится и большие перемещения с центрального склада на магазины. В пятницу пока не смотрел что.

(75) Им бы понедельники взять и отменить (с)

(76) Клиент банк один хрен каждый день загружается массово

(71)(72) дык! Но этот способ не освящен БоГ'ом (БОрисом Георгиевичем)...
(73) ну так давай паузу в клиент-банке. пусть остальные просрутся в этот момент
(74) ну и готовь доки заранее. У тебя будут хотя бы уже сформированы доки, записи партий...
(75) они и фторнег загадят

(78) Две минуты транзировалось сегодня из-за нескольких десятков строк выписки банка и дальше все тип-топ

(78) С доками проблем нет все большие поступления делаются через загрузку тч из файлов всяких (csv txt xml dbf xls)
Правда после загрузки при записи их разбухтовывают

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

(80)+ Большие перемещения - тч тоже заполняется одной кнопкой а все предварительная подготовка через обработку, то есть тч перемещений многосотенно строчных формируется заранее и руками не вбивается

(81) После ряда загруженных выписок - паузу? и потом дальше или как-то хитрее?

окБухт.Новый();    : {Глобальный модуль(16228)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем

Это чаще всего пожалуй. Дохбухт создается в процедуре ПриЗаписи документов реализация, поступление и т.д. и проводится в ней же, то есть своего рода резервирование отрезанных кусков происходит. Вот здесь собака выдимо зарылась еще

(84)+ И что важно - для чеков ККМ а их немало за день тоже создается разбухтовка

Записать(); : {Документ.ЧекККМ.Форма.Модуль(1482)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем

            Если Итог("Сумма")>Получено Тогда
                Картой = Итог("Сумма")-Получено;
                ОплатаКартой = 1;
            Иначе
                Картой = 0;
                ОплатаКартой = 0;
            КонецЕсли
        Исключение КонецПопытки;    //[-] тщи 54ФЗ
        ПриЗаписиПерепроводить(0);
        Записать();
        ПриЗаписиПерепроводить(1);
Вот здесь Записать()

Кстати никогда нет ошибок транзакций при проведении (не вид), есть именно при создании записи и т.д.

(84) значит, создавай доки заранее, пустыми. по крайней мере, не будет транзакций на создании, получении ида и номера

(84) не знаю что за разбухтовка
но если подобные вещи
то быстрый и очевидный костыль - обернуть в попытку исключение и в цикл.

ну и в целом программное создание документов при интерактивной записи/проведении другого документа - это не очень.

(88) Да вроде в-основном срабатывает а главное что если транзакция то она просто в исходное состояние отбрасывает и не надо потом что-то выискивать (хвосты).

(88) попытка-исключение в цикле, и пауза!!! Причем лучше случайная. И все это в цикле.
Но лучше при этом еще и документы брать созданные заранее, а не создавать - это на одну транзакцию меньше

(87) Какие создавать  доки пустые? Ведь и банк и касса и реализация и чеки и перемещения и т.д.
бухи с тура еще автоматом массово расходники создают по эквайрингу в цб со всех магазинов (через обработку конечно)

(91) и вот эти обработки с массовым созданием тоже смотреть - тоже делать в них окна для работы.

(92) Да их вообще можно роботом рано утром делать. Просто не заморачивался этим

(91) разбухтовки твои создать пустые в часы без нагрузки - у тебя-то точно не 24*7, халява же.
можно и банк, конечно, но банк это мелочь. ну там склько, сотни три-четыре доков?

(93) ну так, млять, заморочься! :-))

У меня 11*7. Не совсем халява

(95) Считай что заморочился. И делать их надо в 6 утра и кстати загрузку клиент-банка туда же в робота надо.

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

(98) Насчет торговли - 4-5 лет надо. Ибо возвраты через отчет ккм тот же.
Насчет перехода на скуль или 8-ку. ДА все думаю - не взлетело пока. Наверное стремно что-то резко менять. Одно дело безнал и другое дело массовые продажи в 6 магазинах. Вдруг заткнется где-нибудь сильно. А тут вроде все проверено уже годами

(0) /регистр RA328 подходит к 1.7 ГБ/ как будет 2Гб у тебя база совсем встанет, так что срочно переводи на СКЛ или увольняйся

(96) 11*7 - это фигня. вот когда час в месяц допустимый простой...
(98) торговля торговле рознь. мы держали 3 года, и автообрезка ежемесячная.

(99) Понавтыкай во все свои отчеты/обработки замеры времени выполнения и закинь в журнал регистрации. Через месяц-другой лучше будешь знать узкие места

Насчет тех же документов бухт - да, это выход. Хотя переделывать немало придется. Там обработка разбухтовки порядки 3000 строк кажись (давно писал - пашет)

(100) Ну пока что я свертку сделаю ЦБ и ПБ пересоздам. За ночь и день успею и останется в базе тогда 17,18,19,20 годы, 16 уйдет.
Я каждый год эту свертку делаю. Мне много работы плучаеется а базе хоть бы хны

(102) Да я их в-принципе конечно знаю. Правда это не касается отчетов и обработок а касается именно транзакций. Отчеты и обработки работают себе тихо-мирно и не так уж часто.

жр(102) И время работы отчетов да, вывожу. Ну теперь выведу в ЖР

Начну с того что по максимум всякие массовые обработки выведу в робота. Пусть работает железная пила )

(100) Переход на скуль связан с приобретением скуль-сервера. Вроде сначала загорелись а потмо все в рамках слабенького тестового. Но тоже копаюсь потихоньку. Ну блин заново мозги настраивать приходится. А они заскорузли малость.

(75) вот они и херачат эти перемещения перепроводя их по 20 раз задним числом. Приходы вообще нагрузки не создают.

(100) только пусть 3 конверта оставит

бухгалтер начала загружать клиент-банк массово в 7.45. Загрузилось без проблем и шустро. А вот потом в каждую заходит и меняет там движения денежных средств и проводит и вот тут засады с 1SJORN

(111) А сразу статьи поставить? Аллах не велит?

(111)+ Чтобы загружать клиент-банк скажеи рано утром нужен же сам файл kl_to_1c.txt. Поэтому ту автомат не прокатывает

(111) "В каждую" - это каждая строчка выписки отдельный документ?

(114) Нет, она в обработку выписки их вводит.
(112) ну кроме налогов - остальное можно и сразу делать. Брать из платежек. Согласен. Сам на эту тему думал недавно. Не так уж сложно реализовать.

(115)+ Это ускорит процесс наверняка. Записывать не придется только проводить. Там же еще чтоб выписки прихода были раньше, чтобы выписки расход потом провелись

с 8.48 ни одной ошибки транзакций не было. И уже сегодня вряд ли будут

В строках ввыписки приход движения дс сразу ставятся автоматом в расход нет, но на расход бухгалтер трати 5-7 минут, просто если она это делает до 9, то попадет на массовый ввод документов за вчерашний день еще. Ну установлю ей дс (кроме налогов) в выписках расход. Это мелочи

(115) Бухгалтер после изменения каждой строчки документ записывает/проводит что ли? Плохо понимаю, как проведение одного документа может колом все встать.

(119) Да нет же
ОткрытьФорму("Документ.СтрокаВыписки" + ВидДвижения, Парам); : {Обработка.ВыпискаБанка.Форма.Модуль(253)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем.

Вот странная проблема.
Ну открыл из обработки выписка строку выписки приход или расход.
При чем тут 1SJOURN ???

(119) Да там походу обработка это ТЗ на форме которая при каждом чихе все документы что в ТЗ попали перепроводит :)

(120) Так покажи что там в этой строке 253.

(121) Вообще-то она стандартная. И ничего плохого не делает окромя хорошего )

ткрытьФорму("Документ.СтрокаВыписки" + ВидДвижения, Парам). Так вот же она 253

(123) стандартные - они такие стандартные...

(125) Это да, ну ладно для строк расхода подсуну я ДС, в строках приход сразу стоит поступления от покупателей

(120) Ну дэк в 1SJOURN хранятся как минимум дата,время и номер документа. Больше их по сути взять неоткуда, поэтому при открытии и пытается читать. Но раз прочитать не может то значит в этот момент уже кто-то залочил 1SJOURN проведением.

(127) Ну да, отсюда и ошибки

(126) Надо не подсовывать а перенести то что там делается в обработку, чтобы не было открытия формы.

(129) Ага

(126) Подожди :)
Я тут протормозил: ОткрытьФорму("Документ.СтрокаВыписки" + ВидДвижения, Парам)
Это же не открытие существующего, это создание нового документа. Так обработка у тебя не создает документы получается а только загружает данные в ТЗ и потом из него они уже создаются в ручную?

(131) она пихает данные в ТЗ. а потом бежит по строкам ТЗ, отмеченых флажком, и для каждого отмеченного создает док открытием формы

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

(133) Это первое чем озаботился на данный момент. Надо же хотя бы исключить то что можно исключить

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

(135) было бы желание...
вообще там не только журнал - там три узких места.
но вообще, клюшки пыхтели на 8000 документов (предновогодний декабрь)- упупырище легло и не встало на 2000 (самое начало января, новогодние каникулы)

(136)  А еще какие? Я ж вроде перечислял на каких таблицах блокировки возникают

(136) 8000 в день?

(138) ну да. ну, чуть больше.

(139) Вот эти попытка исключение тоже не всегда понятно как их использовать особенно вместе с НачатьТранзакцию. Мне кажется я вот особенно при автосоздании и автопроведении доков при записи других доков - что-то вымудриваю с этим делом.
                            НачатьТранзакцию();    
                            ТЗПер.Выгрузить(ТЗПерФирм);
                            ТЗКол=СоздатьОбъект("ТаблицаЗначений");
                            ТЗПер.Выгрузить(ТЗКол);
                            ТЗКол.Свернуть("Номенклатура","Количество");  
                            ВыбратьСтроки();
                            Пока ПолучитьСтроку()=1 Цикл
                                Если СпВитр.Принадлежит(Номенклатура)=1 Тогда
                                    НомКол=0;                                       
                                    Если ТЗКол.НайтиЗначение(Номенклатура,НомКол,"Номенклатура")=1 Тогда
                                        Прим=""+"Витрина("+СокрЛП(Строка(ТЗКол.ПолучитьЗначение(НомКол,"Количество")))+")";    
                                    КонецЕсли;    
                                КонецЕсли;    
                            КонецЦикла;    
                            ТЗПерФирм.Свернуть("Фирма","");    
                            ТЗПер.Сортировать("Фирма");
                            ТЗПерФирм.ВыбратьСтроки();  
                            //СпВитр.ВыбратьЗначение(,"");
                            Пока ТЗПерФирм.ПолучитьСтроку()=1 Цикл                                                               
                                НомСтр=0;                                      
                                ТЗДок.УдалитьСтроки();
                                Если ТЗПер.НайтиЗначение(ТЗПерФирм.Фирма,НомСтр,"Фирма")=0 Тогда Продолжить;КонецЕсли;      
                                Пока 1=1 Цикл
                                    ТЗПер.ПолучитьСтрокуПоНомеру(НомСтр);    
                                    Если ТЗПер.Фирма<>ТЗПерФирм.Фирма Тогда Прервать;КонецЕсли;
                                    Если СпВитр.Принадлежит(ТЗПер.Номенклатура)=1 Тогда       
                                        ТЗДок.НоваяСтрока();
                                        ТЗДок.Номенклатура=ТЗПер.Номенклатура;
                                        ТЗДок.Количество=ТЗПер.Количество;
                                        ТЗДок.Единица=ТЗПер.Единица;
                                        ТЗДок.Коэффициент=ТЗПер.Коэффициент;              
                                    КонецЕсли;    
                                    Если НомСтр+1<=ТЗПер.КоличествоСтрок() Тогда
                                        НомСтр=НомСтр+1;
                                    Иначе
                                        Прервать;
                                    КонецЕсли;    
                                КонецЦикла;                  
                                Если ТЗДок.КоличествоСтрок()>0 Тогда
                                    ДокПерем.Новый();                      
                                    ДокПерем.Фирма=ТЗПерФирм.Фирма;
                                    ДокПерем.ФирмаПолучатель=ТЗПерФирм.Фирма;           
                                    //ДокПерем.УстановитьНовыйНомер(СокрЛП(ГлобПрефиксИБ) + СокрЛП(ДокПерем.Фирма.ЮрЛицо.ПрефиксНомеровДокументов));           
                                    ДокПерем.ДатаДок=ДатаДок;                         
                                    ДокПерем.Склад=Склад.ВитринаСклада;
                                    ДокПерем.СкладПолучатель=Склад;
                                    ДокПерем.Валюта=Константа.ВалютаУпрУчета;
                                    ДокПерем.Курс=1;
                                    Если СПП.НайтиПоРеквизиту("Сотрудник",Консультант,1)=1 Тогда
                                        ДокПерем.Автор=СПП.ТекущийЭлемент();
                                    Иначе                            
                                        Сообщить(""+"Не найден пользователь для консультанта "+ВРЕГ(""+Консультант));
                                        ДокПерем.Автор=глПользователь;
                                    КонецЕсли;  
                                    ДокПерем.ЗагрузитьТабличнуюЧасть(ТЗДок);     
                                    ДокПерем.АвтоВремяТекущее();
                                    ДокПерем.Записать();
                                    ДокПерем.Провести();
                                    Если ФС.СуществуетФайл(КаталогПользователя()+"ЧекиПеремещения")=0 Тогда
                                        ФС.СоздатьКаталог(КаталогПользователя()+"ЧекиПеремещения");
                                    КонецЕсли;                                                      
                                    ТекстЧекиПеремещения.ДобавитьСтроку(ДокПерем.НомерДок);    
                                КонецЕсли;     
                            КонецЦикла;                                                  
                            Если ТекстЧекиПеремещения.КоличествоСтрок()>0 Тогда
                                ТекстЧекиПеремещения.Записать(КаталогПользователя()+"ЧекиПеремещения\"+СокрЛП(НомерДок));    
                            КонецЕсли;    
                            //Сообщить("Перемещения с витрины на склад успешно сформированы!!!");
                            ЗафиксироватьТранзакцию();

(140) пля. ну что тебе мешает все свернуть, отсортировать,СПП.НайтиПоРеквизиту("Сотрудник",Консультант,1), СоздатьКаталог(КаталогПользователя()+"ЧекиПеремещения"); и сделать прочую куйню _до_ начала транзакции? у тебя толпа документов стоит, кулаками в дверь стучится - а тут ты такой в шляпе, "щазз я кофэю попью, пользователя найду, тз сверну - а вы ждите, сцуки". Капитан гнездилов, мля

(141) ДА нет же главное это создание перемещений автоматом - вот для них и делал начало транзакции ну и не так часть автоперемещения создаются все-таки на продажном складе остаткков хватает. Знать бы все это раньше когда ваял

(140) ну как бэ.. выкинуть транзакцию к еб..ям, для начала

(135) В SQL можно. У нас уже почти юбилей :)
V7 SQL и гибкие блокировки.
Месяц назад запустили управляемые блокировки, после пары недель перелили в общую базу дочернюю организацию.
Итого сейчас в базе около 300 пользователей в режиме 29/7 (пользователи в 5 часовых поясах) :)
Сейчас идем дальше, начали тестировать свою запись регистров. Т.е. одним пакетом записываем все движения документа и обновляем итоги, получается симпотишно. Разница времени проведении оперативного документа и документа 10-ти летней давности в базе 180ГБ не больше 30%.

(142) это как-то влияет на то, что в транзакции должны быть только необходимые для сохраненния консистентности действия?

(144) круто!
а зачем вам 10-летняя задница? она реально нужна?  180Г/10 лет - объемы маленькие? (я имею ввиду "построчные" объемы)
"одним пакетом записываем все движения" - я так делал в первой "нагруженной" системе для в 1993, еще на клиппере.  потом как-то это все "рассосалось", в 1с в модулях клюшек, да и в ОФных клюшках - пишут как придется. а в УФной КА - глянул, тоже формируют все движения заранее и пишут пакетом. Вот она, диалектика, данная нам в ощущениях экзаменов по МЛФ, в действии....

(143) Ну выкину. Погляжу как жить станет

(146) Если честно то наверно и не нужна эта история, но есть-пить не просит, в работе особо не мешает. Вобщем базу никогда не обрезали, первый документ в ней от 2004 года. Я игрался с обрезанием но особого эффекта это не дает. Все что нужно все равно по своему проиндексировано. Вообще база до 2013 года была dbf-ная и тогда в целях оптимизации делались очень замудренные вещи :). Все длинные строки вытащены в отдельную sqlite-овую базу, т.е. сейчас в рабочей нет ни одного поля неограниченной длинны. Все важнейшие справочники разбиты на сам справочник (id,descr + крайне важные реквизиты но обязательно не больше 5 штук) и прочие реквизиты в отдельно справочнике иногда даже в нескольких.
Но и сама организация активно расти начала где-то с 2013-го года. Т.е. при переходе в SQL чистая база весила не больше 30ГБ, 150ГБ наросло за последние 7 лет.
А по поводу "УФной КА - глянул, тоже формируют все движения заранее и пишут пакетом" - так там только движения пишутся пакетом, а обновления итогов все равно построчно.
Я сейчас эксперементирую с MERGE. Тобишь на основе движений документов формируется кросс таблица по всем будущим периодам от момента документа и она мержится с итогами. Вычитается/Прибавляется к существующим, добавляются недостающие и удаляются то что по итогам становится нулевым. Пока вроде все хорошо получается, но как всегда пока страшновато это в прод пускать :)

(148) ну да, обрезание на сиквеле особого эффекта не дает - все равно активные страницы в кэше.  Я обрезал, чтоб базу на SSD вместить, тогда они были маленькими и дорогими, а в производительность уже упирались. В принципе, сейчас я бы еще многое поправил, и поднял производительность минимум вдвое. Но задний ум - это штука такая... всегда "после".
с мерджем - очень интересно. Расскажи потом при случае, хотя бы в той своей ветке.

Помнится, я игрался как-то с мержем для ускорения длинных запросов...
Так оно мне индекс скан в табле скан переделывало.... Я посмотрел и плюнул...

(150) Длинный запрос это что? Почему длинный?

(151) потому, что не черный

(151) Ну - во-первых, это была не 1с )))
Во-вторых - 10 экранов текста
В-третьих - выполнялся полторы минуты. А допустимо было не больше 15 секунд...

Конт.УстановитьНовыйНомер(СокрЛП(ГлобПрефиксИБ) + ПрефиксЮрЛицаФирмы); : {Глобальный модуль(5411)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем

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

А кстати. Период опроса изменений БД - 10 сек.
Или этот параметр вообще без разницы какой?

(0)(9)(15)
«И советуют время ожидания захвата таблицы БД в ноль установить.»(с)
И тогда ставить не Kernel37, а Kernel33.

(156) Почему?

(256) Кернел это же для файлов больше 1 ГБ - или я уже все подзабыл?

(256) один для выполнения запросов vfpoledb в монопольном режиме, второй для решения проблемы >1гига

(158)
Да. Но...
Вот текст из файла Kernel3x.doc:
«В комплекте имеется файл Kernel37.dll. Эта библиотека решает (кроме проблемы 1 гигабайта) еще и проблему “100% загрузка процессора при ожидании блокировки”»(с).
И алгоритм пауз блокировок Kernel37 не отключится если «в ноль установить»(с).

(159)
Нет. «уже все подзабыл»(с). :-)

Вообще несколько причин блокировок вижу конкретно:
1. ГлВводСчетаФактуры - там где ОткрытьФорму("Документ."+ВидСФ,ФормаНакладной,Конт.ТекущийДокумент());
2. ДокБухт.Новый - при программном создании нового документа из формы родительского так сказать
3. В процедуре ПробитьЧекНаККМ. Уже чек пробит и надо дозаписать то что пришло от ККМ - ФПД и т.д.

То есть практически из-за этих трех вариантов основные ошибки по транзакциям.
Могу ли я программно скажем если не получается ввести счет фактуру по кнопке отловить это чере
Попытка Исключение КонецПопытки как-то и автоматом заново попробовать через 10 сек к примеру?

Или если ДокБухт.Новый() - то же самое, то есть Время ожидания захвата БД в ноль стоит, но сам обрабатываю ошибку блокировки
или не могу так отлавливать и всегда вылетает ошибка?

(162)+ Можно конечно создавать ДокБухт заранее штук 100 с утра и затем распихивать их под родитлеьские документы, но сильно алгоритм курочить придется в этом случае хотя может не очень сильно.
Но а другие два. Может позже записывать эти реквизиты чека, пробили куда-то в память записали а потом пытаемся записать
в процессе работы может по обрабтке ожидания глобальной или еще как-то?
Но вот с вводом счет-фактуры кнопкой из накладной - также насоздавать пустышек счетов-фактур

Может можно похитрее как-то просто реально менеджер начинает на эту кнопку до упора нажимать пока не попадет в паузу между другими документами ?

(163)
Вместо Док.Новый  - Док.Найти - это "сильно курочить"?

глВводСчетаФактуры - ну возьми код прямо из заполнения, и все. Делов ровно на 5 минут.

Если дописываемые в чек реквизиты ни на что не влияют (не фигурируют в регистрах при проведении и т.п.) - можно писать их напрямую в документ.

(165) достаточно просто Записать() без проведения.. и усё.

(166) вроде надо ПриЗаписиПерепроводить(0)?
ну и все равно запись блокирует

(162) если у тебя розница - при чем здесь СЧФ?

(168) Да ещ и опт имется в большом количестве.
Вот видишь получается что в лоб как-то и не решить эти три вроде мелких проблемки.
Но вот Попытка Исключение КонецПопытки - ошибку транзакций обрабатывает?

(165) Возьму нет проблем. И что с ним делать? Ну вставлю его и не буду вызывать через глобальный модуль. И что изменится. Может при проведении накладной автоматом создавть СЧФ как бы после проведения через формексовское внешнеесобытие?

(100) думаешь что у него еще не было 2 гб? :-)

(171) Ни разу не было. Когда стало подходить свертывал год

(172)+ вот мд-ник помнится пересобирал только забыл чем а то он глючить стал

(170) "Может при проведении накладной автоматом создавть СЧФ как бы после проведения через формексовское внешнеесобытие?"
- у меня так сделано

..а то народ регулярно забывал СЧФ создавать к реализациям и авансам. бухгалтерия адски истерила пр нумерацию, хронологию и прочую нихер ане значащую поебень

(174) Ну да я же для чека так пробитие делал по товему совету. но вот записать() тут куда деться?

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

Ну а если ДБФ, то у него его еще проще отломать кусок старых записей.

Если  ПустоеЗначение(глСервис) = 1 Тогда Возврат; КонецЕсли;  //нет обработки асинхронных событий
    Если Проведен()=0 Тогда
        глСервис.ВнешнееСобытие("FAKIR", "ГЕНЕРАЦИЯСЧФВЫДАННЫЙ", ЗначениеВСтрокуВнутр(ТекущийДокумент()));
    КонецЕсли;
КонецПроцедуры //ОбработкаПроведения()

Эдакий закат солнца вручную.

//******************************************************************************
// глОбработкаВнешнегоСобытия(Источник,Событие,Данные)
//
// Параметры:
//  Источник,Событие,Данные
//
// Возвращаемое значение:
//  Нет
//
// Описание:
//  Вызов данной процедуры происходит из всех процедур ОбработкаВнешнегоСобытия(),
// располагающихся в формах справочников, документов, обработок и т.д., для
// обработки независящих от активной в текущий момент формы сообщений.
//
Процедура глОбработкаВнешнегоСобытия(Источник, Событие, Данные) Экспорт
    
    Если (Источник = "A100Online") ИЛИ (Источник = "A200Online") Тогда
        
        глОбработкаСобытияОтККМ(Источник, Событие, Данные);    

//[+]progadmin, 22.08.2013, ДОБАВЛЕНО НЕТИПОВОЕ
    Иначе
        глОбработкаFAKIR(Источник, Событие, Данные);
//[+]_progadmin, 22.08.2013, ДОБАВЛЕНО НЕТИПОВОЕ

    КонецЕсли;
    
КонецПроцедуры // глОбработкаВнешнегоСобытия()

(175) Главное здесь насколько я могу обработать ощибку и куда заветвиться после нее. ну то если все записалось и хорошо если по попытке не записалось значит обрабатываю исключение - куда-то пишу в память а потом оттуда вычитываю и дозаполняю автоматом

//[+]progadmin, 11.10.2013, ДОБАВЛЕНО НЕТИПОВОЕ
//******************************************************************************
// глОбработкаFAKIR_ГЕНЕРАЦИЯСЧФВЫДАННЫЙ(Источник,Событие,Данные)
//
// Параметры:
//  Источник,Событие,Данные
//
// Возвращаемое значение:
//  Нет
//
Процедура глОбработкаFAKIR_ГЕНЕРАЦИЯСЧФВЫДАННЫЙ(Источник, Событие, Данные)
    
    Если Источник <> "FAKIR" Тогда Возврат; КонецЕсли; //штатно
    ОткрытьФорму("Отчет",Данные,глКаталог+"ДОКУМЕНТ#СчетФактураВыданный#АВТОГЕНЕРАЦИЯ.ert");
    
КонецПроцедуры //глОбработкаFAKIR_ГЕНЕРАЦИЯСЧФВЫДАННЫЙ()    
//[+]_progadmin, 11.10.2013, ДОБАВЛЕНО НЕТИПОВОЕ

(181) какую ошибку?

(177) Прямым запросом в каждой базе откусить кусок регистра движения партий?

(183) Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем.

(184) по идее словить такую ошибку можно попыткой. или без попытки - обработка создания дока не возвращает результат успешности, ставишь паузу на 0.2сек и крутишь в цикле до 100 попыток например.

и всю разбухтовку-дочерниедоки тоже делать не в проведении дока-родителя

мне вообще мутная идея что такое разбухтовка твоя.

(177) "оно и на скуле можно дойти до ограничения на размер таблицы." ПОделись примером?
- насколько я помню из писькомерных веток конца нулевых, у чемпиона база была под 700 гектар, и до ограничений он так и не добрался...

(188) Пашет с 2003 года безсбойно ну конечно коче что за эти годы улучшил основательно.
Разбухтовка не в модуле проведения в процедуре ПриЗаписи() как бы родительского документа

(177) дбф - не проще. переиндексация нужна.
а в сиквельной - да, автоподрезка прекрасно работала, оставляя 37 месяцев... Первые пару месяцев ссыкотно было обрезу роботу доверять, а после - привык.

(190) только транзакциями клинит....

(186) ну было как-то типа долбежки раза три, не получилось - пауза, и опять. не прошло в течение 20 циклов - тогда считаем обломом.

(192) "и коллектив прекрасный, и зарплата хорошая - но как пожар, то хоть увольняйся"©

(192) Заметь клинит нечасто и потом именно ДокБухт.Новый() - именно эта операция клинит  часто. Можно заранее правда насоздавать пустышки чтоб крайне редко выходил на эту операцию

(194) Да нет, просто хочется как-то улучшить ситуацию - понедельник и пятница и так последние 2-3 месяца до этого как-то болееменее спокойно было

(195) млять. "можно" было бы уже это сделать за вчерашний день. исправить десять строк кода в одной обработке, и вторая в пару десятков строк.

(197) Вот занимался маломть другими делами весь день. Нет десятью строками не обойдешся. но задался такой мыслью всерьез

(197) А все-таки по поводу обрезания движений - было бы здорово. Какой-нибудь примерчик бы. На фоксе что ли написать. Когда то ж такие вещи как семечки щелкал

(199)
    Если флУдалитьРегистры = 1 Тогда
        Начало = _GetPerformanceCounter();

        Для ном = 1 по Метаданные.Регистр() Цикл
            Рег = Метаданные.Регистр(ном);
            Состояние("движуха регистра "+Рег.Идентификатор);
            Сообщить("движуха регистра "+Рег.Идентификатор,"i");
            
            Если Рег.БыстраяОбработкаДвижений =0 Тогда
                ТекстЗапроса ="
                |DELETE
                |FROM $Регистр."+Рег.Идентификатор+"
                |WHERE iddoc in (select Жур.iddoc from 1sjourn Жур where
                |
                |dtos(Жур.date)+Жур.time+Жур.iddoc between (dtos(:НачДата~~)+'      '+'         ')  and  (dtos(:КонДата~~)+'ZZZZZZ' + 'ZZZZZZZZZ')
                |)
                |";
            Иначе
                ТекстЗапроса ="
                |DELETE
                |FROM $Регистр."+Рег.Идентификатор+"
                |    WHERE
                |        DTOS(date)+time+iddoc+STR(lineno,4)+STR(actno,6) BETWEEN
                |         DTOS(:НачДата~~)+'      '+'         '+'    '+'      '
                |     And DTOS(:КонДата~~)+'ZZZZZZ'+'ZZZZZZZZZ'+'ZZZZ'+'ZZZZZZ'    
                |
                |";
            КонецЕсли;            
            Запрос.УстановитьТекстовыйПараметр("НачДата", '01.01.80');
            Запрос.УстановитьТекстовыйПараметр("КонДата", ВыбДата);
            Если Запрос.ВыполнитьИнструкцию(ТекстЗапроса) = 0 Тогда
                Сообщить("что-то пошло не так движуха регистра "+Рег.Идентификатор,"!!!");
            КонецЕсли;
        КонецЦикла;
        Сообщить("Движения регистров затраченное время: "+(_GetPerformanceCounter()-начало));

    КонецЕсли;

(197) так я и не понял - не влазя вглубь отчего там у него клинит на Док.Новый()

(200) еще vfpoledb ?

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

(202) скулайтом можно

(203)+ В каждом документе есть поле СБухт. Вот в нем номер документа разбухтовки ну а дата у них одинаковая

(203) подбираешь нужную нарезку что ли?

(205)+ Просто заметил что процентов 30 ошибок транзакции - из-за этой операции

(206) Ну да, подбираю и в приходе разбухтовываю и в перемещении и в списании и т.д.

(205) да похорен как сделано (пока).
что делает эта разбухтовка?
из имеющейся инфы по длинам отрезков мерного товара подбирает нужную длину? или что?

(209) Выбирает метражи (в приход их создает, в расходе их списывает по метражам с возможностью отреза и создания тут же новых метражей

(210)+ Ассортимента кабельного много поэтому почти в каждом документе по складам где не установлен ффлаг "не вести учет бухт" идут эти операции, включая чеки ккм, только дял них свой вид разбухтовки - докбухтчек

(211)+ .ну просто много ошибок транзакций именно на такой строчке ДокБухт.Новый() и еще после разбухтовки порой не получается записать родительский документ (из-за ошибок транзакции) и тогда надо опять резать по новой

(200) в файловой я такое не делал и не стал бы, наверное...
хотя может я просто неопытный, Ёп или Джеф или ССерж наверняка бы сделали.

(200) НачДата понятно, а КонДата ставить какую? три года назад?
А если это регистр продажи те же - он же оборотный, с ним такое конечно не прокатит

(214) оставляй три года предшествующих текущему.

(213) ну я так в ПБ тупо чистил от остатков чужих ПБ. нормально все.

(210) Метражи - в партиях написаны/хранятся?
в реализации - как набираешь? идейно как? - набираешь максимально длинными кусками или как?
(может там просто тупо медленно получается и если ускорить, то и проблема уйдет?)

(217) Нет. Там вполне шустро, если есть такой или почти такой кусок сразу на него курсор и можно подобрать мгновенно.
К партиям не привязывал, изначально решили что все по номенкалутре и метражу.

Спасибо. Подвинули меня. Я тут накидал быстренько автоподбор бухт при поступлении (в товаре сидит реквизит автобухтметраж и документ бухт по таким товарам (где задан) формирую. А по каким нет - в разбухтовываю как обычно. Операторы склада давно просили а я все никак. Теперь вроде как )

(218) "если есть такой или почти такой кусок сразу на него курсор и можно подобрать мгновенно."
у тебя что, подбор метража делается интерактивно пользователем?

(218) "К партиям не привязывал, изначально решили что все по номенкалутре и метражу."
вообще непонятно.
ты можешь связно изложить как у тебя реализован аработа - приход, учет остатков и расход по мерному товару? ;-)

(220) Регистр "ДвижениеБухт" Номенклатура Метраж КоличествоБухт
При расходе беру из остатков регистра по фильтру номеклатура затем становлюсь в обработке ДействияСБухтами на нужную строчку и нажимаю ОК - выбираю сколько метров - получается количество бухт или если указываю которого нет - получается отрез

(221)+ Эта обработка действует что при приходе что при расходе, только при приходе выбирается метраж или если нет -вводится новый и количество бухт

(220) А вот в твоей процедуре обрезания - не могут случайно туда попасть регистры оборотные?
Ведь это только для остаточных надо

(223) это не моя. валялась обработка для обрезки базы.
оборотные в принципе то же самое.
если исключить оборотные - то по методанным тип регистра проверь и все.

(224) Не постесняюсь спросить - а оборотные же RG... кажется не имеют ?
А что тогда в них резать?

(224)+ Кажется допер. Главное чтобы не поднимались потом движения по этим документам по этим регистрам.
Хотя если я обрежу регистр "продажи" и потмо захочу полную статистику я ее в любом случае не получу ибо регистра итогов же нет.

А кстати после обрезания как с индексами?

(226)+ RG есть и у оборотных. То есть если не брать по документам можно цеплять из RG а если надо уже по документам то тогда только RA и поэтому его обрезать нельзя

(224) А регистры книга продаж и покупок вообще надо на фиг закрыть хотя сначала тоже обрезать движения

(228) если ты не ведешь книг в базе ТИС - можно тупо их удалить 4 файла для регистров книг

(229) Только сначала убрать из конфы все ссылки на них
А еще: открываю постпуление через "лупу". Не блокируется, открываю просто при этом Форма.ТолькоПросмотр в ПриОткрытии стоит остальное закомментировал. Результат - блокировка, то есть другой юзер не может открыть документ этот.
Так много текстовых формул, но почему через "лупу" когда открываешь - просто закрывается форма документа, а когда просто открываешь вроде в режиме ТолькоПросмотр(1) при закрытии спрашивает - сохранять изменения - хотя я ничего не менял.

Я читал твою ветку про ТолькоПросмотр, но вот видишь что выходит. Может надо все реквизиты формы - доступность(0), хотя шапка серая и т.ч. серая - в чем хоть отличие?

(229) ТЕперь на спрашивает про сохранение но один хрен не дает другому открыть этот документ хотя вроде только просмотр(1)

(229) Мне надо - если поступление проведенное по определенному складу - то без полномочий - режим лупа должен получаться без блокировки, чтоб тот укого право есть мог спокойно зайти в документ

(231) "только просмотр(1)"
не, когда через лупу - то не блокируется.
а когта обычным образом но только просмотр - блокируется.
именно так.

(230) "при закрытии спрашивает - сохранять изменения - хотя я ничего не менял."
не, что-то поменялось на форме.

(230) "Только сначала убрать из конфы все ссылки на них"
можно ничего не убирать. просто регулярно удалять файлы книг. или поставить везде где к нм обращение идет в модулях проведения - сделать "возврат, там не так много мест. минут на 30 работы "выключить" таким способом

(233) То есть с эмуляцией "лупы" ничего нельзя сделать? Даже с помощью формекса?

(236) Это можно сделать штатными средствами, без формекса.
В журнале документов есть предопределенная ПриВыбореСтроки(). В ней анализируешь как нужно открыть документ и при необходимости:
СтатусВозврата(0);
ОткрытьФорму(ТекущийДокумент,,1);

(237) Да, интересно, только не понял куда вставить процедуру ОбработкаВыбораСтроки(1) или так: Форма.ОбработкаВыбораСтроки(1)
В модуле формы журнала документов поступлениетмц

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

(237) Процедура ПриВыбореСтроки()
СтатусВозврата(0);
Если (ТекущийДокумент.Вид()="ПоступлениеТМЦ") И (ТекущийДокумент.Склад=Константа.СкладДляПрихода) И (глЗначениеПоУмолчанию("РазрешитьСкладДляПрихода")=0) Тогда
  ОткрытьФорму(ТекущийДокумент,,1);    
Иначе
  ОткрытьФорму(ТекущийДокумент);
КонецЕсли;    

Так работает если в ПриОткрытии журнала установить обработкавыборастроки(1)

И все в штатном режиме. Только вот в документации все так завуалировано что хрен поймешь
Это типа ПередОткрытием документа получается то есть еще на уровне модуля формы журнала а не документа
ОГРОМНЫЙ СЕНКС !

(233) Странно что в ветке про открытие в режиме только просмотр, которую ты поднимал - не было про такой вариант ничего сказано,
а ведь он абсолютно однозначно решает проблему

(241) решается все проще. Поставь в настройках базы что документ ШТАТНО ОТКРЫВАЕТСЯ на просмотр (лупой). по энтеру. а по шифт-ентеру будут открывать на редактирование ;-)

(240) ну и хоть не принципиально, но я обычно делаю часто используемые константы кеширую
глСкладДляПрихода = Константа.СкладДляПрихода;

(242) Да, это я знаю, но пока обойдусь тем что написал.
Насчет констант - согласен, сделаю список значений, вот только как при этом быть с преиодическими константами?

(244)+ Много обращений к константе хотя в цикле как-то не увидел. Ты где-ниубдь видел чтоб в цикле к константе обращались?

(245) а что за фобия с циклами?

(246) Да нет фобии никакой. Просто речь идет о том что если обращаться к константам в цикле это грузит систему.
Кешировать это хорошо, правда вот не понял что значит двухуровневый кэш в таком контексте. Ну мы же используем ГлПользователь и все его реквизиты - вот и кэш собственно говоря

(246) да это я его напугал.
просто где-то попадалось, что при обработке проведения в цикле каждой строке документа что-то сравнивалось с константой, или заполнялось ли по умолчанию из константы. И так работа с константами не самая быстрая, а тут еще в цикле. может, исправили уже, а может, франчи тогда до меня написали (они и Вопрос() в обработку проведения вставляли, и их код копипастный в одном доке сократил по длине в 30 раз... дело давнее)
(247) двухуровневый кэш цен - это текущие цены ты кэшируешь в одной таблице (можешь сразу при запуске, можешь в порядке обращения, можешь группами по обращению, можешь во время простоя), а при обращении к заднему числу - кэшируешь изменившиеся во второй. Собственно, это от специфики зависит - у меня могли изменять документы последних 2-3 рабочих дней. Для розницы - это неактуально. Но с периодическими константами можешь поступать примерно так же (дата раньше, скажем, месяца от текущей - запрашиваешь из базы, до месяца - кэшируешь. Текущая должна быть уже в оперативом кэше)

(248) Да, можно так. Но вот я изменил значение константы а она закеширована. Получается где-то должна быть передача того что константа изменена и кэш должен обновиться. Но фокус в том что кэш же для каждого сеанса отдельно. То есть надо передавать некий флажок. И где-то в обработке ожидания его мониторить. И опять же вопрос и когда флаг этот удалять?

(249) "Но вот я изменил значение константы а она закеширована"
а нехер менять значение константы при работе.
ты же колеса на авто не меняешь на ходу...

(250) Это крайне редко бывает, почти никогда не меняется

(250) Ну а все-таки?

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

(252) Можно и так конечно. Реально правда единственное что меняется иногда это дата запрета редактирования и то редко. Остальное меняется только в нерабочее время. Еще иногда константа время окончания работы для автозакрытия 1С-ок. Но тут как-то извращусь

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

+(255) не, наврал - первоначально он был для сообщения о поступлении заявок с КПК. дикие времена...

(256) У меня тоже с КПК ). А теперь просят чтоб сделал со смартфона тоже самое, только на кпк вводился только код а тут надо искать по наименованию еще

(256) Вы имеете в виу виндовый планировщик или в 1С глобальом модуле обработкаожидания ?

(258) не, локальный 1совский, через обработку ожидания. честно скопипизжен из конфиги а+ емнип 2004 года. у меня все через него было сделано -завершения работы, сообщения пользователям,  запуск обработок - пересчета себестоимости, автообрезки базы, контроль/пересчет итогов регистров, всякие рассылки отчетов поставщикам, формирование кубиков ОЛАП, обмены со снеговиком. я даже уже и не упомню всего.  там удобно сделано, почти как в снеговике.

(259) Может поделитесь. Интересно было бы глянуть на такое чудо

(260) поищи конфигурацию ТИС для А+ 1.5, у меня если и осталась - то моя доработка под сиквел, на дбфной не заведется сходу.

(261) А+ 1.5 ? Агент плюс какой-то?

(261) В скате когда-то много интересного было. Но не использовал. Вроде и так работает. А зря кстати

(250) ГлСистема = СоздатьОбъект("Система");

Для сч=1 по 100 Цикл
Попытка
  ДокБухт.Новый();
  Прервать;
Исключение
  глСистема.Sleep(500); //0.5 сек
КонецПопытки
КонцеЦикла;

Если я буду делать через попытку исключение конецпоппытки создание документов (что докбухт что сф) в цикле от 1 до 100 через паузу 0.5 сек (пауза используя 1с++), цикл мне процессор не загрузит напрочь?

(264)+ И аналогично только без Попытка Конецпопытки а просто
в цикле с паузой
ГлСистема = СоздатьОбъект("Система");

Для сч=1 по 100 Цикл
Если ОткрытьФорму("Документ."+ВидСФ,ФормаНакладной,Конт.ТекущийДокумент())<>1 Тогда
  глСистема.Sleep(500);//0.5 сек
Иначе
  Прервать;
КонцеЦикла;

(249) Пусть все перезайдут в базу и тогда кэш обновиться. Ибо константа это не то что меняешь 24/7

Ну или сделай кнопку "обновить кэш" которая обнуляет кэш. Кому надо нажмут не перезаходя

(266) Абсолютно согласен. Переделаю на кэш. И кнопка тоже неплохая идея. Кому надо - я сообщу
А что скажете насчет (264,265).

Везде блокируется 1sjourn
Именно его блокировка - причина львиной доли ошибок связанных с транзакциями.
Попробовать везде через попытку и паузы в цикле скажем из 20-50 итераций?

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

(269)+ А вот при проведении как-то и нет ошибок.
Просто опасаюсь что понаставлю циклов с паузами и процессор окажется перенагруженным хотя на сервере их вообще-то два

(269) ускорить проведение документа нельзя?

(271) То есть?
Проведение и так шустрое ну если только не задним числом.
А вот с циклами и паузами в "узких" местах как сделать?

(271) то есть попробовал операцию - блокировка, пауза, еще раз операцию, а в паузах другие же смогут что-то делать как раа глядишь и разрулится проблема

(273)+ И потом: ну поставлю я попытка конечпопытки на узких местах, но по исключению куда ветвиться? Когда ошибка транзакции - она просто всю процедуру откатывает и все.

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

(270) А откуда при проведении ошибкам то взяться.
Может ты не совсем правильно представляешь тему блокировок.
Вот как это работает:
При проведении 1С полностью блокирует 1sjourn. В этот момент в него нельзя ничего записать.
И разблокирует его после завершения проведения.
В это время нельзя создавать новые документы потому как новый номер для документа берется как Макс.номер из журнала + 1. И чтобы одновременно не взялся один и тот-же макс.номер на время создания документа так же полностью блокируется 1sjourn.
Тобишь если у тебя проведение длится 1 секунду, то у тебя может в системе быть создано не больше 60 документов в минуту, ну а так как у тебя еще во время проведения делается какая-то разбухтовка которая там на 3000+ строк, то почти уверен что проведение у тебя больше 1 секунды.
Задача максимально сократить период блокировки журнала.
Я бы лично для начала смотрел можно ли эту разбухтовку делать не в транзакции, тобишь на форме по кнопке Записать сразу делать разбухтовку, привязывать к документу а при проведении ее как то корректоировать если нужно.

+(276) Кстати кажется в DBF и прочитать ничего нельзя в период блокировки 1sjourn. Это только в SQL 1С для отчетов грязно читает. В ДБФ и отчеты по документам/регистрам зависают пока идет проведение.

проведение не блокирует на чтение.

вроде так.

(278) А вот и блокирует :)
Даже 1SQlite не может прочитать ничего из журнала при проведении в другом сеансе.

(278) Ещё как блокирует

В дбф точно.

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

+(280) Тобишь если какой-то отчет строится по регистру и ему нужно связать этот регистр с журналом, то отчет однозначно будет ожидать завершения транзакции.

(276) Но сама процедура проведения разбухтовки милисекундная по-сути.
И в модуле проведения родительского документа я ничего не провожу и не записываю по разбухтовке.
Я это делаю только через процедуру ПриЗаписи(). Потому что она если что все откатит назад и грязи за собой не оставит

(276) а про номера документов - 1SDNLOCK там еще задействован

(286) А он все равно вторым идет. Сначала берется максимум из журнала, потом уже он уже смотрится есть такой в 1SDNLOCK или нет.

(283) Насчет счф согласен,но вот сегодня понедельник и до 9.00
много ошибок ДоуБухт.Новый() и ДокБухт.Записать()
С блокировкой журнала документов.
Цикл с паузой имеет смысл пробовать?

(276) Бальзам на мою душу ) ибо у меня так и сделано - по кнопке записать проводится разбухтовка а в проведении дальнейшем она уже не трогается

(288) Конечно имеет, как минимум меньше непонятных для пользователя ошибок будет вываливаться. Но только не в транзакции, то это просто убьет базу наповал :)

(290) да не в транзакции а через попвтка исключение конец попытки.
А как правильно сделать ццикл с паузой чтоб процессор не нагружать?
А то у летит в 100% и вообще труба )

(275) Расшифруй понятнее:
сли не удастся забороть - тогда ставь все проведения в очередь или с использованием исключительной блокировки через флажок или тупо организуй очередь  и проводи все в одном сеансе роботом. както так

1. куда писать время проведения документа чтоб понять что долго проводится ессно только там где речь о документах с ТЧ. А то елси в текстовый файл - то проведение начинает замедлятсья когда этот файл вырастет прилично.
2. Что значит исключительная блокировка через флажок.
3. НЕТ У МЕНЯ НИКАКИХ РАЗБУХТОВОК В МОДУЛЕ ПРОВЕДЕНИЯ. Только при записи

(280) ну вот вкооррячил я в процдуру проведения предупреждение-стоп в одном сеансе. Если бы это блокировало журнал на чтение - то хрен бы журнал любой в базе открылся бы на просмотр - а так совершенно спокойно открывается.
и реестр документов по Док.ВыбратьДокументы(ДатаН, ДатаК) - спокойно читает. я еще для верности влупил Док.ИспользоватьЖурнал(). нормально реестр доков строится.
.
я что-то не так понимаю?
.
созлдать новый документ - да, напарывается на транзакцию.

(291) "как правильно сделать ццикл с паузой"
Shell.Sleep
Командасистемы("ping 127.0.0.1 -w 1000")
и ещё много разных способов.

(291) система.слип - нормально паузу делает

(295) ТАк это пауза а сам цикл скажем из 20 итераций - обычный? Для сч =1 по 20 ?

(292) п.2
там где критичные узкие места - проверяешь типо:

Цикл 1=1
если ФлажокВзведен = 0 Тогда
  ФлажокВзведен = 1;
  делаю что надо
  ФлажокВзведен = 0;
  прервать;
иначе
  жду пока флажок сброситься
конецЕсли;

(297) Да вот только флажок же для только моего сеанса он же между сеансами не передается.
Каким образом сработает проверка Если ФлажокВзведен когда он был взведен на другом сеансе? Через файл?
Через константу?

(296) ну это уже икспериментально надо подобрать.
сначала тупо залогировать насколько долго тупит при создании документов. или где у тебя там узкое место.
и почему именно в ПНД с утра.. чем это понедельник так от других дней отличается.
может у тебя по понедельникам там востановление ГП в фоне идет...

(298) блокировка служебного элемент служебного справочника

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

(300) Да понял, хорошая придумка. И так до упора, пока не освободит?
(299) Нет, ГП я вообще не использую. С утра в понедельник Поступление и большие перемещения с центра на магазины (все делается в ЦБ)

(.) проверь почту, я тебе какое-то УГМамонтов скинул, откуда можно взять планировщик

(301) Да, пробую уже так делать. Но это только на Создание.
На ДохБухт.записать() - мне это не поможет

(303) Видел и поблагодарил

(300) Справочник из одной записи служебный с одним полем - так получается?
И ФлагВзведен - это если элемент этот не блокирован

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

(302) " и большие перемещения с центра на магазины"
вот они у тебя и тупят. потому что скорее всего делаются задним числом (?) (а предыдущий документ от ТА - это уже заднее число). плюс перемещения возможно у тебя тянут партионку, а если регистр незакрыт - обьем обработки в проведении будет большой, вот тебе и тормоза. И я очень сомневаюсь что даже 30 манагеров прям таки раком могут поставить базу если они проводят документы интерактивно и документ проводится до секунды.

(304) а записать - долби, пока не продолбится, только давай паузу, чтоб другие.
(306) (300) а ишшо при "взведении надо проверять, что его другой в это время не взводит :-)"

(307) При записи делай асинхронное генерацию внешнего события и после записи документа это нормально отработает.

(303) а мне?!

(311) В очередь, щукины дети - в очередь! (с)

(309) потенциально - наверное да. но взвести такой флажок - это быстро. очень быстро.
у меня на таком принципе было сделано когда расфасовка книжек по заказам разными людьми делалась, чтобы пересорта/лишнего не случилось

(303) Тоже люблю УГ Мамонта посмоктать :)

(311) а оно те надо?

(315) Ну они все есть у меня в адресной.
Если вы не против - тут же перешлю

(316) кидай, мне не жалко.
Просто сейчас продолжать делать что-то на клюшках - странно...
Хотя, они, конечно, "неисчерпаемы, как атом"©

(315) а то ж!
у меня крутится простенький робот-планировщик, но хочется побольше возможнгстей

(317) на 8-ке делать еще страшнее.
осваиваю EYA/
это иснтрумент для ручной работы толпы обезьян. автоматизации по минимуму.
ошибок - вагон.

(308) Регистр партий в-основном кончено закрыт, RА328 намного меньше RG328
А какое внешнее событие генерироватьв процедуре ПриЗаписи() ?

(318) перекинул. Если надо будет для сиквельной - пиши, там выборка немного  ускорена, на пару порядков вроде. поищу

(321) не скуль не надо. спсб.получил

(320) должно быть наоборот РГ (итоГ) должен быть раз в 10 меньше РА

(320) да похрен какое. главное сгенери ;-) выше в ветке я для автосоздания СЧФ код написал.
абсолютно аналогично.
.
только надо посмотреть аккуратно  что запись отдельно идет интерактивная или с проведением.

(323) ДА наоборот же РА намного больше РГ. Просто затупил

(324) Тогда для чего его генерить? если по хрен какое)

(326) для того, чтоб на него отреагировать и создать док..

(319) Эх, я вот с СКД воюю. шткуа мощнейшая, но себе на уме. Убивает отсутствие внятной доки. Рекомендации на ИТС и книжка дают примитив, который и так понятен. а сложнее - уже хреннайдешь, только разбираться методом нашего известнейшего профэссора...

(328) Ты с ней воюешь, вот она тебя и убивает.
А ля герр ком а ля герр, понимаешь ли....

)))

(329) угу. подружиться не получается

Получается что надо максимально ускорять провведение документов. Именно тут собака зарыта.
Хотя если задним числом через РассчитатьИтогиНа - тут сильно и не ускоришь вообще-то. И еще же одно замедляет.
Если один и тот же товар в нескольких строках. Потому что партии тогда будут списыватьс  учетом уже списанных. И Это ксатит тоже тормозит проведение, ведь такая возможность в нем учтена

(331) Вроде прямые запросы и для ДБФ есть?

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

(331) это, вообще-то, базовая штука: максимум готового, минимум расчетов в транзакции.
(333) кроме как цены получать - у прямыхЪ запросовЪ есть еще много других применений.
(332) не помнишь, как в дбфной версии РассчитатьИтогиНа делаются - пробегом по РА, или выгрузкой выборки РА во временную дбф, как с запросами?

(334) Не работал с ДБФ прямыми

(335) не, не прямыми - именно при штатной работе. как прямые работают - я знаю

(326) причем отреагировать и создать во время простоя системы

(331) в оперативной работе убить нахуй всю работу задним числом. особенно реализации, перемещения и прочую хрень. не вижу никакой необходимсоти проводить это в оперативной работе задним числом массово.

(338) Хорошо бы. Ну воте сли резюмировать - то получается что я вставляю в цикле с паузой попытку исключение конецпопытки в узких местах связанных с созданием и записью дополнительного документа к родительскому и мониторю время проведения документов, если вижу что сильно длинное - пытаюсь уменьшить. То есть никаких сильно неправильных дел в базе нет и все это вполне обычно для работы одновлеменной многих пользователей.
Даст ли что переход на гигабитные хабы или это мелочь?

(339) ОМГ Клюшки по сетке это зло!

(34) В терминальном режиме. если б по сети до 40 юзеров - я б нобелеввку получил бы )))

(341) Лови архив V7dbnet https://cloud.mail.ru/public/C3fY/CWQwnhy5L
Это клиент-серверная база 1С 7.7 на dbf. Сайт у wirth давно сдох, но там внутри хорошее руководство по установке есть.
foxpro, если используется работать не будет, а 1sqlite будет.
Ну и что за проблема поднять терминал на 40 мест? Нынче память дешевая, и процы слишком быстрые.

А, в терминальном все таки! Неверно прочитал. Ну и чем тогда замена сетевой хабов поможет?

+(343) В терминальном очень сильно помогает патч FlushFileBuffers Книга знаний: Ускорение 1С:Предприятие 7.7

(343) Вот получается что ничем. Ладно. За неделю=другую соберу статистику в ЖР по времени проведения через _getperfomancecounter в начала и в конце обработки проведения и посмотрю что будет

(339) у тебя ж терминальник. пофиг какой канал

(340) (341)  ну у меня только на 85-м юзвере  затыкались.

(347) 50 с лишним бывало но до 85 как то не доходило)

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

+(347) наврал. 75

(344) Спасибо. Вроде не звморачивался, сейчас заморочился

(292) А как организовать очередь проведения документов - может было бы хорошо именно так.
В понедельник хотя бы -
1. чеки ккм (с утра их немного)
2. рко и пко (с утра много, но там проведение наносек)
3. Поступление ТМЦ (вот здесь может быть много-много сторк и относительно много документов)
4............прочие

(352)+ Нет, лучше глянуть насчет времени проведения с записью события в жр и обработать те ошибки что обнаружил связанные с программными опреаицями над доп. документом в призаписи и в призакрытии "родительского документа"

(352) анакуа тут очередь-то?
чеки проводятся когда вводятся, рко-пко тоже
Для поступления тмц и перемещений - можешь подготовить заранее элементы справочника ПартииТМЦ

(353) Я конечно понимаю что может быть уже проверил, но проц случаем не перегревается?
У меня как-то 3.3 на 1.6 троттлил... Не всегда все программно же решается.

(354) Заранее? Для постпуления тмц так и получается потому что их грузят моей универсальной обработкой из различного вида файлов (csv dbf xml txt xls) - получается что все кроме разбухтовки - готово. Затем разбухтовка и весь процесс завершен. Что касается перемщения - мысль интересная, но поскольку что-то корректируется задним числом то возможно партии эти поменяются и документ перепровести уже не удастся, надо либо на авто либо переподбирать партии. А так идея сокрашения времени проведения - очень даже здравая. Спасибо!

(352) "3. Поступление ТМЦ (вот здесь может быть много-много сторк и относительно много документов)
- в поступлениях шттано в ТИС нет ничего сложного. проводится практически мгновенно.
если ты только руками туда не понапихал всякой хрени типа разбухтовок каких нить..

(356) перемещения..? корректировать задним числом? нахуа?!

(357) Нет у меня вооблще разбухтовок в модулях проведения, есть только в ПриЗаписи чтоб в единой транзакции все было иможно было откатиться.
(358) Да потому что это перемещения с ЦС на магазины, и там есть куча всяких нюансиков поэтому приходится порой перепроводить их, там еще отдел перемещений дорабатывает иъ.

(357) Если ЖД заблокирован то значит кто-то его проводит хотя ПриЗаписи ведь записывает же и шапку и тч документа если он еще не был записан. Но все равно если блокировка значит в этот момент кто-то что-то проводит. Так ведь?

(360) не обязательно проводит. открой DD и посмотри что в журнале общем полном написано по реквизитам.

(361) ну да

(358) переместили-недопереместили-перепереместили... перемещали-перемещали, да не выпереместили...

(363) А что происходит в процедуре призаписи - там же явно сама пользовательская часть а ведь есть еще неявная системная. То есть пришем ЗАписать(). Это запись в базу данных. А призаписи и только когда интерактивное сохранение объекта - это как бы то что увенчивается самой записью в базу, все реквизиты тч и шапки раскидываются по своим таблицам

(364)+ То есть блокировка возможна когда запись идет процедурой записать() Но мне кажется что это очень короткая процедурка.

(364) ПриЗаписи (которая вызывается при интерактивной записи) ничего не блокирует. просто заполняет реквизиты объекта (в памяти)

(366) Ага понял, но она же заканчивается хоть и неявно методом Записать()

В монопольном режиме но задним числом (в милисек)
Реализация  ЭлТД006710 (20.10.20) ВремяПроведения 3460
Вот еще
Реализация  ЭлТД006874 (23.10.20) ВремяПроведения 4033
Медленновато похоже

(368)+
Монопольный, новые 1 строка товара
Реализация  ЭлТД006879 (02.11.20) ВремяПроведения 55
Монопольный 2 строки
Реализация  ЭлТД006878 (02.11.20) ВремяПроведения 151

(369)+ Вывод понятен. Новая формируется в раз в 30 быстрее

(365) в Записать() собственно в самой - никаких блокировок нет. если ты только руками туда не вписал чтонить транзакционное (как у тебя с бухтами) (еще и см. выше хз как там у тебя отрабатывает разбухтовка при записи когда ты повтрно записываешь документ с уже ранее сделанной разбухтовкой)

(368) задним числом 4 секунды - это трэш адский. ткаое допустимо только в монопольном режиме в регламентых работах. у меня под 3-4 секунды реализации задним числом проводятся которые под несколько сотен строк... я сомневаюсь что у тебя в розниуе такие реализации ;-) поэтому заднее число УБИРАЙ НАФИГ. чем больше тем лучше. ситуация сразу станет на порядок легче. и манагеры у тебя тупо открыв документ в ззаднем числе на просмотр тупо жимут ОК. с перепроведением задним числом и всеми прелестями этого.

(372) А еще варианты? Не могу я отказаться от заднего числа.
Надо как-то оптимизировать запросы что ли в модуле проведения. Там еще высчитывается просрочка задолженности контрагента согласно условиям договора. А ведь это тоже запросы к регистру

(373)+ Не чистил все эти процедуры ибо они в-основном из типового ТИС взяты с добавлением своих как бы внешних нюансов

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

(373) " Там еще высчитывается просрочка задолженности контрагента"
- с дуба рухнул? в типовой в модулях проведения никаких просрочек задолженнойтсей на рассчитывается.

(376) А это уже я сам вставлял наверное. Не помню. Буду смотреть раз такая хреновая ситуация. Но пусть проводится 3-4 сек, не так уж это и много. Хотя елси взять все доки которые хотят провести пользоватлеи до 9 утра - вот им времени получается и не хватает

(377) проблема не втом что им времени не хватает. проблема в том что они ломятся все массово. хотя это нахер не надо.

(378) А что - запретить им проводить? Что значит массово ломятся? Надо делать документ и они его делают, насчет того что перепроводят по ОК - да нет, просто закрывают и все.

читай (40) долго думай.

И да, запрещать кому-то чего-то.. это моветон

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

1. Почему в групповых обработках проведения? Мне что не проводить документ после его записи интерактивно? А проводить групповой обработкой?
2. Как называется эта вот ошибка блокировки если я ее поймал в исключениях ?
20 попыток  без пауз? а если все-таки будет продолжаться тогда же надо чтобы отшибла транзакцию и всякая "грязь" чтоб не осталась.

Но главное конечно - это групповая обработка проведения. Что вы под этим в данном случае понимаете?

(382) если ты спрашиваешь об этом, то у тебя их нет.

(383) раз в квартал я делаю перепроводку базы.
Пожалуйста расшифруйте мне ваш пост (40)

(384) если ты не пользуешься групповыми обработками для изменения реквизитов документов, типа юниджорнал/ючойз/сетатрс и т.п, то тебе достаточно прочитать только первый абзац в (40). Всё.

(379) " насчет того что перепроводят по ОК - да нет, просто закрывают и все."
да, именно. просто закрывают. ПО КНОПКЕ ОК.

(0)
Посмотрите мои «теоретические» :-) рассуждения тут: http://catalog.mista.ru/1c/articles/87339/
И сделайте рекомендации из сообщения (40) учитывая текст из (156) сообщения.

(385) Пользуюсь реплвал в-основном. Время Ожидания в ноль установлено везде.
Но вообще конечно 3-4 сек на проведение документа пусть и задним числом - это что-то до хрена.
(387) Смотрел. Обратил еще внимание на (156). Дело в том что я пользуюсь кажется solution6 (секретным релизом), который много всяких вопросов мне помог решить. Насчет кернел - надо глянуть. Я так понял что кернел33 обеспечивает только работу с дбф свыше 1 ГБ а кернел37 решает вопрос и 100% загрузки процессора при транзакциях и проблемы 1 ГБ.

(385) При работе под SQL проблемы транзакций пропадают или все равно дело в движке 1С?

(387) То есть мне надо DBEng32 Ваше себе установить? Заменить НачатьТранзакицю Попытка Исключение КонецПопытки ?
Ставить на проведение в очередь? Каким образом? При чем тут учойс сетатрс или униджорнал?

(387) А как мне понять теперь уже у меня кернел33 используется или кернел37?
Получается что если время ожидания в ноль то мне достаточно кернел33 для решения проблемы 1 ГБ?

(391) Получается что при установке времени ожидания в ноль - кернел37 избыточна?

Как и писал раньше - вторник, все тихо, ошибок транзакций и нет вовсе.
Но все равно хотелось бы управлять этим процессом.

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

(393) парочке юзеров в понедельник сдвинуть график на час и все

(395) Четвертьмеры. Просто не пойму как очередь проведения организовать. где проверять блокировку слуэжебного элемента?
В начале обработки проведения пробуем блокировать и елси не блокируется ставим в очередь или же просто гоняем цикл с проврекой блокировки в начале процедуры ОбработкаПроведения? Если я вошел в ОбработкаПроведения не значит ли это что все равно уже я пытаюсь проводить документ и блокироваать журнал ?
1. Беру первый документ за день и провожу его
пока он проводится, пытается проводиться второй документ, и он же ставится в какую-то "стековую очередь", если проведение первого еще не завершилась? Когда этот второй будет проводиться? И какой обработкой?

(396) нахрена множить сущности без необходимости?

(394) Давал провести с каким-то флагом? А обмен ведь тоже ночью с магазинами так можно и не успеть весь регламент отработать

(397) Подступает конец года, там цже и чеки не по 200 штук в день а по 350 начнут бить и реализаций будет много очень и поступлений к новому году ну и соответственно перемещений - может и стоит их умножить наконец-то?

(399) Да и что особенного, просто некая очередь массового обслуживания причем далеко не по всем видам документов. В очерередь попадут реализации поступления перемещения чекиккм списания оприходования ну документы по движению разбухтовки.

(385) Просвети, пожалуйста - для ДБФ прямые запросы с виртуальными таблицами (РегистрОстатки) работают так же, как и СКЛ?

(401) да

(401) Да вроде похоже через 1sqlite или vfpoledb, только я так понял что если я использую kernel33 или 37 для решения проблемы 1 ГБ то рпямые запросы через 1С++ могут и не заработать

(402) Тогда ТС может перейти на прямые запросы в ДБФ и ускорить проведение в разы

(403) почему не заработают-то? ограничения на 1Г - это ограничения движка 1с, а не структуры хранения. а 1с++ использует драйвер фокса. Ну или 1склайт (в нем тоже ограничений нет)

(403) я тебе даже больше скажу - в режиме чтения ты можешь прямыми запросами к сколь угодно большой базе (в пределах ограниченй дбф и файловой системы, конечно) обращаться

(401) Очередь проведения дает управляемость и ликвидирует блокировки фактически. Ибо ждут пока предыдущий не закончит проведение.
Просто я никак не могу дотумкать как формировать очередь.
1. первый документ с утречка который проводится и блокирует служебный элемент
2. тут же второй с проверкой блокировки служебного элемента, пусть 20 циклов ожидания. Но ведь тут же и третий и т.д. Как эта очередь будет работать по времени? Пока гоняется 20 циклов - остальные не могут свои циклы проверять?

(404) я б сформулировал по-другому: "возможно перейти на прямые запросы". а может тс или нет - это совсем другая история...

(398) если не за сегодня проводили, то партии включались, а все что в течении текущего дня - нет. Но с проведением задним числом было строго. Ночью у тебя в монопольном режиме один день то за полчаса перепроведется. а в выхи перепроводилсось с ГП.

(408) Согдасен. Проблема не в переходе а втом что надо заново раскапывать что и зачем и как в модулях проведения и как все это увязывается. Время в-принципе есть конечно на это.

(407) Если документы начнут проводиться в 10 раз быстрее - никакой очереди не возникнет. 40 человек

(411) причем у него практически все юзвери кроме банка долбят руками.

(411) Да не в этом дело, опять же новые проводятся за сотни милисек. А вот задние те долго раз в 20-40 дольше даже в монопольном режиме. Просто подскажи мне по повдоу очереди а то в моей голове она не до конца прояснена. Если вошел в ОбработкаПроведения - это означает что уже блокировка журнала началась или пока я не начнуб движениерасход или движениеприходвыполнить или движениевыполнить - все пока свободно?

(412) Ну да, это же логично а как еще? хотя реализации однйо кнопкой на основе заявок, поступления через загрузку файлов от поставщика большие. Или есть какие-то вообще автоматически варианты?

(413) когда Обработка проведения (или удаления проведения) началась - ты уже в трранзакции

(413) На заднем проведении прямые запросы как раз максимальный выигрыш дают при расчете итогов.

(415) то есть если в этот момнет кто-то проводит уже сразу ошибка блокировки? То есть проверку блокировки служебного элемента надо делать вне этих процедур? Но тогда где? В каком месте проверять?

(416) Согласен. Давай попробуем. Окунусь в начало 2000-х опять )

(414) ну я ж говорю, у меня бегало с сотню торговых с планшетами, плюс прилетали заявки через EDI. Т.е. 95% заявок давали робот, принимающий с планшетов, и оператор, отслеживающий поступления от сетей.

(419) Ну это конечно другая ситуация.

(419) ну и 50-70 заявок делало вручную 4-5 человек из опта.

Звонят говорят что сегодня все спокойно да я сам вижу по журналу регистрации - нет ошибок транзакций сегодня кроме может милисекундных.

(401) нет. Там нет вирт.таблиц, все запросы руками. Можно конечно, через класс от вандслава писаиь, ноя им не пользовался, ибо у меня в конфе былм свои классы на перехватчике, ли и рукамииписаиь проще.

(403) неправильно понимаешь

Если не переписывать на прямой запрос, то делается период хранения 5 дней и привет. И любой твой докумкнт будет проводитсЯ в любом числе быстрее.

Как и получение любого отчета на чорном запросе

(425) лениво только каждые 5 дней период открывать. На сиквеле хоть можно автооткрытие сделать...

(427) ты не поверишь, но на дбф тоже можно не руками..

(428) пакетным?  честно говоря, не пробовал.

(428) Понимаешь есть у мення и учойс и унижурнал и сетаттр и реплвал которым я порой пользуюсь.
Но вот 5 дней в периоде - сильно напрягает почему-то

(430)+ Ну а на магазинах - то же 5 дней? Или там можно месяц оставлять?

(428) А как делать квартальное перепроведение, ведь это сколько же периодов у меня откроется - порядка 20?
Открыть период-то не проблема даже роботом как-то

(388)
«Я так понял что кернел33 обеспечивает только...»(с)
Верно поняли.
(390)
«То есть мне надо DBEng32 Ваше себе установить?»(с)
Не надо.
«Заменить НачатьТранзакицю Попытка Исключение КонецПопытки ?»(с)
У нас ВСЕ (!!!) операции модификации БД были охвачены «Попыткой».
«Ставить на проведение в очередь? Каким образом?»(с)
Для ответа на этот вопрос надо смотреть Вашу конфигурацию. Но... :-) Что точно надо делать - это убирать из модуля проведения документа ЛЮБЫЕ операции по модификации БД кроме работы с регистрами, «проводками» и самим  только ЭТИМ документом. Во всех других случаях может/будет возникать "Взаимная блокировка (deadlock)" с тупым/бесполезным ожиданием средствами самой 1С, любым «решением проблемы 100%», Вашими «ручными» циклами с паузами.
«При чем тут учойс сетатрс или униджорнал?»(с)
Я не знаю что это такое.
(391)
«А как мне понять теперь уже у меня кернел33 используется или кернел37?»(с)
Сравнить файл с файлами из ZIP-а где скачали.
«Получается что если время ожидания в ноль то мне достаточно кернел33 для решения проблемы 1 ГБ?»
Да.
(392)
«Получается что при установке времени ожидания в ноль - кернел37 избыточна?»(с)
Больше того. :-) Вредна.

(433) Спасибо за развернутый ответ. Но вотту непонтяно ибо было очень давно и zip уже не сохранилось сохранили сами kernel33.dll и kernel37.dll  а вот что я использую увы теперь не пойму. И какие файлы патчились. Подскажите как уже тперь разобратся раз момент подошел.

(432) какая-то каша у тебя в голове, разобраося что ле, что такое регистр, как он устроен, что такое итоги останкового и оборотного регистра. И что такое открытие периода. И как получается остаток на  произвольную дату.

И чем получение остатка за произвольную датутотличается от получения остатка на ТА..и что вообще такое ТА.

(436) Ну стодбко лет с этим работаю - расчет регистра, ТА, остатка на ТА и тд - вроде понятно что к чему. Просто из-за перепродаж и работы задним числом приходится делать перепроведение базы за квартал (если 5 днеЙ) значит в месяц 6 открытий периода примерно - а может я и правда не понимаю что-то?

(435) Остаток на произвольную дату - остаток на ближайшую (скажем начало месяца+приход за время от начала периода до произвольной даты-расход за время от начала периода до произвольной даты)

(434)
Выслал ZIP-ы на почту.

(439) Спасибо. Хоть сориентируюсь

(439) Пока не получил. [email protected]

(441)
Блокируют. :-)
Повторил отправку.
Пароль на ZIP - hogik

(442) Да, каспер. Отключил

Думаю yandex.ru блокирует.

ну да, не доходит, хотя если в архиве - должен пропустить по идее
tgu_82 скайп
Может через телеграм?

(444) Спасибо большое, дошло. Отпишусь

(437) при проведении документа никаких "открытий периода" нет.
А перепроводить что-то нужно в потоке, если что.

(447) Открытий периода нет, но переход на следующий период есть и порой долго переходит прежде чем проводить начинает уже в новом периоде, ну скажем за квартал - 4 раза, перед 1 месяцем, затем на второй, затем на третий ну и на четвертый на начало

(448) какой переход ? какой квартал ?

кто куда у тебя переходит ?

(450) Ну запустите групповое перепроведение документов и сначала будут итоги на начало пересчета причем даже если я считая с 25 числа, все равно он высчитывает итоги на 1 число а потом уже так идет до 25 числа.

В потоке - это в одном терминальном сеансе?

Каждый квартала я делаю групповое перепроведение документов один раз перед квартальной отчетностью (выгрузкой в бухгалтерию)

(453)+ Хотя же можно точку актуальности просто откатить и будет наверное намного шустрее перепроводиться. пробую прям сейчас

(454) конечно будет гораздо шустрее. у тебя не будет расчетов задним числом, все будет проводиться в ТА

другое дело если в базе трэш и угар - то будет затыкаться на проведении документов...

(456) Ну нет вроде треша никакого  - ведь перепроводится все более менее без проблем а те что есть - разруливаю сразу (типа заявка на склад по времени позже реализации на основе той заявки и т.д. Кстати в-основном приходится поправлять именно все эти запутки с резервами. И потом документы меня мало интересующие я вообще из перепроведения исключаю

(456) Если я откатываюсь на 1 июля то опять же долгго соображает с перенос остатков на 01.07.2020 - все это в копии конечно я делаю. В рабочей финальный обмен идет

(456) 33000 доков перепроводятся за 12 минут - это один месяц после того как ТА передвинул на начало этого месяца. В-принципе РКО ПКО и банк можно было бы не проводить но поскольку их вводят задним числом (банк) то после пересчета последовательность взаиморасчетов с контрагентами восстанавливается путем такого проведедния

(459)+ Опять перенос остатков на 01.08.2020 - долго а перепроводятся шустро

(460)+ Как резуюме - почти 100000 документов за период 01.07.2020 - 30.09.2020 перепровелись вместе с переносами остатков за 50 минут.
Комп мой рабочий с hdd с 8 гб оперативки однопроцессорный win7-64 установлено, рейдов никаких нет.
Это хороший результат или не особенно?

(461) я думаю хороший

(462) А задним чисслом тормозит

(463)+ При интерактивном проведении - почему не пойму

(463) потому что заднее число. при проведении в потоке ТА - итоги просто читаются. при заднем числе итоги читаются+вычисляются. причем чем дальше вычисление от начала месяца -тем больше объем вычислений. поэтому перевод на периодичность в 5 дней существенно ускорит проведение задним числом.

(465) Я понимаю что ускорит, да надо пробовать на копии.
Ну и потоковое проведение или ты говорил ещекакие-то варианты - меня заинтересовало

(465) И от ПриЗаписи надо отказываться. Просто процедура и в конце Записать(), вот в ней все бухтовки автоперемещения и т.д.

(450) Переделываю в копии на 5 дней. Долго изменяется период. Жду

(468) это у тебя сейчас ВСЯ БАЗА пересчитывается на итоги в 5 дней. это может быть небыстро

(469) Да, это я понимаю

(470) це успix!

(468) Прерывай процесс, удаляй все rg***.dbf и rg***.cdx и запущай заново. Будет быстро, если итоги норм закрываются

(472) тьфу, точно, так быстрее будет

Да, точно. Прорву сейчас. Ночь прошла. Еще идет. А может пусть идет, интересно когда он завершится

(465) Еще и "Регистры.Актуальность(1)", за что писателям типовой ТиС памятник прижизненный из навоза.

(475) Это да. Придумали на нашу голову.
Если RG удалить то они же сформируются потом на основании RA

(475) при нормальной реализации - почему бы и нет?
впрочем, архитектура 98 года, и ждать там нормальной реализации странно.

Удалил rg установил 5 дней и теперь пересчитываются итоги но медленновато что-то хотя комп обычненький

(478)+ Получается 360 точек итогов. интересно когда же они пересчитаются

(477) да по сравнению с текущими типовыми ТИС образец практически вылизанности

(480) я про архитектуру платформы.

Пока пересчиталось 50 с лишним периодов. Сентябрь 2016 заканчивается

(482)+ За три часа один год

(483)+ Нужны почти полные сутки а еще ведь по каждому магазину тоже надо переделывать на 5 дней. То есть вроде вариант а фактически не вариант все-таки

(483) год пересчитывается 10 минут или меньше, не помню уже, в комплексной, с задвоенными записями иирегистрами, а не какой-то там голый тис. И у нас размер вмех дбф примерно 21 гиг был. У тя просто или комп целерон, или регистры не закрыты/есть строковые измерения

дай хоть *.dd посмотреть от этой базы

(486) Куда прислать dd?

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

(487) на любую файлопомойку, ссылку сюда

(359) >есть только в ПриЗаписи чтоб в единой транзакции все было иможно было откатиться.
Дык, у него там вся разбухтовка считается в транзакциях! Я правильно понимаю?
плюс, в модулях проведения много лишних телодвижений понадобавлено.
плюс, работа задним числом.
Вот и тупит оно адски.

Хорошо, точно не сообразид )

пока 01.01.2018 05.01.2018 идет

(489) https://yadi.sk/d/mDf8WnpI1udbpQ
Ссылка с dd

(488) Ну сделай в конце концов для каждого магазина файл регистра остатков за последнюю декаду
Думаю )

(490) Гуру провел тесты и выясник что ПриЗаписи к транакциям отношение не имеет
И пришёл к выводу, что само МЕСТО (процедура ПриЗаписи) создания документа не порождает конфликтов и клинчей.

Я думаю что если документов в понедельник с утра до фига и часть из них задним числом и проводится 3-4 скунды а то и больше то вот отсюда блокировки и лезут. Все время пытаются жать кнопку ОК, их отшибает по ошибке Они говорят Да и их может опять отшибить по ошибке. Уступать друг другу не хотят уж точно. Хотя может дело в чем-то еще

(490) Нет транзакций явных при разбухтовке. Там просто ДокБухт.НОвый(), Записать(), Провести()
Но никаких транзакций в ПриЗаписи нет явных нет а где были я их повыкидывал.

(495) сделай как я сказал - при открытии дока - если док существующий и нет изменений - все кнопки ОК, Записать, Провети - сделать недоступными. в доступность переводить только если что-то в документе поменяли. вот как начнут в первый день после изменений звонить что кнопки не нажимаются - вот и понятно откуда транзакции.. ;-0

(497) если док существующий и нет изменений - все кнопки ОК, Записать, Провети
Ну это друг другу противоречит. Или  ты имеешь в виду что модифицированность=0 то есть
ничего с ним не делали а если делали то открывать кнопки к доступу

(498) да

(499) Согласен тут бы еще знать где попытка исключение конецпопытки выставить, заменить ими начатьтранзакцию зафиксироватьтранзакцию

НачатьТранзакцию();

Попытка
//всякое
Исключение
  Попытка ОтменитьТранзакцию();
  Исключение
  КонецПопытки;
  Возврат;
КонецПопытки;

ЗавершитьТранзакцию();

я типа так делаю.
проблем не наблюдал вроде.

(500) если у тебя разбухтовка - это генерация нескольких подчиненых документов ДокБухт - то без транзакции у тебя получиттся что зафиксирован аи проведена будет только половина например. правильно это допустимо или нет - сммотри сам.

(502)
Словарь:
разбухтовка - тайный процесс. см. забухтовка.
забухтовка - см. бухтовать.
бухтовать - см. разбухтовка.

зы. навеяно Сепульками С.Лема

(503) Ну и ладно). Добавлю в копилку - у меня есть процедура "Пришить бухту"

(501)    
Попытка
        
        НачатьТранзакцию();
        
        Если БП_ЕстьЗаявка = 1 Тогда
            ДокЗаявка = СоздатьОбъект("Документ.ЗаявкаПокупателя");
            ДокЗаявка.Новый();    
            ДокЗаявка.АвтоВремяТекущее();
            // идентичные реквизиты шапки
                           ..............
            Если ДокЗаявка.БанковскийСчет.Выбран()= 0 Тогда
                Сообщить("У выбранной фирмы не указан расчетный счет по умолчанию!
                |Оформление быстрой продажи невозможно!");
                ОтменитьТранзакцию();
                Возврат;
            КонецЕсли;
                         .........
            ДокЗаявка.ЗагрузитьТабличнуюЧасть(ТаблицаДокумента);
            
            ДокЗаявка.Записать();
            ДокЗаявка.Провести(1);
            Если ДокЗаявка.Проведен() = 0 Тогда
                ОтменитьТранзакцию();
                Возврат;
            КонецЕсли;
        КонецЕсли;
                .................
            Если ДокПКО.Проведен() = 0 Тогда
                ОтменитьТранзакцию();
                Возврат;
            КонецЕсли;
        КонецЕсли;
        
        // фиксируем все изменения
        ЗафиксироватьТранзакцию();
        
    Исключение
        
        // при возникновении ошибки отменяем все изменения
        // здесь можно выдать сообщение об ошибке
        ОтменитьТранзакцию();
        Сообщить(ОписаниеОшибки(),"!");
        Возврат;
        
    КонецПопытки;
                      
       Это в БыстройПродаже так
Сначала Попытка и только потом НачатьТранзакцию
А у тебя наоборот

(505) ээээ. а _до_ начала транзакции Если ДокЗаявка.БанковскийСчет.Выбран()= 0  -проверить низззя? совсем никак-никак-никак?

(506) Можно и еще тысяч 30000 строк одного только глобального модуля тоже )

(507) выдыхай, бобёр! ©
я ж тебе выше писал, что в транзакции должно быть минимальное число телодвижений. в идеале - только "записать - провести - откатиться". а создавать объект и заполнять - _до_ и снаружи транзакции.

Док.Провести() Возвращает: 1 - если проведение документа выполнено, 0 - иначе.
Док.Проеден()=0 - излишне.
причем если такую проверку делать например для ранее проведенного документ ан аперепроведении - то получишь трабл, так как документ не провелся, но при этом проведен

Сообщить("У выбранной фирмы не указан расчетный счет по...
.
стопудово можно не Докзаявка.банковский счет проверять, а еще до транзакции нужнаяФирма.основнойСчет

Значит так. Пересчет на 5-дневные иотги слетел в 2018 году с невосстановимой ошибкой базы данных

(510) Да я согласен со всеми, но это все лопатить заново. Ну может и придется

(511)+  наверное придется сделать тестирование и исправление на копии. что-то мне не нравится такая ошибка невосстановимая

(513)+ Дошло до 26 мая 2018 и срубилось на фиг

Мне бы сделать свертку и дальше тихо переползать на скуль а может и еще куда

(513) Процентов 90 что с 5-ти дневными файлик итогов до критической массы вырос.

(516) Наверняка так и есть.
Сделал ТИИ, ничего криминального. Мелочевка есть типа одного дубля уид в справочнике цен ну и еще немного по мелочам

(517) Значит вариант на 5 дней пока не прокатывает. Буду чистить модули проведения возможно перейду на прямые запросы для заднечисловых проведений

(518)+ Как небольшое резюме - база более-менее в порядке. Транзакции возникают из-за долгого проведения в других сеансах о чем свидетельствует блокировка исключительно 1sjournal. Кто первый начал - найти вряд ли возможно но обработать через попытку с озвратом по исключению как бы опять наверх вполне возможно тогда ошибка транзакции пользователи видеть может ине будут зато ко мне будет приходить информация нетранзакционным способом о том что у конкретного пользователя возникла проблема и он не может довести действие до конца.

(all) Гуру - подскажите: для ДБФ по прямым запросам какие отличия?
Уже написали, что виртуальные таблицы не работают. А что взамен?

(520) руками (ибо без оптимизации это не сложно). или класс "ПрямойЗапрос", там сделано. Рекомендую последнее.

(518) ну попробуй "10 дней". Есть же вроде?

(522) есть, да. Пробую

(523) сколько у тебя периодов получилось вообще, и влезло в RG?

+(524) посчитай просто для начала.
ну и прикинь динамику записей в РГ по периодам.
если регистр закрывается, но с опозданием (ну типично - отгружаем сегодня, платят через неделю), то у тебя будет более-менее стабильное количество на период. Если не закрывается - будет расти

(525) Не закрывается регистр книга покупок и продаж но они невелики.
5 лет примерно *12 = 60*3 если по 10 дней - будет примерно 180 периодов

(526) ту так упало - из-за ндсных книг? удали файлы движений к хренам, делов то

(527) Запусстил с 10 днями, проверю как получится

(527) Я удалил RG все и теперь он иотги по 10-дневкам пересчитывает. А если удалю регистры движений - мне всю базу заново проводить? или вы имеете в виду что потом я их вставлю обратно? Но не будет движений - с чего по 10-дневкам итоги будет формировать?

(527) Ксати после упаковки таблиц - индексный файл регистра движения движения партий уменьшился в два раза почти а вот сам регистр движения партий не уменьшился ни на копейку

(529) если у тебя упало и-за незакрытых регистров книги продаж и покупок - то удалить движения по ним.

(531) Смотрю теперь размеры регистров - мониторю

(532)+ Интересно регистр ra328.dbf в 10 раз больше чем ra328.cdx, а
регистр rg328.dbf в 10 раз больше чем rg328.cdx

(533)+ Сорри, в два раза

Сегодня за исключением мелочи ошибок транзакций не было

таблицы итогов и движений по книгам покупок и книгам продаж 4+4=8 файлов можно тупо грохнуть. все будет работать без проблем.

..если конечно вы книги продаж/покупок не используете.
.
там в последних печформах счф есть что-то СформироватьПоКнигеПродаж типа - может оно там надо.. хз...
у меня и без них все работает.
.
сегодня чуть кондратия не увидел. 77 перестала запускаться. не найден ключ защиты.

Народ - поделитесь прямым запросом и 1sdqlite с документацией. Что-то форум на 1cpp.ru в безобразном состоянии

(538)
Прямой запрос с докой:
http://www.1cpp.ru/forum/YaBB.pl?action=downloadfile;file=Query%5FExtTF%5Fother%5F001%2Ezip
1Sqlite, сборки от Djelf:
https://cloud.mail.ru/public/9znr/ZJ6ULE9aR/

(539) Спасибо

При пересчете на 10 дней - слетело,, вскочил за 2 ГБ регистр заявок. Ну с этим-то я разберуусь. Я его точно давно не закрывал. Как-то и не парился

(541)+ Именно по неподтвержденным заявкам в-основном незакрыто.
Теперь закрою. Только этот регистр распух остальные терпимо

(537) Мы наверное с тобой два могиканина - работаем с ключом и может оказаться что не найден ключ защиты )

(543) Ага... А при этом ключи в сейфе лежат ))

(544) А вот и нет - ключ вставлен и работает )

(541) вот так вот потихоньку заодно проблемы вычистишь, техдолг накопившийся...

(546) Может и скуля и прямых запросов не понадобится...

(547) Скуль хоть как нужен - иначе сворачивать и сворачивать из-за регистра партий

(547) "прямой запрос" и вообще вандаловский класс чем цеен - многие вещи "как в снеговике".
т.е. быстро и удобно как в клюшках, а "рюшечки" как в восьмерке
Привыкаешь нормально использовать нормальные запросы (я проработав с клюшками лет 16 - черные запросы не знаю вообще).

(548) регистр партий можно и "архивировать"
сделать копию (при желании - и не одну), и перекидывать туда "очередные 2 гига"

(549) На 8.1 мне нравилось, такие замысловатые запросы строил а потом как отрезало: все на фиг позабыл, но хотя консоль есть же, ей когда-то и пользовался для отладки

(550) Конечно я делаю копии. Вы имеете в виду убить регистр движений на фиг но оставить регистр итогов?

(552)+ Злобчинский давал мне для этого прямой запрос

+(550) у меня подобный прикол использовался:
пересчитанный ночью регистр себестоимости копировался в "копию регистра". и все работы по анализу продаж не зависели от того, лазили сегодня в заднее число, или нет - они работали с "копией".

(552) я имею ввиду сделать регистры "партии до 2016", "партии до 2018", "партии до 2020", и перекидывать соотв. обороты туда.

(552) чтобы "убить регистр движений" (на самом деле таблицу, файл) прямой запрос не нужен. достаточно кнопки del

(555) Несколько таких доп.регистров? А обмены как? А маржу как считать будут? Хотя последние же движения года за три останутся )
(556) Мне надо убить не все. А овт эти "Партии до 2016,2017 и т.д.) Вы именно как регистры делали? Или как справочники например?

Лень матушка и такое "легкое" отношение к заявкам. RG 100 МБ а RG 900 МБ. Вот отсюда видимо вся радость и прет

(557) Что обмены? Обмены как обмены. что в обменах необменного? как настроишь, так и будет.
маржу можно хоть за все время считать,
имхо просто в черные запросы тупо регистры по перечню добавить.
в нормальные запросы чуть больше работы.
я регистры не делил - я делал копию для чисто утилитарной цели: чтоб сегодняшнее ковыряние кем-нибудь в заднице не сносило себестоимость у всех остальных.
я просто предлагаю _вам_ - поделить, если уж и на сиквел не пререходить, и резать лень...

(559) Резать не лень. Но надеюсь для жизнеспокойстия в конце ноября базу сверну как обычно и вот тут уже буду дальше экспериментировать.
А кстати вот сейчас у меня же многие итоги в ргеистре заявок обнулятся. Нет у вас скрипта чтоб их убить - которые нулевые имеенов регистре итогов?

(560) с дбфами прямым мне работал.
но вообще говно вопрос - написать прямо на 1с обработку файла. десяток строчек, и похрен, что будет пару часов шуршать...

(561) Просто все поубирал вроде но регистр иотгов по Заявкам не уменьшился ни на грамм. Хотя это наверное правильно. Так и должно быть просто они дальше не полезут

(562) дык сжать надо
хотя вроде открытие месяца тем и отличается, что нулевые остатки не переносит

(563) Это так. Только я ж сделла в ноябре и теперь до 1 декабря надо ждать

(493) Посмотрел. Кучка непонятных самодельных регистров, в которых измерения числовые (занафига ?)

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

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

(566) Числовые измерения - это метраж для разбухтовки.
Он вроде никому не мешает. А больше не помню чтобы числовые измерения были

(567) Как раз не закрывались регистр заявок сейчас закрыл и регистр книга покупок и продаж но они вообще-то маленькие хотя я их просто удалю и заново пустые создадутся. Остальные закрываются. А так спасибо за анализ.
Сегодня как все дни кроме понедельника ошибок транзакций кроме очень мелких - нету. Только получается в понедельник дурдом

(520) взамен чего? Виртуальных таблиц ?..ну если 1sqlite пользовать, то cte можно) + уложитьТЗ суперметод.
Если нужна макс скорость, то vfpoledb использовать и писать запрос с учетом попадания в индекс.

(568) СерийныеНомера, ИсторияЧеков,ДвижениеБухт

(571) Историч чеков - это по номерам дисконтных карт, давно все не так но когда-то в 2000-х это было так.
Серийные номера вообще неиспользуется уже лет 20 )
Что касается движения бухт - я выше уточнил - метраж - число и ничего тут страшного нет тем более от него отрезы - и опять метраж числовой

(511) ну дык в момент слёта, отсортируй по убыванию размеров все файлы, там сразу видно, на каком регистре затык. и где RG много больше RA

(570) попадание в индекс это ужасное )). Это чтобы в условии where были все поля из индексного файла к аблице из 1С.ДД?

(572) Ага.. и прям приход с метражом 10 и расход с метражом 9 ? Или как ? :))

(575) Именно так.
товар кабель:
5 бухт по 100 м
3 бухты по 50 м
Поэтому метраж и выбран как измерение

(576) я не об этом.
У тя точно приход 50м и расход 50м всегда ?

И это, выкладывай уже базу целиком (*.dbf+md+dd) куда нить на файлопомойку на поглядеть

а то чую, еще до 2030 года не разберешься

(577) ну вообще-то да. "хвосты"- то тоже куда-то деваются, хоть на утилизацию
но "числовые измерения" это оригинально, конечно

(577) Конечно нет, у меня же и розница и опт. Тот же кабель-канал приходит по 2м всегда
Все по разному.

Бывает что по 1м покупают и резать приходится скажем от 50

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

(581) :))))))))))))))))))))))))

зачет ага, т.е у тебя всегда приход с одним набором измерений (Метраж твой), а расход с другим ?

Или ты не понимаешь, как это работает ?

(584) Это мое произведение искусства от начала до конца еще с 2003 года

Кто писал эту разбухтовку ?
там 3 дока за это отвечают, на сколько видно

(586) Я писал и уж это работает как часики много лет. И регистр бухт закрывается.

(587) каким образом ? Если ты утверждаешь обратное ?

(586) 4 документа или даже 5 но используются
Дивжение бухт
Движение бухт по чеку (каждый день ууничтожаются с чеками при закрытии смены)
Разбиение бухт
Кореектировка бухт (можно ей и разбить и сшить)

(587) Да простым вроде.
есть на остатке 10 по 100
есть на остатке 5 по 50

продаю или перемещаю
2 по 100 остается 8 по 100
1 по 35 м (значит 50 в расход например а 15 в приход).

То есть когда ты продал 3м из 100метровой бухты ты списал одны стометровую и оприходовал одну 97метровую?

(590)+ Имеется в виду метраж 15 - 1 бухта
метраж 100 - 2 бухты в расход и т.д.

Ресурсом у меня является не метры а количество бухт
А метражи - да измерение

Теперь понятно?

(591) Именно ток. Поэтому в документе разбутовки у меня есть реквизит тч - родительская бухта