Просмотр полной версии : ОЧЕНЬ медленная обработка смен Сервером Отчетов
Доброго дня, ALL!
Последние 4 дня УЖАСНО долго перевариваются выгрузки с кассовых серверов.
SQL-базы сервера отчетов (около 4,6Гб на текущий момент) и tempdb лежат на SSD, памяти 32Гб, iCore5, но несчастных 40 файлов выгрузки смен (размер не больше 3Мб) уже 4 часа переворачивает в incoming и почему-то файлов то меньше становится, то снова прибавляются.
3824
3825
Версия платформы 7.5.2.471
Куда копать?
shift2sql (http://www.carbis.ru/forum/r-keeper-7/8442-%D0%9F%D0%B5%D1%80%D0%B5%D0%BA%D0%B0%D1%87%D0%BA%D 0%B0-%D1%81%D0%BC%D0%B5%D0%BD%D1%8B-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-%D1%83%D1%82%D0%B8%D0%BB%D0%B8%D1%82%D1%8B-shift2sql-exe.html) пользуетесь? Если нет, то надо.
shift2sql (http://www.carbis.ru/forum/r-keeper-7/8442-Перекачка-смены-с-помощью-утилиты-shift2sql-exe.html) пользуетесь? Если нет, то надо.
Разумеется.
В настройках RepsServ.ini
UseShift2SQL = 1
Кстати, именно MSSQL2012 стабильно грузит 1 ядро (общая загрузка CPU 25%)
P.S. в этом же файле настроек внедренцы поставили
UseShift2SQl="1"
UseShift2SQL = 1
Какой вариант правильный - с кавычками или без?
UseShift2SQL= 1
LoadThreadsCount = "4" - загружать данные закрытых смен в накопительную БД параллельно, "4" - число обрабатываемых параллельно файлов (рекомендуется при большом количестве одновременно поступающих файлов смен). Версия должна быть не ниже 7.5.2.328!
UseShift2SQL= 1
LoadThreadsCount = "4" - загружать данные закрытых смен в накопительную БД параллельно, "4" - число обрабатываемых параллельно файлов (рекомендуется при большом количестве одновременно поступающих файлов смен). Версия должна быть не ниже 7.5.2.328!
Вроде как я СПЕЦИАЛЬНО СРАЗУ написал, что
Доброго дня, ALL!
Версия платформы 7.5.2.471
nikolabogetic
03.06.2015, 18:38
В настройках сервера отчетов Режим БД какой стоит? Надо чтоб стоял маленький (только чеки).
VampireKB
03.06.2015, 18:49
Я думаю все банальней..
Теоречиски попалась битая смена(битый файл) и прога не может ее обработать
Имхо!!
В настройках сервера отчетов Режим БД какой стоит? Надо чтоб стоял маленький (только чеки).
1. Такой и стоит изначально.
2. Настройки не менялись.
alkon132
04.06.2015, 09:36
А как насчет совета от VampireKB?
Попробуйте очистить папку incoming (и retrylist заодно) от этих .tmp файлов и потом подкинуть необработанные смены вручную, желательно по одной.
А как насчет совета от VampireKB?
Попробуйте очистить папку incoming (и retrylist заодно) от этих .tmp файлов и потом подкинуть необработанные смены вручную, желательно по одной.
Нерационально - у меня нет столько времени чтобы после каждого файла ждать пересчета кубов (полчаса) и смотреть появилась ли смена в отчетах.
К тому же понятие "битый файл" не применимо - у каждой выгрузки есть что-то типа CRC32/MD5/SHA1 и я не думаю, что в UCS не догадались поставить проверку файла перед закачкой.
alkon132
04.06.2015, 10:27
Ну для начала, ждать пересчета кубов не надо. Достаточно, чтобы смена появилась в "информации об общих сменах". Если она туда попала - 99,9%, что в отчетах она будет. Если использовать shift2sql - пересчет кубов и импорт смен не должны друг другу мешать, это независимые процессы.
Второе - встречался с таким, что в "incoming" появляются файлы, которые сменами собственно не являются. Онлайн сбор данных с кассовых серверов не включен случайно?
и я не думаю, что в UCS не догадались поставить проверку файла перед закачкой.
Догадались, конечно. Если файл испорчен - информация о проблемах с ним будет в логе сервера отчетов. Дальше, если я не ошибаюсь, он попадет в папку "retrylist". Дальше через некоторый промежуток времени опять пытается закачаться. (с алгоритмом могу врать, но общий смысл такой).
А лог сервера отчетов покажете?
Ну для начала, ждать пересчета кубов не надо. Достаточно, чтобы смена появилась в "информации об общих сменах". Если она туда попала - 99,9%, что в отчетах она будет. Если использовать shift2sql - пересчет кубов и импорт смен не должны друг другу мешать, это независимые процессы.
Увы, но этого не достаточно. Поэтому и приходится лезть в эту таблицу, НА КАЖДОЙ, не попавшей в отчет/куб, смене ставить "Разрешить перезакачать смену", закидывать её в Incoming и ждать пока пересчитаются кубы чтобы увидеть реализации. А Shift2sql работает с момента разделения серверов на Сервер Справочников и Сервер Отчетов уже года 2.
По второму пункуту - какой именно вы лог хотите увидеть?
alkon132
04.06.2015, 19:49
Странно, честно говоря. Если в "информации об общих сменах" смена есть, значит она прошла "проверку на качество" и сервер отчетов ее съел.
Про онлайн сбор данных всё-таки ответьте, пожалуйста.
Лог сервера отчетов. Т. е. того сервера, который занимается файлами в папке incoming.
repsserv.stk, ЕМНИП
Странно, честно говоря. Если в "информации об общих сменах" смена есть, значит она прошла "проверку на качество" и сервер отчетов ее съел.
Про онлайн сбор данных всё-таки ответьте, пожалуйста.
Лог сервера отчетов. Т. е. того сервера, который занимается файлами в папке incoming.
repsserv.stk, ЕМНИП
-------------------END STACK------------------
667:Cash server 01MIDSERV data process error: Server 01MIDSERV disconnected running function MIDGETWORKDATA.
-------------------------------------
05.06 09:58:20
219:Server 03MIDSERV disconnected running function MIDGETWORKDATA
-------------------Start STACK------------------
0001209C.D:\RK7\bin.2015\win\errors32.DLL
00022D8D.D:\RK7\bin.2015\win\netkern.dll
0002B078.D:\RK7\bin.2015\win\netkern.dll
0002B8BD.D:\RK7\bin.2015\win\netkern.dll
0002DEBC.D:\RK7\bin.2015\win\netkern.dll
000C6E81.D:\RK7\bin.2015\win\rkReportsServer.exe
00391878.D:\RK7\bin.2015\win\rkReportsServer.exe
003954BB.D:\RK7\bin.2015\win\rkReportsServer.exe
00012CB2.D:\RK7\bin.2015\win\THREAD32.DLL
0000F829.D:\RK7\bin.2015\win\THREAD32.DLL
0001336A.C:\Windows\syswow64\kernel32.dll
000392B2.C:\Windows\SysWOW64\ntdll.dll
00039285.C:\Windows\SysWOW64\ntdll.dll
-------------------END STACK------------------
667:Cash server 03MIDSERV data process error: Server 03MIDSERV disconnected running function MIDGETWORKDATA.
-------------------------------------
05.06 09:58:33.206
26:UDB Export <-
-------------------------------------
05.06 09:58:33.206
26:Entiny DB Export ->
-------------------------------------
05.06 09:58:33.206
26:Entiny DB Export <-
-------------------------------------
05.06 09:58:33.253
26:SQL Export (shift2SQL) ->
-------------------------------------
05.06 09:58:36.794
26:Cash Data received from server 02MIDSERV(15003), size: 574464
-------------------------------------
05.06 09:58:36.997
26:Cash Data processed
-------------------------------------
05.06 09:58:46.450
26:Cash Data received from server 01MIDSERV(15001), size: 594944
-------------------------------------
05.06 09:58:46.778
26:Cash Data processed
-------------------------------------
05.06 09:58:49.71
26:Cash Data received from server 03MIDSERV(15079), size: 486400
-------------------------------------
05.06 09:58:49.133
26:Cash Data processed
-------------------------------------
05.06 09:59:09.788
26:SQL Export (shift2SQL): fail <-
-------------------------------------
05.06 09:59:09
687:Cash server 36MIDSERV, file "D:\RK7\AllRepsBase2015\filesync\incoming\15077-658.udb" data process error: [09:59:09] [ERRX] EOleException: Время ожидания запроса истекло
-------------------------------------
05.06 09:59:55.418
33:New data ready in 20MIDSERV
-------------------------------------
05.06 09:59:55.418
33:New data ready in 20MIDSERV
-------------------------------------
05.06 09:59:55.418
33:New data ready in 20MIDSERV
-------------------------------------
05.06 10:00:09.21
33:New data ready in 19MIDSERV
-------------------------------------
05.06 10:00:09.21
33:New data ready in 19MIDSERV
-------------------------------------
05.06 10:00:09.21
33:New data ready in 19MIDSERV
-------------------------------------
05.06 10:00:11.517
33:New data ready in 18MIDSERV
-------------------------------------
05.06 10:00:11.517
33:New data ready in 18MIDSERV
-------------------------------------
05.06 10:00:11.517
33:New data ready in 18MIDSERV
-------------------------------------
05.06 10:00:27.772
26:Cash Data received from server 20MIDSERV(15040), size: 570368
-------------------------------------
05.06 10:00:27.804
26:Cash Data processed
-------------------------------------
05.06 10:00:42.764
26:Cash Data received from server 19MIDSERV(15038), size: 558080
-------------------------------------
05.06 10:00:42.795
26:Cash Data processed
-------------------------------------
05.06 10:00:44.698
26:Cash Data received from server 18MIDSERV(15036), size: 556032
-------------------------------------
05.06 10:00:44.730
26:Cash Data processed
-------------------------------------
05.06 10:01:09.861
26:File R:\Temp\2\rk7Reps\rk7Receive\rcvFC6C.tmp copied to retrylst: D:\RK7\AllRepsBase2015\filesync\retrylst\serv.1507 7.shift.658.udb (reason: UCSERR(440):Waiting for collection GLOBALSHIFTS to load timed out.)
-------------------------------------
05.06 10:01:09.861
26:copy to ftp server
-------------------------------------
05.06 10:01:09.970
26:GetShiftDataFileInfo
-------------------------------------
05.06 10:01:10.95
26:find midserver (restid: 1, servid: 15079, shiftn: 659)
-------------------------------------
05.06 10:01:10.95
26:mark shift data (server: 15079, shftno: 659)
-------------------------------------
05.06 10:01:10.95
26:shift data found, no further processing will be performed (server: 15079, shftno: 659)
-------------------------------------
05.06 10:01:10.95
26:copy to ftp server
-------------------------------------
05.06 10:01:10.173
26:GetShiftDataFileInfo
-------------------------------------
05.06 10:01:10.236
26:find midserver (restid: 1, servid: 15079, shiftn: 660)
-------------------------------------
05.06 10:01:10.236
26:mark shift data (server: 15079, shftno: 660)
-------------------------------------
05.06 10:01:10.236
26:shift data found, no further processing will be performed (server: 15079, shftno: 660)
-------------------------------------
05.06 10:01:10.236
26:copy to ftp server
-------------------------------------
05.06 10:01:10.329
26:GetShiftDataFileInfo
-------------------------------------
05.06 10:01:10.438
26:find midserver (restid: 1, servid: 15079, shiftn: 661)
-------------------------------------
05.06 10:01:10.438
26:mark shift data (server: 15079, shftno: 661)
-------------------------------------
05.06 10:01:10.438
26:shift data found, no further processing will be performed (server: 15079, shftno: 661)
-------------------------------------
05.06 10:01:10.438
26:copy to ftp server
-------------------------------------
05.06 10:01:10.516
26:GetShiftDataFileInfo
-------------------------------------
05.06 10:01:10.594
26:find midserver (restid: 1, servid: 15079, shiftn: 662)
-------------------------------------
05.06 10:01:10.594
26:mark shift data (server: 15079, shftno: 662)
-------------------------------------
05.06 10:01:10.594
26:converting udb file 'R:\Temp\2\rk7Reps\rk7Receive\rcv27B9.tmp' to abs file 'R:\Temp\2\rk7Reps\rk7Receive\rcv27BA.tmp'
-------------------------------------
05.06 10:01:10.594
26:UDB Export ->
-------------------------------------
05.06 10:01:10.953
26:UDB Export <-
-------------------------------------
05.06 10:01:10.969
26:Entiny DB Export ->
-------------------------------------
05.06 10:01:10.969
26:Entiny DB Export <-
-------------------------------------
05.06 10:01:11.47
26:SQL Export (shift2SQL) ->
-------------------------------------
05.06 10:01:11.640
26:converted udb file 'R:\Temp\2\rk7Reps\rk7Receive\rcv27B9.tmp' to abs file 'R:\Temp\2\rk7Reps\rk7Receive\rcv27BA.tmp'
-------------------------------------
05.06 10:01:14.26
26:SQL Export (shift2SQL): okay <-
-------------------------------------
05.06 10:01:14.26
26:Mark shift done (server: 15077, shftno: 659)
232:Server exception in RPC function REFDOUSERLOGIN
UCSERR(545):Incorect account/password combination or you don't have enough rights to log in the Manager Station.
-------------------------------------
05.06 10:03:14.115
26:File R:\Temp\2\rk7Reps\rk7Receive\rcvE1FA.tmp copied to retrylst: D:\RK7\AllRepsBase2015\filesync\retrylst\serv.1507 7.shift.659.udb (reason: UCSERR(440):Waiting for collection GLOBALSHIFTS to load timed out.)
-------------------------------------
05.06 10:03:14.115
26:copy to ftp server
-------------------------------------
05.06 10:03:14.225
26:GetShiftDataFileInfo
-------------------------------------
05.06 10:03:14.303
26:find midserver (restid: 1, servid: 15079, shiftn: 663)
-------------------------------------
05.06 10:03:14.303
26:mark shift data (server: 15079, shftno: 663)
-------------------------------------
05.06 10:03:14.303
26:converting udb file 'R:\Temp\2\rk7Reps\rk7Receive\rcvB19.tmp' to abs file 'R:\Temp\2\rk7Reps\rk7Receive\rcvB1A.tmp'
-------------------------------------
05.06 10:03:14.318
26:UDB Export ->
-------------------------------------
05.06 10:03:20.402
26:converted udb file 'R:\Temp\2\rk7Reps\rk7Receive\rcvB19.tmp' to abs file 'R:\Temp\2\rk7Reps\rk7Receive\rcvB1A.tmp'
-------------------------------------
05.06 10:03:58.310
26:UDB Export <-
-------------------------------------
05.06 10:03:58.326
26:Entiny DB Export ->
-------------------------------------
05.06 10:03:58.326
26:Entiny DB Export <-
-------------------------------------
05.06 10:03:58.357
26:SQL Export (shift2SQL) ->
alkon132
05.06.2015, 08:21
05.06 09:59:09
687:Cash server 36MIDSERV, file "D:\RK7\AllRepsBase2015\filesync\incoming\15077-658.udb" data process error: [09:59:09] [ERRX] EOleException: Время ожидания запроса истекло
Не нравится мне название файла, а про онлайн сбор данных вы не отвечаете. Ну попробуйте увеличить SQL Timeout в настройках внешних БД. Поставьте 10000.
05.06 10:01:09.861
26:File R:\Temp\2\rk7Reps\rk7Receive\rcvFC6C.tmp copied to retrylst: D:\RK7\AllRepsBase2015\filesync\retrylst\serv.1507 7.shift.658.udb (reason: UCSERR(440):Waiting for collection GLOBALSHIFTS to load timed out.)
Баг, исправлен в 7.5.3.204 (http://tracker.ucs.ru:8080/redmine/issues/49709#note-21)
05.06 10:01:10.438
26:shift data found, no further processing will be performed (server: 15079, shftno: 661)
Пытаетесь повторно вкачать смену, которая уже есть в "информации об общих сменах". Сервер говорит: такое у меня уже есть, делать ничего не буду.
232:Server exception in RPC function REFDOUSERLOGIN
UCSERR(545):Incorect account/password combination or you don't have enough rights to log in the Manager Station.
Баг, исправлен в 7.5.3.204 (http://tracker.ucs.ru:8080/redmine/issues/49709#note-21)
05.06 09:59:09
687:Cash server 36MIDSERV, file "D:\RK7\AllRepsBase2015\filesync\incoming\15077-658.udb" data process error: [09:59:09] [ERRX] EOleException: Время ожидания запроса истекло
Не нравится мне название файла, а про онлайн сбор данных вы не отвечаете. Ну попробуйте увеличить SQL Timeout в настройках внешних БД. Поставьте 10000.
Я хотел ответить, честно! :)
Просто не хотел посткаунт набивать, а вставить скриншот в то же сообщение, но глюк с буфером обмена (не копировалось) заставил перезапустить браузер.
Вот:
3829
Баг, исправлен в 7.5.3.204 (http://tracker.ucs.ru:8080/redmine/issues/49709#note-21)
Баг, исправлен в 7.5.3.204 (http://tracker.ucs.ru:8080/redmine/issues/49709#note-21)
Завидую вам, что можете отслеживать change-log - наш дистрибьютор не информирует о новых версиях и не сообщает какие изменения происходят.
---------- Добавлено в 11:30 ---------- Предыдущее сообщение было размещено в 11:07 ----------
05.06 09:59:09
687:Cash server 36MIDSERV, file "D:\RK7\AllRepsBase2015\filesync\incoming\15077-658.udb" data process error: [09:59:09] [ERRX] EOleException: Время ожидания запроса истекло
Не нравится мне название файла.
Это я его так назвал, т.к. с таким же номером уже был файл во входящих от другого кассового сервера
Решилась проблема следующим образом - в настройках кубов не было фильтра обработки и получалось, что Сервер Отчетов при поступлении новых выгрузок с кассовых серверов перекручивал все чеки, начиная с 1-ой записи в базе чеков. После установки фильтра в режим "Текущий месяц и 1 предыдущий" всё стало пересчитывать за 2-3 минуты.
P.S. Меня и бухгалтера по отчетам наказали по з/п, хотя я считаю, что это косяк дилера, изначально заставивший работать сервер с избыточной нагрузкой при пересчете смен.
После установки фильтра в режим "Текущий месяц и 1 предыдущий" всё стало пересчитывать за 2-3 минуты.
А где этот фильтр?
Привет.
Есть похожая проблема.
Перестал считаться куб по расходу (время ожидания запроса истекло).
База скуля большая (>15Гб).
Увеличение времени ожидания до (7-значного числа) не помогает, ошибка вылетает (при чем быстро).
Фильтр помогает только если поставить 2-3 дня для пересчета (10 дней уже не считает).
Последние удачные попытки пересчета длились примерно 2,5 часа.
Если напрямую сделать запрос в скуле - отрабатывает без ошибки примерно за то же время (как и раньше через РК7)
Оператива и проц с запасом, версия рк7 - 7.5.2.490, скуль 2012.
UseShift2SQL=1 - пробовал с ним и без него.
Где ещё можно копать?
alkon132
15.07.2015, 11:17
На всякий случай очевидный вопрос - редакция SQL не Express?
На всякий случай очевидный вопрос - редакция SQL не Express?
Нет, Microsoft SQL Server Enterprise.
В экспрессе 2012 10Гб ограничение, база уже 15.
Я думаю что если бы был трабл в самом скуле то запрос бы и в нем не выполнялся?
Кстати есть такая же проблема на экспрессе (база 700 метров), ещё не копался.
ЗЫ: Тот сервер про который спрашиваю - есть центральный, куда стекаются данные с локальных серверов отчетов.
можно попробовать сделать экспорт справочников в SQL заново. Возможно, "побились" представления куба.
Второй вариант - восстановить базу SQL из бекапа.
можно попробовать сделать экспорт справочников в SQL заново. Возможно, "побились" представления куба.
Второй вариант - восстановить базу SQL из бекапа.
С бэкапом попробую, хотя слабо верится, а вот по поводу побились - маловероятно, т.к. за любые пару дней считает без проблем и моментально.
Может вам сделать несколько кубов:
1 - Все данные за исключением текущего месяца. (пересчет раз в месяц)
2 - Данные за текущий месяц. (пересчет каждый день)
Снизите нагрузку на сервер, ускорите получение данных пользователям :)
Это будет оф. ответом UCS из рекомендаций по оптимизации кубов.
Есть еще вариант: Написать свой софт с отчетами, который будет работать быстрее :) Запросы кубов есть уже...
Есть ещё одна проблемка... после "копаний" в рк7, а конкретно:
1. создании доп.куба как раз с ограничениями на период (старый не изменял)
2. параметром UseShift2SQL
3. параметром maxcubecalcs
4. изменением таймаута построения кубов в свойствах конкретного сервера
и возврата всего к изначальным настройкам
ошибка вылетает даже на 10 днях... (при этом по 2 дня это период считается, т.е. косяка в этих днях нет никакого)
Есть еще вариант: Написать свой софт с отчетами, который будет работать быстрее :) Запросы кубов есть уже...
Похоже будет самый простой вариант :)
Похоже будет самый простой вариант
Ню-ню... Я бы хотел посмотреть на самописные кубы... Именно кубы, а не линейные отчеты в FR...
Если вам кубы не нужны и вы пользуетесь ими только для построение печатных форм, то вам прямая дорога к ИА отчетам...
Я бы хотел посмотреть на самописные кубы
По большому счету - лицензируется та же самая cube.dll и вперед.
По большому счету - лицензируется та же самая cube.dll и вперед.
И смысл?
Я не силен в технологии OLAP, но процедура пересчета кубов это же не просто "кнопочка в программе, не понятно зачем". Представления куба, хранящиеся в БД дают возможность оперативно формировать отчеты в разных разрезах. Если брать данные на прямую из SQL и сразу строить OLAP отчет, то легче никому не станет. А если писать свое представление куба, да еще с возможностью добавления полей и размерностей...
Может кому пригодится. То что я искал - в настройках внешних бд, параметр SQLTimeout.
И смысл?
Я не силен в технологии OLAP, но процедура пересчета кубов это же не просто "кнопочка в программе, не понятно зачем". Представления куба, хранящиеся в БД дают возможность оперативно формировать отчеты в разных разрезах. Если брать данные на прямую из SQL и сразу строить OLAP отчет, то легче никому не станет. А если писать свое представление куба, да еще с возможностью добавления полей и размерностей...
Там все проще. Берется представление, а дальше в своей программе ты фильтруешь данные. Куб = сохраненный набор данных из SQL.
---------- Добавлено в 15:02 ---------- Предыдущее сообщение было размещено в 15:01 ----------
параметр SQLTimeout.
И что, помогло быстрее пересчитывать кубы?
Куб = сохраненный набор данных из SQL.
Ок. Пусть так. Но тогда при закрытии смены что то должно пересчитывать кубы (что бы там новые данные появились). Весь разговор то начался с того что у UCS мол кубы кривые, надо свои написать, делов на 5 копеек...
Вот и получается что не так все там просто.
Дело в том, что сам запрос куба в базе SQL отрабатывается за несколько секунд, а куб пересчитывается от 20 минут, в зависимости от куба. У нас около 100 касс в базе, 20+ объектов. И если одна касса не дошла до времени автоматического пересчета, то работа с отчетами встает, пока идет пересчет нужных кубов.
И что, помогло быстрее пересчитывать кубы?
Помогло в принципе пересчитывать кубы. Писал что запрос в скуле выполняется, а при пересчете с кипера ошибка по таймауту.
---------- Добавлено в 16:38 ---------- Предыдущее сообщение было размещено в 16:36 ----------
Весь разговор то начался с того что у UCS мол кубы кривые
Где это написано?
Я думал, мы уже решили этот вопрос. Далее дискуссия пошла в русло оптимизации пересчета кубов :)
Где это написано?
Ну примерно от сюда пошел флейм...
Есть еще вариант: Написать свой софт с отчетами, который будет работать быстрее Запросы кубов есть уже...
давайте остановим оффтоп и перейдем к решению вопроса по средствам РК7? у кого какие идеи есть?
05.06 09:59:09
26:shift data found, no further processing will be performed (server: 15079, shftno: 661)
Пытаетесь повторно вкачать смену, которая уже есть в "информации об общих сменах". Сервер говорит: такое у меня уже есть, делать ничего не буду.
Приветствую. У меня случилось обновление и я решил обрезать базы на этот год.
При обновлении R-Keeper до 7.6.0.64 была создана чистая SQL-база, перемещены с целью пересоздания check_db.udb в папке Сервера Отчетов и check.udb в папке Сервера Справочников. При подключении новой базы были установлены опции "Экспортировать справочники" и "Только структура". Теперь последние данные (вчерашние за 29.05.2018) в базу и отчеты сели, а предыдущие после копирования с ftp в папку incoming пропадают, но не появляются в Общих Сменах и не видно в отчетах. В логе сервера отчетов почему-то такая запись присутствует:
Подскажите почему он считает, что выгрузка по смене уже есть в базе.
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot