ТИС Файловая. Терминальный режим. Работают около 50 пользователей. Иногда бывают зависания при транзакциях. Особенно в центральной базе при обменах с магазинами такое наблюдается. Редко но бывают.
происходит это так: какой-то пользователь (по журналу регистрации видно)лупит документы остальные ничего делать не могут. Тот кто лупит - делает бесполезную работу, потому что документы налезают друг на друга. После того как он закрывает 1С (по моему требованию) все нормализуется у остальных.
Но руководство требует чтобы их не было вообще. Буквально с ножом к горлу уже !!!
Как у форумчан - тех кто работает в 1С 7.7 обстоят с этим дела??? Может я один такой неграмотный ???

Чё ты орёшь?

(0) Если перейдем на скульную - проблема решится??? Зарплату и бухгалтерию собираюсь перевести на 8-ку. Но управленческую систему - сильно измененную ТИС - пока что не могу!

(1) Почему ору?

(1) ничего смертельного - все у меня работает слава Богу

Файловая и 50 пользователей?
Размер базы то какой?

(5) Я свернул недавно, так что регистр партий теперь 1,2 ГБ всего

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

(0) что вкладывается в понятие "лупит документы" ?

перейдешь на скульную - вылезут другие сюрпризы
и не мейчтай = что будет работать быстрее

попробуй на отдельной базе ..
сделай из нее скульную
и устрой краш-тест .. запусти чел 5-10 чтобы одновременно минут на 15 делали свои типовые отчеты ..
потом слушай что скажут

ну и если че, режим ожидания всем в 0 поставить принудительно

это, для начала

(8) Ну тот единственный кто захватил как-бы базу вполне себе проводит документы, но в журнале регистрации видно что он делает счет-фактуру а она налезает на платежное поручение к примеру

(10) Насчет режима проверю но когда-то транзакций была тьма и ставил его в ноль. Давно это было, года 3-4 назад. Кернел 33 и 37 использую потому что лицензионка у меня

Просто еще хотел поинтересоваться как с этим у тех кто работает в аналогичном режиме

(12) в 7.7. вроде блокировка идет на все документы при проведении любого, так как таблица одна

А еще хотел спросить - если УТ поставить все-таки или КА например (мы купили апгрейдом), то транзакций не будет?

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

(15) В Журнале регистрации выглядит так:
Например:
объект - перемещение
представление объекта - чек ккм.

Тот кто делает перемещение - потом переделывать должен.

ТИИ изредка делаю но как-то не замечал существенных ошибок.

(10) ЕПРСТ Кстати время ожидания захвата у меня 15 сек,
Период опроса 10 сек. Не ноль. А в ноль какой из двух параметров ставить? И какое значение должно быть у другого параметра ?

(20) еще раз, время ожидания всем 0.

это самый быстрый штатный способ работы с дбф

можно принудительно, либо через вк, либо штатно, проверяя перед началом работы параметры файла cап e gjkmpjdfntkz

(21) ЕПРСТ А период опроса изменений какой? Это надо под каждым юзером ставить?

ну и при ошибках как в (18) - это просто битые индексы 1sjourn

(24) период опроса 10

да, каждому юзверю.

(25) То есть в ТИИ пересоздать индексы предварительно убив их?

Тогда, при наличии блокировки, юзверь будет мгновенно отваливаться с сообщением, что журнал заблокирован, а не ждать годами появления этого сообщения

(28) ТиИ нужно вообще забыть как страшный сон.
Просто удали все *.Cdx и зайди монопольно

(29) можно принудительно, либо через вк, либо штатно, проверяя перед началом работы параметры файла cап e gjkmpjdfntkz

НЕ ПОНЯЛ концовку

От  транзакций никуда не уйдёшь. Единственный способ - сделать робота, который карусельно будет проводить документы пользователей. При этом пользователи свои документы будут писать не в документы, а в справочники с набором полей , как в документах. Робот берёт документ из Справочника пользователя и  делает документ в понимании 1С. С общим журналом работает ОДИН  пользователь - робот.   Суть - избавление от тупой конкуренции за главный журнал. Или принудительно кешируй самые часто используемые таблицы и индексы в оперативной памяти. В скуле это можно сделать по человечески. Это так, в качестве теории...

