Вход | Регистрация
    1  2  3  4  5  6  7  8   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций
Я
   tgu82
 
28.10.20 - 13:18
1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

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

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

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

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

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

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!
   Kigo_Kigo
 
1 - 28.10.20 - 13:48
SQL
   tgu82
 
2 - 28.10.20 - 13:49
(0) Как увидеть кто начал цепочку блокировок и его притормозить?
   tgu82
 
3 - 28.10.20 - 13:51
(1) А что в SQL таких проблем разве нет?
SQL хорошо но слишком много разом переписывать на прямые.
Да еще и на всех ПБ надо тогда SQL а там по 3-4 компа
   Kigo_Kigo
 
4 - 28.10.20 - 13:51
(3) Зачем?
   tgu82
 
5 - 28.10.20 - 13:54
(4) А что - на них свертку делать?
Ведь если SQL то ЦБ может быть быть уже любого размера
а на ПБ как тогда быть?

Мне бы сейчас срочно увидеть кто начал цепочку блокировок и его притормозить?
Может с помощью 1С++ как-то это можно отловить?
   Mikeware
 
6 - 28.10.20 - 13:54
(3) прекрасно работала центральная сиквельная (она тогда еще не очень большая была, гигов под 50) с четырьмя файловыми периферийками.
   Mikeware
 
7 - 28.10.20 - 13:55
(5) в файловых - имхо, никак
   tgu82
 
8 - 28.10.20 - 13:59
(6) Практически вся инфа одинакова что в ЦБ что в ПБ
и регистра движения партий тот же вылезет за 2 ГБ и что тогда делать?

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

Ну что кроме реально обмена (не очень уж он частый) может блокировать надолго доступ к базе данных?
Если время ожидания в ноль - значит сразу же должен отлетать. а другие как раз могут работать
   tgu82
 
9 - 28.10.20 - 14:01
(7) вроде как кернел33 я пользуюсь или 37 (ззабыл уже) чтобы проц в 100% не уходил, но как раз он и не уходит
   Kigo_Kigo
 
10 - 28.10.20 - 14:01
(6) (7) и я про тоже, да в SQL  такой проблемы не будет ИМХО, по крайней мере у меня не стало после перехода скуль, до скуля было, но еще было -  переписать обработку проведения расходной накладной, их выписывают много и много народа, а расчет регитров в проведении стал тормозить, вот и была такая бяка, это помогло но не надолго, перевел на скуль и забыл
   Mikeware
 
11 - 28.10.20 - 14:12
(8)
1. а зачем одинаковая инфа в ЦБ и ПБ? может, пересмотреть архитектуру системы, если не хочешь менять систему хранения?
2. в периферии все движения по партиям могут быть не нужны. в любом случае - надо смотреть архитектуру. ну, или переводить то, где большие объемы - на серверное хранилище.
3. запись в БД - не поможет.
4. время ожидания в ноль - он вроде как раз долбится  без ограничения по времени?
(9) как вариант, смотри чей сеанс в 99% (у тебя же терминал, насколько помню?), пытай пользователя
   Kigo_Kigo
 
12 - 28.10.20 - 14:17
И да ПБ и ЦБ вообще фиолетово какие базы скуль или ббф
   Kigo_Kigo
 
13 - 28.10.20 - 14:17
*дбф
   tgu82
 
14 - 28.10.20 - 14:31
(12) Не понял.
Насчет 99% процессора - надо поглядеть.
(11) Ну если приход весь на ЦБ то значит дальше все перемещениями на ПБ. Но ведь и приход тоже на ПБ уйдет иначе его уже не перепроведешь елси что. Все кроме РКО и строк выписки банка (расход) мигрирует во всех базах, ну еще Чек ККМ (место создания и центр)
   tgu82
 
15 - 28.10.20 - 14:38
(14)+ Читаю - все ж это было и раньше.
И советуют время ожидания захвата таблицы БД в ноль установить.
То есть по идее сразу идет сообщение о блокировке и никто не ждет

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

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

А что править в CFG файле?
   Mikeware
 
