Каталог решений - Оптимизация регистров оперативного учета на работающей базе . v77

Оптимизация регистров оперативного учета на работающей базе . v77

Оптимизация регистров оперативного учета на работающей базе . v77

В наличии

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

Категория:

Описание

 Столкнулся с исторически спроектированной базой.

 У семи нянек, как известно, четырнадцать взглядов на развитие бизнеса.
Взялся в середине года за торговую фирму. И впервые увидел не просто «улучшенную» стандартную конфигруацию, а исключительно глубоко улучшенную. Диагноз поставил практически сразу-
закопать нельзя лечить. Однако с запятой возникли проблемы. Конфига конечно исключительная. Но ведь худо-бедно работает. Торговый процесс идет. Прикручено две системы кармнных компьютеров. Значит, все-таки сначала лечить, подготовится к переходу на что-нибудь, и только потом закопать.
 Т.е. лечение должно быть малобюджетное  и эффективное, чтобы дотянула программуля до конца года.
 оказалось, что основные тормоза возникали из-за ошибок в проектировании регистров. Один регистр
«учет» содержал пять(!) лишних измерений, которые не закрывались на конец периода  (1) . После пробега по отчетам, документам и живым сотрудникам компании выяснилось, что надо убрать запятые в двух местах (регистр.сводныйОстаток()) — и все(!!!), можно [было бы] удалять лишние измерения.
 Но в отчетах они используются. К счастью, язык запросов не делает синтаксической разницы между измерением и реквизитом. Отсюда решение — надо перекинуть измерения в реквизиты.
 Сработало. База взлетела, кроме тормозов — ничего не потеряла. Через неделю — к новому году -закопаем.:)
 
 На всякий случай напомню, как сделать измерение реквизтом.

1) В конфигураторе создаем реквизит больного регистра
  В моем случае «Регистр.Учет» имеет измерение «маршрут» тип=»справочник»
 создаю реквизит маршрут0 того же типа.
2) сохраняю конфигурацию.
3)  Если есть 1с++ тогда запускаем:

ЗагрузитьВнешнююКомпоненту(«1cpp.dll»);

Рекордсет=СОздатьОБъект(«ODBCRecordset»);

Рекордсет.ВыполнитьСкалярный(«Update $Регистр.Учет  set $Регистр.Учет.Маршрут0=$Регистр.Учет.Маршрут «);

//Если нет 1с++ тогда по .dds надо выковыривать названия таблиц и подставлять в запрос QA.

4)Удаляем измерение «маршрут»

5)Переименовываем реквизит «маршрут0» в «маршрут».

6)сохраняем.

7) Запускаем в Конфигураторе  «пересчет итогов».

зы.Не забываем бэкапится.

 ЗЫЗЫ Абсолютно замечательная статья по прямым запросам 1с++.

http://www.1cpp.ru/forumfiles/Attachments/mod_002.zip

 Там, в том числе разбирается подключение к ДБФ.

 

 

 

 Примечание 1.

В 2-х словах на том же примере:

Имеем:

 Регистр «Учет» измерения «Товар»,»Склад»,»Маршрут»

 ресурс:»Остаток»

Реквизитов не было.

Приходный документ приходует 1шт Остатка  движениеПриходВыполнить() по Товару и Складу.

расходный документ списывает 1шт Остатка движениеРасходВыполнить() по Товару,Складу и Маршруту

 В результате в таблице итогов (RGххх) остается запись «Товар,Склад,Маршрут,-1шт». Поскольку маршрут на приходе всегда пустой — эта запись никогда не обнулится. А таблица итогов каждый конец периода итогов (обычно месяц) складывает все ненулевые ресурсы по измерениям и переносит их на следующий период итогов. То есть наша запись будет присутствовать во ВСЕХ последующих итогах.

Проверить наличие таких хвостов очень просто,например — Тз=0;Рег.ВыгрузитьИтоги(ТЗ);Тз.ВыбратьСТроку();

 В ТиС обычно висят хвосты по Покупатели-Поставщики. Но там таким способом лучше не бороться.

 

has been added to your cart:
Оформление заказа