(30) Хорошо. Так и сделаю. Когда-то в ноль ставил всем но видимо после сверток она в стандартный вариант устанавливалась (10 и 15)

(33)+ Хотя вряд ли после них. Поменяю в ноль прям завтра!

дбф 100 пользователей. периодически тоже такое бывает.
Давно пробовали на скуль, но так как скуль работает медленее, то тупо не успевали выполнять тот же объем работы. Плюс тормоза в подборе при динамически вычисляемых колонках. Откатились на дбф

(35) А параметры опроса и захвата какие устанавливаете?

(36) вооще не замарачивались

(35) Как писали ЭсКуЭльщики, сперва трассер, потом самые часто используемые таблицы вместе с индексами в оперативную память.
Ну, и до кучи, разносить оперативное и полное проведения по времени - в рабочее время только оперативное, полное - вечер-ночь. Если позволяют бизнес-процессы.

(37) А как часто бывают блокировки транзакций?

(31) параметры файла cfg у пользователя

(40) пользователи у меня каждый в своей папке? А чем проверить, какой ВК и установить как нужно чем можно в автомате?

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

(38) вот и мы сидим на мешке с деньгами и думаем куда потрать. Толи уйти на скуль оставив от 1с только формы, а все остальное прямые запросы и хранимые процедуры. Или уйти на УТ10 и там "сперва трассер, потом самые часто используемые таблицы вместе с индексами в оперативную память. "
Пока что склоняемся ко второму варианту, так как перспектив интеграции с различными продуктами у второго варианта больше

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

(39) ну пока что раз в неделю (в понедельник) в пиковый часы. В остальные часы 1с-ка успевает пережевывать

Как здорово, что в восьмерке нет вот этого всего.

(0) Нет, не ты один такой. У нас около 70 баз в УРБД. Регламент - обмен ручками до 10:00, и с 17:00. но отдельные зверьки нарушают, да и жизнь диктует. И в рабочее время появляются дедлоки.

(44) Спасибо большое. А ведь была у меня такая процедура или типа такой когда-то

(45) Какого же объема у тебя база?

(25) Ёпрст - а пересоздание индексов исключит вот такие записи в журнале регистрации?

(42) в ДБФ - это к системным администраторам, пусть правят на сервере условия . В SQL дописываются скрипты. После каждой реструктуризации. Это к ЭскуЭльщикам.

(49) небольшая. почти 3 гига чистые dbf. Правда там данные за последние 5 месяцев с 1.07.17

(50) существующие - нет.
ЖР нужно вообще отключить в пофигураторе за ненадобностью

(49)
Померяемся? SELECT Count(*) FROM _1SJOURN 460 000 документов...

(52) У меня с 2014 года А была с 2012 - свернул

Был опыт: сделал базу, работала на одном регистре остатков с одним измерением. 5(пять) лет - проведение увеличилось с 3 сек  до 5... Это к вопросу о скорости работы в зависимости от количества регистров и измерений. Акты сверок делали сбором данных с непроведённых документов регистрации денег.

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

(53) Так а если отключить ЖР как я потом увижу что и кто в базе делал? Ведь бывают и злонамеренные дела иногда - по ЖР отлавливаю любые изменения в проведенных документах

(56) не отпадёт.
(57) злонамеренные дела по ЖР не отловить от слова совсем.

(0) Нужно смотреть.  В 7.7. узкое место 1SJOURN. Если есть возможность загрузку больших объемов "перенести" на ночь - значит нужно перенести.

(58) Отлавливаю, написал перехват любых изменений и пишу протокол в ЖР, потом можно посмотреть найти кто и что.

(0) -> дело, замени на что угодно, только уйди от этого добра.

(59) Перенести загрузку данных при обмене УРБД?

(61) ЖР сильно тормозит работу?