16 - 28.10.20 - 14:39
(14) ну и сделай, чтоб на периферию уходили только нужные документы. Рецептов минимум два.
   tgu82
 
17 - 28.10.20 - 14:42
?(16) А тогда надо модули проведения переделывать. Если периферийка чтоб на смотрела остатки по ЦБ при проведении перемещения.
Но тогда контроль остатков вообще улетит или нет?
   tgu82
 
18 - 28.10.20 - 14:52
(16) 2 рецепта - это какие?
   Mikeware
 
19 - 28.10.20 - 14:59
(17) периферийка смотрит только на свои остатки. контроль остатков происходит в своей зоне ответственности (склады, кассы)
2 рецепта - это "пустышки с периферийки" и "чистка апдейтса".
   tgu82
 
20 - 28.10.20 - 15:04
(19) Пустышки - да, давно была идея ,с апдейтс сложнее - надо прямой запрос рисовать
Как-то стремно было - вроде ж работает в-осовном нормадьно и ладно. Даже писал программы
Ну и потом партии - фифо у нас. Магазины есть с оптовыми реализациями - значит надо партии чтоб они видели
Точнее свою маржу.
   Mikeware
 
21 - 28.10.20 - 15:17
(20) на прямой запрос на чистку апдейтса в далеком 2008 я потратил с неделю - при этом в общем и подсказать было некому особо. Но при этом там была еще и настройка "какие объекты в какую базу" (была ИБ, в которой торговля была не только за нал с расчетом на месте, но и за безнал, который приходил в офис. поэтому уходили в эту базу расчеты только некоторых контрагентов. Ну и еще какие-то аналогичные правила. Плюс база была - "снежинка". точнее - "куст".)

ну свои партии магазины и увидят.
   Aleksey
 
22 - 28.10.20 - 15:29
Функция УстановитьВ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);
        ЗавершитьРаботуСистемы();
    КонецЕсли;    
...
   Aleksey
 
23 - 28.10.20 - 15:29
(22) к (15)
   tgu82
 
24 - 28.10.20 - 15:33
(23) Спасибо! Да пользовался я этим скриптом
   Aleksey
 
25 - 28.10.20 - 15:36
(24) Кэширование констант из прошлой ветки тоже сделал? (1С 7.7 ТИС на SQL - взлетит? База большая, еще 6 перифериек,юзеров>40 терм режим)
   tgu82
 
26 - 28.10.20 - 15:41
(25) Нет. Работает же все )
По-сути это в начале все константы в список значений кроме периодических. (при начале работы системы)
Ну и
   tgu82
 
27 - 28.10.20 - 15:41
(25) Или периодические тоже?
   tgu82
 
28 - 28.10.20 - 15:43
(25) Поднимаю ветку  и буду глядеть. Тогд много ценного было. И время в ноль я устанавливал
   Mikeware
 
29 - 28.10.20 - 15:59
(25) а чтение констант разве лочит файловую базу?
Единственно, что оно медленное до оппы, и если чтение константы где-нибудь в транзакции, да еще в цикле - тогда она и приходит.
   tgu82
 
30 - 28.10.20 - 16:02
(29) Посмотрю но что-то яне помню чтоб в модуле проведения настолько актиывно в цикле константу проверял
тем не менее гляну. Единственное - вопрос периодических констант. Но кстати цены-то тоже периодические - а к ним же все время идет обращение
 
 Рекламное место пустует
   tgu82
 
31 - 28.10.20 - 16:24
Если не все мигрирует что касается партий и остатков - получаем незакрытые регистры. Кстати у меян книга продаж и книга покупок не закрывались. Я так-то вообще ими и не пользуюсь
   Mikeware
 
32 - 28.10.20 - 16:46
(30) именно поэтому чуть не первый вопрос был - как оптимизировать работу с ценами. Там и варианты с регистром были, и еще какие-то, и кэширование одноуровневое и двухуровневое, кэширование с освежением кэша, еще какие-то интересные способы. и, конечно, чтение цен прямым запросом.
   Mikeware
 
33 - 28.10.20 - 16:49
(31) ну и делаешь регламентное задание, которое раз в месяц тупо чистит эти регистры.
оно вообще секунды работает.
   tgu82
 
