L_KATORG
Краткое описание :
Некорректно работает выбор организацийОписание :
Аналитический учетЧто измененно :
Некорректно работает выбор организаций.
Формируем отчет, по счету ведется системная аналитика Организации, хотим выбрать нужные нам,открывается выбор по контрагентам, по умолчанию в настройках установлено отображение только Рабочих контрагентов.
В списке контрагентов они разбиты на несколько групп, становимся на нужную, нажимаем Insert помечается пака и все вложенные рабочие контрагенты, нажимаем ввод.
Но при этом почему-то в фильтр и в шапку отчета, соответственно, попадают организации, которые относятся к данной группе, но находятся в архиве.
Клиент утверждает, что ранее помечались и попадали в фильтр только те рабочие организации, которые отражались в интерфейсе выбора.
Как измененно :
Исправлено.
Также учитывается фильтр по стране и городу, если есть
L_KATORG
Краткое описание :
Модифицируются лишние МЦ при редактировании Справочника ОКДП2Описание :
Каталог МЦЧто измененно :
Создаем новую мц МЦ_1. Поле "Код ТНВЭД" (KATMC.TNVED) не заполняем.
Создаем новую мц МЦ_2. Становимся в поле "Код ОКПД2", жмем F3, попадаем в интерфейс L_KATORG::GETOKDP. Далее создаем новую запись. Если в ней заполнить поле ТНВЭД, то в МЦ_1 поле KATMC.TNVED заполнится этим же значением.
Такого быть не должно.
Т.е. если мы создаем в каталоге кодов ОКПД2 новую запись и присваиваем ей поле ТНВЭД, то во всех МЦ, где не заполнен код ТВНЭД происходит апдэйт поля KATMC.TNVED.
И вообще, зачем апдэйтить все МЦ, у которых код ТНВЭД совпадает с кодом ТНВЭД редактируемой в данный момент записи ОКДП2? Может быть лучше апдэйтить только те МЦ, которые ссылаются на редактируемый ОКДП2?
Как измененно :
Исправлено заполнение ТНВЭД в МЦ, если они не заданы при создании новой записи в каталоге ОКДП
L_KATORG
Краткое описание :
C 01.07.2018 ЦБ РФ вводит новый формат распространения справочника БИК 595-ПОписание :
Импорт каталога банковЧто измененно :
C 01.07.2018 ЦБ РФ вводит новый формат распространения справочника БИК
Формат DBF будет поддерживаться до конца года.
Необходимо реализовать импорт.
Как измененно :
ФРО-настройка-импорт каталога банков.
Реализован импорт справочника БИК с сайта ЦБРФ в формате XML.
Поля, для которых реализован перенос данных:
-Бик
-ОГРН
-Наименование
-Индекс
-Название населенного пункта
-Адрес
-Корр. счет.
По умолчанию загружается интерфейс для обработки данных с 01.01.2019.
В локальном меню есть возможность переключения для загрузки данных из формата DBF до 31.12.2018.
L_KATORG
Краткое описание :
(ВАН) Количество Parse превышает количество ExecutionsОписание :
Не знаю, какая именно часть контура логистики, научитеЧто измененно :
Количество Parse превышает количество Executions
На основании awrrpt_1_43763_43764.html от 28-Dec-18 11:00 за 1 час работы на первой ноде.
Модуль: atlexec.exe
Запрос
SELECT COUNT(ROWID) FROM GAL_VEK."KONTRIER"
Описание
Количество Parse Calls составляет 25 тысяч раз. При этом количество выполнений этого запроса всего 1300 раз.
Либо разработчики парсят запрос, а на выполнение не запускают, либо выполнение идет с использованием parallel query. Таблица имеет degree = 1, а все индексы имеют degree = 30. Очевидно, что count считается по одному из индексов построенных по not null полям.
Рекомендация для Асконы
Запрос выполняется 7 раз в секунду в течение часа. В таблице 6 миллионов записей. Этот запрос делает избыточную и ни кому не нужную нагрузку на диски.
Обратите внимание, parallel query ВСЕГДА читает с диска игнорирую buffer pool.
Для облегчения ситуации таблица ранее была уже сжата методом BASIC. Рекомендую пересжать ее методом OLTP.
Для этого выполните fix_kontrier.sql
Это снизит размер таблицы на 30%, соответственно дисковые чтения снизятся также.
Рекомендация для разработчиков
Данный запрос выполняется 7 раз каждую секунду. Действительно ли необходимо так часто подсчитывать количество записей в таблице в которой 6 миллионов записей?
Пожалуйста, рассмотрите возможность кеширования данного вычисления на клиенте, чтобы этого не происходило 7 раз в секунду в течение часа.
При указании хинтовне забудьте, что parallel query это всегда дисковые чтения. Это всегда на тестовом окружении показывает хороший результат на секундомере, а на продуктивной БД будет просто "убивать" дисковую подсистему и тормозить расчет других задач выполняемых на этом сервере в это время.
Рассмотрите отказ от parallel query для этого запроса - подсчет count все-равно идет по индексу, он может быть в кэше и расчет будет выполняться гораздо быстрее без parallel query. Но это верно только для продуктива. На тесте секундомер покажет обратный результат, так как на тесте мало кто работает и там пустой кеш.
PS.Вариант, при котором вы парсите запрос, но не выполняете его - не рассматриваю, как маловероятный.
Как измененно :
Изменен алгоритм определения наличия записей в таблице с RecordsInTable на RecordExists