а так,
1.проверить, закрываются ли все регистры
2. выкинуть лишние не используемые регистры из базы
3.выкинуть лишнюю не используемую аналитику в регистрах
4.выставить период хранения останков 5 дней
5.даже штатно, этого достаточно, чтобы всё полетело

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

(64( Да скорость очень неплохая, на это никто не жалуется. А вот с транзакциями напряг бывает.
Сделаю все что посоветовали по максимуму

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

(63) да. поставь Рамдиск в Оперативной Памяти, переключи туда лог. Сможешь вообще отключить - будет молодец.

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

(65) Да, это неплохо бы сделать. Но проведение тоже не тормозит (нет жалоб).
(69) Здорово. Я за полтора-два часа три месяца перепровожу.

А если пытаться переходить на 8-ку? На УТ 10 или УТ 11 и конечно скульный вариант при таком числе пользователей ?

(68) и каталоги пользователей туда же.

Существенное ускорение даст работа с одним регистром с одним измерением, в 7.7 .

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

(71) Не вздумай, отрок!

(75) Отроку 58 лет :)

(71) УТ 10 пойдёт, её можно подрихтовать. УТ11 - почитай про её внедрения.

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

(0) Желательно УРБД вытащить в консоль, напрямик на сервер, в робота. без сети, без удалённого доступа.

(68) Рам диск ничего не даст. При наличии ССД дисковая подсистема перестает быть узким местом

(74) По возможности незакрытые регистры закрыть.

(80) Это смотря как настроить систему.

SQL даёт хорошие возможности кеширования, есть смысл перейти, в той же 7.7 .

(0) Когда то давным давно были проблемы в транзакциях в скулевой базе на 7.7

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

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

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

ТАк на УТ категорически не советуете переходить? Так и ездить в "копейке" когда БМВ7 можно пользовать?

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

(88) В точку! Есть такой юзверь - ставит обработки проведения/создания документов на 2х компах параллельно, зажимеют enter скрепкой и уходит покурить на xy сколько времени...

(87) кто не советует?

(90) Посмотрите 75 пост

(71) 8-ка на 50 пользователях файловая в терминале живет, но очень грусно. Сразу расчитывай на клиент-сервер. Клиенты могут быть и в терминале, если это УТ10. Если УТ11 то терминал противопоказан и клиент-сервер от 5 пользователей.

(0) У меня такой глюк был в файловой 7.7. При создании нового документа, пользователь "попадал" как будто в чужой созданный документ (причем тип документа мог быть другой). Причем для него это было не заметно. Только по журналу регистраций это видели. Объект один документ, представление другое. И вот в этот момент, он захватывал всю базу и начинал работать, все остальные курили бамбук от транзакции, пока этот пользователь не перезайдет в 1с.
Данный глюк был не часто, но работало около 180 человек, в терминале. Объем базы большой 16 гиг вроде. Самый большой файл движение партий подбирался к 1.9 гигов.

Если постучишся в почту, то скину тебе обработку (на 1сpp) которая ловила данный глюк (сравнивала объект и представление объекта по журналу регистрации) может у тебя такая же причина.

(92) где-то такой глюк всплывал уже в обсуждениях... точно

(87) Я бы посмотрел в сторону УТ10 в режиме "клиент-сервер".

(92) Так а причину этого нашли? Или боролись только со следствием (гоняли пользователей?)

(95) Да, тоже хотелось бы знать причины

(87) Хоть на что переходить, но на производительность всегда влияет количество записываемых данных. Принцип этот был, есть и будет. Даже если винчестер начнёт работать со скоростью асинхронного процессора. Практически это означает, что один регистр с одним измерением - всегда будет значительно быстрее всех остальных. И ЦИФРОВЫЕ периодические реквизиты лучше писать не стандартным методом, а в такой же регистр остатков с одним измерением, только интерпретировать остаток как значение на дату. Уйти от механизма временных реквизитов.

На практике, УТ10 поддаётся рихтованию за разумные затраты, УТ11 - уже для больших или очень больших контор, которые в состоянии переписать до половины кода, плюс до кучи серверное хозяйство должно быть на высоком уровне. Ибо УТ11 писалась в сотрудничестве с большими конторами, которые могли позволить себе Многое.

как то так

http://compress.ru/article.aspx?id=15851

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

+ к 100 вот в (84) пользуются этим решением.

ТиС - не знаю. Может и виснет на этих самых транзакциях.
У нас Торговля, полностью трансформированная под производство.
Файловая, ТермДоступ из 4-х городов
Хотели в SQL перевести, сравнил производительность с рабочей-файловой и тестовой SQL, в скульной время выполнения оказалось в 7 раз больше.
Директор сказал: всё, завязываем с SQL.
Так и завязали.

+102 и не виснет

http://www.superspeed.com/desktop/supercache.php

Для меня преимущества SQL перекрывают ее недостатки.
Все не совсем мелкие базы на SQL 2008, никто не жалуется на производительность.

В SQL есть особенность: запрос, в общем случае, выполняется в 10-100 раз быстрее, чем формируется-оформляется. Поэтому при переходе на скуль надо будет переписать получение данных одним запросом на модуль, или на кнопку-задачу.

(105) + можно на достойном уровне настроить безопасность.

(92) Alexor - я Вам отправил письмо с просьбой прислать обработку на 1С++

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

(109) Без (106) ваши потуги не дадут полного результата.

(109) Вам нужен программист SQL, а один раз настроить скуль - не большая проблема

(0) Откройте почту, пожалуйста. Как вам помочь?

(112) Спасибо. Насстроить SQL на раз - есть у меня опытнейший человек. А почту здесь можно указать?

в карточке у себя проставьте, этого достаточно.

(114) Открыл в карточке уже

Установил в 0 время ожидания. Вылезла проблема с константами - модовским IDD. Кто то явно её закусывает и держит. Придется срочно обморочно выкосить в части документов заполнения IDD (заявка, доставка, фактура - а это 2/3 от всех доков). Если не поможет, придется логировать её использование и тогда с паяльником идти выяснять у пользователя чем он это таким занимается.

(116) посмотри на время-интервал открытия формы, есть там опция, сколько секунд по умолчанию держать открытой.

(64) период ночью планировщиком открываешь?

(97) "И ЦИФРОВЫЕ периодические реквизиты лучше писать не стандартным методом, а в такой же регистр остатков с одним измерением, только интерпретировать остаток как значение на дату."
- это пипец как регистр распухнет практически мгновенно при значительном объеме периодики... и как это повлияет на открытие периода - даже думать не хочется...
.
или я что-то неправильно понимаю?

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

(95) Причину не нашли. Подозреваю на большом объеме пользователей, подозреваю из-за нарушения индексов. Которое проявляется из-за количество пользователей и объема базы.

(117) Это где?

(119) Почему? Регистр остатков не пухнет, а ведь там не менее 10 тысяч различных разрезов (склад, номенклатура, фирма)
А тут 1 разрез - имя реквизита и движение для изменения
Возъмем вырожденный случай - валюта и курс.
У тебя 3 валюты и тебе нужно хранить курс. Соответсвенно каждый день ты делаешь движение по этим 3-м валютам где фиксируешь изменения курса (+20 копеек, - 1 рубль). За год таких документов будет порядка 250.
Т.е. будет регистр в котором 3 измерения, 250 движений и остаток на любую дату покажет курс.
Чему там пухнуть?

*3 измерения = 3 записи

Кто то может мне объяснить как народ умудряется блокировать 1 константу в 7-кеу в дбф?

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

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

(126) Количество записей в таблице остатков есть величина конечна и равна количеству периодических реквизитов

"Пухнут" - это увеличение количество записей, а тут для этого нет основания.

Сколько у тебя периодических реквизитов в конфе 100-200? Даже пусть 1000. Т.е. в таблице итогов будет максимум 1000 записей на каждый период хранения остатков.


Как ты сейчас получаешь остаток товара на дату?

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

(127) именно что тысяча записей на каждый период. За год будет не тысяча записей а 12 тысяч

(129) еще раз. сравни с остатками номенклатуры.
Представь себе что у тебя 1000 фиксированных позиций, 1 склад и 1 фирма (ну скажем прайс 1С с коробками), ассортимент у тебя не меняется, учет по срелдней. В день по некоторым из них может быть 1 документ прихода или расхода, не более того. При этом у тебя на складе всегда есть этот ассортимент (т.е. в 0 он не уходит)

Сильно распухнет регистр остатков ТМЦ в такой базе?

(129) и что такое 12 тысяч за год? У меня в месяц на остатки с учетом складов и фирм тысяч 60 записей наверное будет. А тут за год всего 12 тысяч записи. У тебя база лежит на дискетки, что для тебя каждый байт важен

Может и так

(131) если из этого исходить то на восьмёрке ваще тормозов быть не должно ;-)