34 - 28.10.20 - 16:52
(33) чистит и движения и итоги?
   tgu82
 
35 - 28.10.20 - 16:56
(32) Заинтересовало. А что значит одноуровневое и двухуровневое?
Я делал в другой конторе давно типа такого универсального справочника и все вот эти данные заливал в него,
при начале работы считывал его в список значений, но опять же там не было необходимости в периодике
   Aleksey
 
36 - 28.10.20 - 18:50
(29) Косвенно. При записи и при модули проведения очень часто идет обращение к константам. И чем быстрее будет получен результат тем меньше времени занимает транзакция.
   torgm
 
37 - 28.10.20 - 19:26
(0)  1С 77 + SQL +TOYSQL  лечит вопрос, отключая часть блокировок.... Сам делаал лет 10 назад...
   tgu82
 
38 - 28.10.20 - 20:31
Много чего видно дописывал с неоптимальным кодом влезая куда не надо и не влезая куда надо. Особенно это проведение других документов в процедуре ПриЗаписи текущего документа. А у меня по кабельному учету и автоперемещениям с витрины много такого наворочено
   Ёпрст
 
39 - 28.10.20 - 21:30
(0)
>>>Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
>>>Тогда бы можно было его притормозить а другие бы работали дальше !!!

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

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

Да и в жр, если он не отключен, за ненадобностю видно, у кого транзакция открыта
   Ёпрст
 
40 - 28.10.20 - 21:35
Ну тис то соптимизировать для полёта..недолго, всего то выкинуть лишнюю неиспользуемую аналитику, период выставить в 5 дней и ожидание блокировки захвата таблиц в 0.
В групповых обработках проведения втыкать счетчик на запись, допустим 20 попыток, в обработка исключения ловить, что если это ошибка блокировки журнала, например при транзакции, то долбить дальше.
Таким образом, если можно хоть всю базу ставить на перепровод, не мешая остальным человекам работать. Рано или поздно, в цикле влетит в перепровод, даже за меньше чем 10 попыток
   Ёпрст
 
41 - 28.10.20 - 21:35
да..много чего можно сделать
   Ёпрст
 
42 - 28.10.20 - 21:36
вплоть до получения останков в модуле проведения прямым запросом, хотя с периодом 5 дней, даже тормоз рассчитатьитогина будет летать
   tgu82
 
43 - 28.10.20 - 23:13
(42) Период итогов в 5 дней - это регистры остатков сильно вырастут ?

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

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

Или кто-то долбит документы а все стоят, а долбит впустую ибо один вид дока наезжает на другой.
Увидел это - тут же его отключил и все заработали.
Но как сделать чтобы аж визжал комп и ругался что Сидоров лупит черт что в одиночку
   tgu82
 
44 - 28.10.20 - 23:14
(42) Итоги по всем регистрам остатков 5 дней? Забыл уже, надо глянуть где устанавливается
   Ёпрст
 
45 - 28.10.20 - 23:18
(44) операции - управление итогами.
Тока, регистры должны быть закрытыми, иначе, можешь и не дождаться пересчета или открытия след периода
   Ёпрст
 
46 - 28.10.20 - 23:20
Да и сами регистры можно пооптимизировать, где нужно, втыкать быструю обработку движений или ставить отбор по итогам на нужных измерениях.
Избавиться от лишних измерений, подвигать измерения в правильном порядке для попадания в индекс, порезать размерность числовых ресурсов ну и т.д
   Злопчинский
 
47 - 29.10.20 - 00:46
я хз что там может так массово в транзакции/блокировки попадать. если только все с дикой скоростью херачат документы массово проводят и перепроводят.
   Андрей_Андреич
 
48 - 29.10.20 - 07:36
(47) Запросто из этих юзеров половина регулярно гоняет тяжелые отчеты
(0) Я же тебе в начале июня переписал списание партий и остатков на прямые запросы. Там оставалось на полдня шкуркой зачистить. Чего дожидаешься?
   Mikeware
 
