Коллеги! Предлагаю обсудить модуль «Управление запасами»

Подсчитал. У нас среднее количество строк в SC07 за день — ок. 5200.

Разумеется, для большого количества клиентов Скалы это ничто, хотя, очевидно, что 5200 — это «средняя температура по больнице», как в таких случаях говорится, реальные данные имеют разброс от 1 до 78000 строк в день.

Однако, на мой взгляд, количество проводок в день совершенно не должно быть реальным ориентиром для оценки производительности, в лучшем случае, неким косвенным показателем. На скорость работы может также влиять количество записей в таблице партий (SC33), в таблице позиций запасов (SC01), а также даже в таблице курсов валют. Могу согласиться, что система часто обрабатывает массивы данных внутри программы, совершенно неоптимальным способом, однако, вполне возможно, что можно проделать некие действия, способные улучшить ситуацию. Имея под 300 внешних пользовательских отчетов, мы недавно вынуждены были откорректировать все запросы, используемые для построения этих отчетов, разрешив так называемое «Грязное чтение» с помошью добавления в текст запроса «(NOLOCK)», например,

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

Ну отчего же… Просто, возможно, для Вас она не слишком подходит, Вам, возможно, требуется некая функциональность, которая в Скале отсутствует, как написано ниже:

Насколько я предполагаю, что при использовании «Коньюктивита», что при обычном импорте проводок, логика следующая: Скала обрабатывает весь массив данных построчно, как, если бы это было введено в систему «вручную».
Происходит это примерно так (порядок условный, я не претендую на то, что Скала делает именно так, как я описываю):
1. Проверяется наличие кода запаса, склада, партии, учетных измерений и т.п.
2. Создается проводка, корректируется или создается новая партия, корректируется информация по складам, статистика по запасу и т.п.

И при этом я не уверен, что производится это оптимальным образом, т.к. многократно замечал (особенно при работе с модулем Управления Производством), что программа хватает полный массив данных, и уже внутри крутит его перебором, посылая отдельные запросы к SQL серверу вместо одного запроса с грамотно наложенными ограничениями в WHERE или с корректно построенными взаимосвязями между таблицами в виде JOIN

Проделав все это, система берется за следующую строку и цикл повторяется.

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

Это новая штука, но остальное-то старое, т.е. проводки по запасам все равно создаются в соответствии со старой методикой. Может быть я ошибаюсь, но Connectivity — это просто «надстройка», возможность «запихивания» данных не с помощью «ручного» импорта данных, а более приемлемым автоматическим способом, без участия оператора. При этом, насколько я полагаю, в определенный момент все равно используется тот же самый инклюдник (кусок кода), что и в определенный момент ручного ввода проводок. Т.е., как бы имеются 2 разные двери, которые разными коридорами (новым, с евроремонтом и старым, слегка потертым) все равно приводят в конечном итоге в одну комнату в старом здании.

Paul77 писал(а):

Да, но старый-то способ почти на порядок быстрее

Ну, так новый коридор-то в 3 раза длиннее

У нас в таблице SC07 сейчас ок. 5 млн. записей, прирост в среднем ок. 7000, максимум 13000 записей.

Год назад со скоростью Скалы также были серьезные проблемы, помимо того, что купили новый более мощный сервер, пришли к таким выводам: во-первых, как рекомендует aav, всегда используем в «читающих» внешних отчетах хинт nolock, в особеннности для больших таблиц модуля управления запасами. До этого неоднократно наблюдали ситуацию, что все пользователи просто подвисают в Скале, пока обрабатывается какой-нибудь внешний отчет, использующий, например, SC07. Такие отчеты отловили с помощью такого скрипта (запускаем, когда пользователи начинают звонить, что они зависли):

Во-вторых, оптимизировали несколько тяжелых запросов во «внешних» программах, которые хоть и внешние (используеют только скальскую базу), но на скорость Скалы, тем не менее влияют, попросту загружая сервер или блокируя, используемые Скалой таблицы, а она, бедняжка, их ждет, а ее в это время ругают
Специалисты рекомендуют регулярно составлять топ 100 самых медленно выполняющихся запросов (через профайлер), таким образом можно обнаружить массу интересного, как мы в свое время, например

Поделитесь опытом: насколько реально настроить Connectivity таким образом, чтобы при совершении определенного действия вне Скалы информация, например, об отгрузке по заказу на продажу, попадала в Скалу в течение 0.5-1-2-3 минут? Я в данном случае не веду речь про те проблемы, что Вы описываете — с медленностью самого процесса обработки большого количества строк, предположим, что этих самых строк одномоментно не больше 10. Сможет ли оператор распечатать накладную из Скалы через 2 минуты после того, как нажмет кнопку, формирующую входную информацию для этого самого коннективити? Что показывает практика? Поделитесь своим опытом с учетом того, что большинство из нас в отношении «коньюктивита» — «чайники»