(123) Для курса Валют
надо
Валюта не в измерении хранить а в реквизите
т.е Регистр будет :
Реквизит  Валюта
Ресурс Курс


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

(134) Не понял остаток чего тогда нам покажет курс?

Ты с прайсом не путаешь, когда цену хранят в реквизите, а номенклатуру в измерении?

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

В 1999 году была так была решена задача по изменению цен на бензоколонках
Регистр
Реквизит  Безоколонка
Реквизит  ВидТоплива
Ресурс Цена

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

Я только о том что бы незакрытый регистр он и есть незакрытый

задача из 0 элементарная и решается совсем по другому.

(136) опять не согласен. У тебя ресурс цена, а значит любое движение вызовет расчет и запись в таблицу остатки. И если каждый раз писать цену, то получается что остаток будет расти до бесконечности, и опять имеем незакрытый регистр. Поэтому
Бензокалонка и ВидТопливо - измерения, Цена - реквизит. И тогда запись в этот регистр не будет влиять на остатки от слово совсем, ну и поиск перебором
        Прайс.УстановитьФильтр(Безоколонка,ВидТоплива);
Прайс.ОбратныйПорядок(1);
Прайс.ВыбратьДвижения(,ДатаПрайса);
Если Прайс.ПолучитьДвижение()=1 Тогда    
     Результат=Прайс.Цена;