49 - 29.10.20 - 07:47
(48) Отчеты не блокируют, они - насколько помню - ждут окончания блокировки.
"списания на прямые" - ему не рановато? вдруг возникнут проблемы, а он не найдет по недопониманию... Начинать надо хотя бы с расчетов прямыми...
(47) была бы дикая скорость - база была бы побольше. у меня когда 8 тыщ доков в день хренячили - база чуть не на гиг в месяц приростала, если не больше.
единственное, что могут одновременно хренячить - "перед обедом" или "перед концом рабочего дня"
(43) что значит "один вид дока наезжает на другой"? Он хотя бы по понятиям наезжает, или по беспределу?
   Андрей_Андреич
 
50 - 29.10.20 - 07:57
(49) Они не блокируют, но все равно нервный фон серваку создают. А списание партий и остатков - это две процедуры в ГМ. Ну и помощь зала никто не отменял - вроде здесь помогают оперативно
   Mikeware
 
51 - 29.10.20 - 07:57
(39) писать в стороннюю базу можно. но у него, похоже, не только интерактивные блокировки - но и создания доков из других при записи этих других, и т.п.
Ну и начало интерактивной блокировки ты отловишь-зафиксишь, а окончание? Или я где-то туплю?
   Mikeware
 
52 - 29.10.20 - 07:58
(50)
- Доктор, меня все игнорируют!
-- Следующий!!!
©
   Mikeware
 
53 - 29.10.20 - 07:59
(50) вот что бы я переделал - это отчеты. особенно типа ведомости по контрагентам, или "продажи" в 100500 разрезах (ну, тот вообще на олап хорошо ложится)
   Андрей_Андреич
 
54 - 29.10.20 - 08:04
(53) Отчетов много, а тут 2 процедуры и все. Много лет назад перед переходом на СКЛ собрал статистику за 3 месяца по отчетам/юзерам/времени выполнения. Удивились как народ любит "аналитические" отчеты за год запустить и идти курить.
   Bigbro
 
55 - 29.10.20 - 08:05
если проблемы в ЦБ - запретите в ней работу.
пусть информацию только в периферийках вносят, потом чтобы в ЦБ сливалось все.
для тяжелых отчетов можно отдельную периферийку замутить, с только выгрузкой.
   Андрей_Андреич
 
56 - 29.10.20 - 08:08
(55) Все гениальное просто :)
   Bigbro
 
57 - 29.10.20 - 08:11
(56) ну это то что проверено и работает. и сделать несложно, не переписывая конфигурацию.
дальше меры понятно по нарастающей надо применять если недостаточно будет.
   Sserj
 
58 - 29.10.20 - 08:18
(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. Все остальное полумеры.
   Ёпрст
 
59 - 29.10.20 - 08:20
(53) да отчеты переписать, это фигня, сперва надо заставить базу работать как надо, чтобы за ночь, она вся перепроводилаь, например. У нас была комплексная, двойной учет. Были задвоенны или записи в регистре или сами регистры, если в размер не влазили. 2 плана счетов. И ничего, перепроводилась вся за ночь. Правда, за место уриба был мод.
   Ёпрст
 
60 - 29.10.20 - 08:21
(58) с его объемами, это лишнее
 
 Рекламное место пустует
   ДенисЧ
 
61 - 29.10.20 - 08:23
(58) "отчеты вообще ничего никогда не блокируют
Shared-то по-любому будут ))
   Mikeware
 
62 - 29.10.20 - 08:30
(54) ну и формировать аналитические кубики ночью, а днем давать доступ только к кубику типа https://radikal.ru/lfp/s010.radikal.ru/i311/1510/4d/8e08b02e4265.jpg/htm
(59) у меня только себестоимость пересчитывалась. но в часы наименьших нагрузок, когда всего десяток юзверей в базе, ну и немонопольно, конечно. вся, конечно, не перепроводилась за отведенное время, но несколько месяцев успевала. год, емнип, трое суток догонялся.
   tgu82
 
63 - 29.10.20 - 08:39
(55) ДА, планирование закупок и закзаы поставщикам давно уже вынес в отдельную периферийку. Еще переводим всех менеджеров на проводную сеть а то раньше была радиосеть - видимо растет документоооборот в базе и уже вай-фай не выдерживает таких нагрузок.
   Mikeware
 
64 - 29.10.20 - 08:43
(63) так у вас это через вафлю? ну-ну...
   Андрей_Андреич
 
65 - 29.10.20 - 08:47
(63) Напомни - терминал-сервер или по сети работают?
   tgu82
 
66 - 29.10.20 - 08:55
(65) Конечно терминальный сервер и довольно мощный.
(64) Ну да, хотели когда-то чтоб было красивво и мобильно, без проводов, ну а теперь переделываем на провод
   tgu82
 
67 - 29.10.20 - 08:57
Юмор в том что транзакции в понедельник и реже в пятницу. Вчера их практически не было, думаю что и сегодня не будет и во вторник почти не было
   ДенисЧ
 
68 - 29.10.20 - 08:59
Если все в терминалке - то способ подключения не важен. Не гоняете же вы базу по сети...
   tgu82
 
69 - 29.10.20 - 08:59
(46) Я попробовал убрать одно измерение с регистра, очень долго убирал. Ну на копии.
   tgu82
 
70 - 29.10.20 - 09:01
(68) Не гоняем, но тем не менее после того как часть вернули на провод - шума по поводу зависаний и прочего стало меньше
   Ёпрст
 
71 - 29.10.20 - 09:04
(69) убрать измерение с регистра..минут 10 на все, вместе с переписыванием кода.
   Ёпрст
 
72 - 29.10.20 - 09:04
Руками, разумеется, а не штатной реструктуризацией
   tgu82
 
73 - 29.10.20 - 09:04
Загрузка выписки из клиент-банка - вот еще источник транзакций ибо много чего создается один чохом и другие затыкаются
   Mikeware
 
74 - 29.10.20 - 09:05
(66) если терминал, то способ подключения пофиг. хоть LTE
(67) почему ж "юмор"? пиши даты перепроводимых документов, и анализируй. вангую, что в пятницу они "хренячат план", а в понедельник они "подчищают хвосты за пятницу"
   tgu82
 
75 - 29.10.20 - 09:07
(74) В понедельник приход больщой вводится и большие перемещения с центрального склада на магазины. В пятницу пока не смотрел что.
   Андрей_Андреич
 
76 - 29.10.20 - 09:11
(75) Им бы понедельники взять и отменить (с)
   tgu82
 
77 - 29.10.20 - 09:13
(76) Клиент банк один хрен каждый день загружается массово
   Mikeware
 
78 - 29.10.20 - 09:14
(71)(72) дык! Но этот способ не освящен БоГ'ом (БОрисом Георгиевичем)...
(73) ну так давай паузу в клиент-банке. пусть остальные просрутся в этот момент
(74) ну и готовь доки заранее. У тебя будут хотя бы уже сформированы доки, записи партий...
(75) они и фторнег загадят
   tgu82
 
79 - 29.10.20 - 09:17
(78) Две минуты транзировалось сегодня из-за нескольких десятков строк выписки банка и дальше все тип-топ
   tgu82
 
80 - 29.10.20 - 09:19
(78) С доками проблем нет все большие поступления делаются через загрузку тч из файлов всяких (csv txt xml dbf xls)
Правда после загрузки при записи их разбухтовывают
   Bigbro
 
81 - 29.10.20 - 09:20
ну перепиши загрузку из банк клиента. сделай там окна для работы других.
просмотри код, может там начать транзакцию и зафиксировать транзакцию первой и последней строкой.)
   tgu82
 
82 - 29.10.20 - 09:21
(80)+ Большие перемещения - тч тоже заполняется одной кнопкой а все предварительная подготовка через обработку, то есть тч перемещений многосотенно строчных формируется заранее и руками не вбивается
   tgu82
 
83 - 29.10.20 - 09:22
(81) После ряда загруженных выписок - паузу? и потом дальше или как-то хитрее?
   tgu82
 