Иначе
     Результат=0;
КонецЕсли;

(137) Да мы не занесение курса  а про вытаскивания курса - эта операция гораздо чаще чем внесение,
да и тот запрос что ты написал на 1с на sql гораздо лучше и эффективней будет.

(136) Интересный подход, спасибо за подсказку. А поподробнее можно?

(140) Мщи сайт дикого зайца он по моему в кеше был
также наверняка кто то еще ту статью выкладывал
по моему статья называлась
@Регист свединий на  1cv77"
автор я  Z1

по подходу можешь тут спрашивать

(136) Задача из (0) элементарная ? И как же она элементарно решается? вот несколько дней вообще тишь и благодать по транзакциям

(141) Не работать в ЦБ
ЦБ только для обменов.

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

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

(143) Да и если в УРБД смесь  sql баз и dbf баз
то бывают очень сложнообнаруживаемые ошибки
на строках неограниченной длины ( из-за разной организации хранения их )

(145) Пока все ДБФ. Спасибо за советы. Буду думать

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

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

(148)  Лет пять назад полностью переделывал выгрузку РИБ на 7.7 на sql, Разработки давно потеряны, но загрузка/выгрузка занимала секунд 300 максимум. Все в итоге было переписано на 1cpp.    

(137) У меня были хранимые процедуры на T-SQL для переодических реквизитов, работали в сотни раз лучше стандартного кода. Но поддержка их связана с заметным геморроем.



В переводе на прямые запросы есть один геморрой - надо все прямые запросы выполнять ДО первой записи в регистры, иначе словишь лок от 1С и все. В итоге пришлось переписать полбазы и все данные для расчетов для проведения  выполнять при начале проведения. Прям как сейчас в конфах для 8.3.

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