84 - 29.10.20 - 09:24
окБухт.Новый();    : {Глобальный модуль(16228)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем 

Это чаще всего пожалуй. Дохбухт создается в процедуре ПриЗаписи документов реализация, поступление и т.д. и проводится в ней же, то есть своего рода резервирование отрезанных кусков происходит. Вот здесь собака выдимо зарылась еще
   tgu82
 
85 - 29.10.20 - 09:26
(84)+ И что важно - для чеков ККМ а их немало за день тоже создается разбухтовка
   tgu82
 
86 - 29.10.20 - 09:31
Записать(); : {Документ.ЧекККМ.Форма.Модуль(1482)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем 

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

        ПриЗаписиПерепроводить(0);
        Записать();
        ПриЗаписиПерепроводить(1);
Вот здесь Записать()

Кстати никогда нет ошибок транзакций при проведении (не вид), есть именно при создании записи и т.д.
   Mikeware
 
87 - 29.10.20 - 09:34
(84) значит, создавай доки заранее, пустыми. по крайней мере, не будет транзакций на создании, получении ида и номера
   Bigbro
 
88 - 29.10.20 - 09:35
(84) не знаю что за разбухтовка
но если подобные вещи
то быстрый и очевидный костыль - обернуть в попытку исключение и в цикл.

ну и в целом программное создание документов при интерактивной записи/проведении другого документа - это не очень.
   tgu82
 
89 - 29.10.20 - 09:38
(88) Да вроде в-основном срабатывает а главное что если транзакция то она просто в исходное состояние отбрасывает и не надо потом что-то выискивать (хвосты).
   Mikeware
 
90 - 29.10.20 - 09:39
(88) попытка-исключение в цикле, и пауза!!! Причем лучше случайная. И все это в цикле.
Но лучше при этом еще и документы брать созданные заранее, а не создавать - это на одну транзакцию меньше
   tgu82
 
91 - 29.10.20 - 09:41
(87) Какие создавать  доки пустые? Ведь и банк и касса и реализация и чеки и перемещения и т.д.
бухи с тура еще автоматом массово расходники создают по эквайрингу в цб со всех магазинов (через обработку конечно)
   Bigbro
 
92 - 29.10.20 - 09:42
(91) и вот эти обработки с массовым созданием тоже смотреть - тоже делать в них окна для работы.
   tgu82
 
93 - 29.10.20 - 09:43
(92) Да их вообще можно роботом рано утром делать. Просто не заморачивался этим
   Mikeware
 
94 - 29.10.20 - 09:43
(91) разбухтовки твои создать пустые в часы без нагрузки - у тебя-то точно не 24*7, халява же.
можно и банк, конечно, но банк это мелочь. ну там склько, сотни три-четыре доков?
   Mikeware
 
95 - 29.10.20 - 09:44
(93) ну так, млять, заморочься! :-))
   tgu82
 
96 - 29.10.20 - 09:44
У меня 11*7. Не совсем халява
   tgu82
 
97 - 29.10.20 - 09:45
(95) Считай что заморочился. И делать их надо в 6 утра и кстати загрузку клиент-банка туда же в робота надо.
   Bigbro
 
98 - 29.10.20 - 09:47
но вообще оценивая количество костылей - стоит подумать и более кардинально проблему решить.
с переездом на скуль и на прямые запросы возможно.
и обрезать старое. оставить в оперативной базе только необходимый для работы период, в торговле обычно года достаточно.
остальное в архивных базах
тут кто то решение показывал чтобы отчеты можно было итоговые прозрачно формировать из баз нескольких периодов.
   tgu82
 
99 - 29.10.20 - 09:50
(98) Насчет торговли - 4-5 лет надо. Ибо возвраты через отчет ккм тот же.
Насчет перехода на скуль или 8-ку. ДА все думаю - не взлетело пока. Наверное стремно что-то резко менять. Одно дело безнал и другое дело массовые продажи в 6 магазинах. Вдруг заткнется где-нибудь сильно. А тут вроде все проверено уже годами
   olegves
 
100 - 29.10.20 - 09:51
(0) /регистр RA328 подходит к 1.7 ГБ/ как будет 2Гб у тебя база совсем встанет, так что срочно переводи на СКЛ или увольняйся
  1  2  3  4  5  6  7  8   

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