ЕПРСТ. На магазинх стало лучше намного а в центральной базе начался дурдом. Постоянные транзакции. Может с нуля вернутьь опять на 15??? 45 пользователей работают. Конец года, документов вал идет, включая кассовые чеки.

Или есть еще какие-то варианты ?

(151) ну, можешь поставить хрень от ромикса,vk_sleep

но я её убрал, ибо были ошибки при её использовании

А чего у тебя народ в ЦБ делает..? Справочники заводит, или что ?

(152) Если попроббовать вернуть как было или например поставить не 15 а 10 секунд или 5 - подскажите код. На ноль то я всех выставил

(154) Справочники, документы: поступление, чеки, строки выписки ПКО РКО перемещения реализации и счета-фактуры. В базе сейчас 45 пользователей

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

Вот код который все в ноль поставил

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

Ромиксову не использовал а вот кернел 33 и 37 использую

(159)+ Утром дурдом из-за транзакций а потом как-то нормально пашет

(154) ЕПРСТ. У нас очень много документов проводтся задним числом - и перемщения и постпуления и реализации. Получается что регистры же перерасчитываются. Вот может из-за этого все и происходит

(161) если регистры норм закрываются, выстави период хранения останков 5 дней.
Всё полетит

единственное неудобство - открытие периода.

(163) Ну а если все-таки вернуть время ожидания захвата не в ноль? Просто с кодом не врублючь как там сделать 10 или 15 секунд. Но именно с этого момента (как в ноль поставил) стало хуже на центральной базе

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

(164) воткни проверку, что если это центр база, то cfg не трогать и код из (158) не выполнять. делов-то

но от транзакций ты не избавишься, будет только хуже :)

(166) Так он же уже в ноль всем поставил. Что толку-то если я проверку поставлю. Он же мне в 10 или 15 секунд сам не поставит

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

(168) воткнёшь проверку в модуль, один раз исправишь в параметрах в цб время захвата таблиц. Всё

(169) Эти регистры вырезать за ненадобностью, ими в ТИСе никто и никогда не пользовался

В модулях найти все строки, которые толкают этот регистр и заремить.

это минут на 5 работы

(168) добавь константу ВремяОжиданияЗахватаБазы и немного модифицируй (158), а именно

Если Найти(СтрокаТекста,Симв(34)+"LockWaitTime"+Симв(34)+","+Симв(34)+""+Константа.ВремяОжиданияЗахватаБазы+""+Симв(34))=0 Тогда
                    МойТекст1С.ЗаменитьСтроку(НомерСтрокиТекста,
                    "{"+Симв(34)+"LockWaitTime"+Симв(34)+","+Симв(34)+""+Константа.ВремяОжиданияЗахватаБазы+""+Симв(34)+"}}");
                    ЛокВэйт=-1;


И тогда в центре ставишь 15 и оно в центре у всех будет 15, а на филиале ставишь константу в 0

(172) Но один раз закрыть-то надо по-любому а чем хз?
(174) Текстовая константа или числовая ?

(175) число Длина 3 точность 0, неотрицательный

(171) Вырезать регистры вообще из конфигурации? И сдлеать потом ТИИ с пересчетом итогов?

(177) Для начало просто отключи движение по ним

(176) Спасибо. С утра дурдом а потом как-то все нормально

(178) Отключу а потом как закрыть чтоб больще не лезть в них?
Типа документа ввода остатков?

(180) грохни dbf физически

(177) Можешь и оставить, на память, только сами таблички прибей потом. Чтоб файловое место не занимали и чтоб пересчету регистров не мешали

(182) понял. спасибо. попробую

+ можно повырезать лишнюю аналитику с регистров, можно поуменьшать размеры ресурсов регистров, всё это уменьшит размер дбф

и увеличит производительность

(184) А много там лишней аналитики? Где стоит вырезать? Ведь основные - это  продажи, партии, остатки, резервы, банк, покупатели и поставщики, касса. Что там вырезать-то? Хотя да -ценапрод не нужна в остатках тмц

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

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

Да там, много чего повырезать можно

и переписать на норм алгоритмы.

(189) Учет многофирменный. НП выкинуть - это полконфигурации менять. В валюте ничего не ведем

Да, если учет по-средней, можно повырезать партии.

(187) мы тупо раз в 2 недели запускаем cmd файл

DEL R?4480.*

Ну и помечаем на удаления заявки и закрытие резерва

(192) Учет по ФИФО

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

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

(196) в том то и дело, что блокировки нет, ибо пока кто-то не провёл документ, блокируется 1sjourn целиком. зато сразу оутлуп, и не надо ждать 10 секунд и создавать очередь на ожидания

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

(198) Чем его ускорить (проведение)? У меня и так за секунду порой по 3-4 дока создаются

(199)+ Самое фиговое что создана например громадная Заявка покупателю и из-за транзакции приходится порой создавать ее заново, вот как с этим быть. юзеры ругаются. Это нечасто бывает но бывает

(199) уменьшить период хранения останков, желательно вынести проверки до обработки проведения, выкинуть запись лишних движений.
Проводить все документы в потоке.
Для "заднего" числа, переписать получение останков на прямой запрос.
Хотя, и с 5-ю днями будет гоооораздо быстрее делатся временный расчет регистров

(201) А как быть с открытием периода ?

(201) А что значит в потоке? Ведь остатки же все начнут лететь

(202) открывать
(203) проводить новые доки со сдвигом та

(203) Слова знакомые но сути не понял

(205) Но новые документы и так проводятся же со сдвигом ТА

(195) Резервы? Так используем гиперактивно. Настолько что через месяц начинает всё тормозить. Поэтому раз в 2 недели тупо грохаем движение и документы

(204) ЕПРСТ
У нас так:

Новые документы записывать:
С текущим временем - флажок пустой
после ТА - флажок пустой

Новые документы проводить:
после ТА (в реальном времени) - флажок пустой
при проведении после ТА заменять время на текущее - флажок непустой

Может тут что-то не так?

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

типа     ПроводитьПослеТА(1,1);

только надо быть аккуратнее с приходами

(210) Алексей.Это в каком месте вставлять?

Процедура ПриОткрытии()

(213) А что это практически даст?

Для поступлений/возвратов я бы прописал бы
    ПроводитьПослеТА(1,-1);

(215)Спасибо понял а что это все-таки даст на практике ?

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

(217) А что делать в конце дня? И потом много документов создаются и проводятся обработками. Там нет ПриОткрытии :)

(218)
Провести(<?>,);
Синтаксис:
Провести(<Режим>,<Знач>)
Назначение:
Выполнить проведение документа.
Возвращает: 1 - если проведение документа выполнено, 0 - иначе.
Параметры:
<Режим> - необязательный параметр. Число: 0 - проводить документ без сдвига ТА; 1 - проводить непроведенный документ реальным временем (со сдвигом ТА); 2 - перепроводить проведенный документ реальным временем (со сдвигом ТА); 3 - проводить любой (непроведенный, проведенный) документ реальным временем (со сдвигом ТА). Значение по умолчанию - 0.

(219) Так в конце дня как быть? Что-то надо будет перепроводить массово?

(220) ну ты когда обработкой созздаешь докуи там и пиши что проводить на ТА

Док = создатьОбъект(
...
Док.Провести(3);

(0) Выкинте, пожалуйста, семерку, меня от неё тошнит(

(221) Я понял. То есть вечером или ночью ничего восстанавливать не надо
(222) Давно бы выкинул только в ней 45 пользвателей только на ЦБ и еще перифериек 5

(222) а сюда ты зачем зашел? Поблевать?

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

Вообще странно:
Работает собственно только кассир.
И вот в течении минут 15 при попытке создать автоматом дополнительный к чеку документ "Движение бухт по чеку" идет ошибка "обращение к таблице 1SJORN" - Ошибка обращения к данным при транзакции выполняемой Другим пользователем. Но как-то вот нет этого другого пользователя