УТ: Медленно проводятся документы #210494

Загрузил в одинэсину (v8 для SQL, 8.0.16.2, УТ 10.2.10.2) порядка 130 тыс. документов (всего ок. 2 млн. строк) в порядке теста (грузил по ADO собственной обработкой из сиквельной базы совершенно другой программы). Загрузку делал без проведения (чтобы побыстрее), доки "Поступление товаров и услуг" и "Счет-фактура полученный". Теперь пытаюсь провести эти доки через меню "Операции" - "Проведение документов..." (т.е. средствами платформы). Очень уж долго! Запустил в пятницу днём, сейчас (утро понедельник) по дате в строке состояния вижу, что проведена примерно пятая часть(!) доков. (Проведение запущено на самом сервере, где стоят и 2005 сиквел, и сервер приложений 1С.) Что я делаю неправильно? Или так и должно быть?

отключи RLS

Что это?

что-то типа настроек прав доступа. В поиск: форум, КЗ, БЗ, СП и т.д.

А подсказать можешь чуть поконкретнее? В базе единственный пользователь с административными правами, никаких специальных настроек я не делал. "Отключить RLS" - это значит менять конфигурацию (конфигурация на данный момент нетронута)?

Есть подозрение, что торможение в УТ от RLS, поэтому и дал тебе такой совет. А изменять конфигу или не решать тебе.

А как предлагаешь изменять конфигу? Выгрызать все RLS запросы отовсюду напрочь?

размышляю сейчас над тем же вопросом в БП доразмышлялся уже до того, что сделал свой регистр остатков, с минимумом измерений, причём измерения тоже очень специфичные: код товара (!!!) ставка НДС (числом !!!), ресурсы - количество и сумма. В общем стало довольно быстро, но этого всё равно мало - придётся взаиморасчёты тоже переписывать :(

И играет ли вообще роль RLS, если в базе единственный пользователь с административными правами?

А что за сервер-то? Может там машина, которую и под клиента не поставишь-то...

Сервер нормальный вроде. System Information показывает 4 проца по 3000 МГц, 4 Гига оперативки. Система, ldf-ы и mdf-ы каждый на своём физическом диске (3 физических диска).

Короче, УТ с такими объёмами данных можно выкинуть на помойку, я правильно понял?

Всё же хотелось бы получить ответ на ...

если вводить документы не пакетами, а в реальном времени - ещё поживёт ИМХО не играет

отключить RLS, контроль остатков(при условии что доки правильные.)

А проведение по партиям как? Как-то стрёмно... Имхо, проведение по партиям жить не будет.

Как его отключать то??

от партий вообще имеет смысл отказаться

нафига их вообще придумали эти партии. Надо было сделать опционное отключение

это почему же не будет) будет) бе:-) и потом пиши отчёт чего продалось из этого (конкретного)прихода.. без партий:)

отказаться от таких отчётов !

аха:) я бы с радостью.. они ж всё равно - фикция.. (в зависимости от метода списания)

согласен. Когда частота поставок каждый день да по три вагона, кого волнует из какой там партии был товар. А как продавался мы и так увидим. Опять же здесь специфика учета для конкретного вида товаров. Дак вот кому партии не нужны надо было бы сделать возможность отключать ведение по партиям

бугага.. в настройках парамтров учёта не пробовал копаться?

Можно отключить в Учетной политики, списывать партии при проведении, и из 10 регистров Расходная накладная будет проводиться по 6-ти

а толку то. Ну не будет списываться товар из партии, зато эту регламентированную операцию надо будет делать как советует разработчик периодически с необходимой частотой. И остатки всё равно по приходу будут болтаться по регистрам даже если этого и не делать

это я про Проведение документов по партиям

ну а потом берёшь бензопилу и усё остальное нах.. мне вот только не охота потом писать километровой длины запросы в отчётах..

Вести учёт по средней то бишь? Это не прокатит, к сожалению... Один цэ как была программа для ларьков, так и осталась. Тьху...

да ладно чё ты. Ну оставим партии, тока если ИМХО надо что бы быстее провелось пусть отключит проведение по партиям в учетной политике, только всё равно это действие придётся выполнить. ну про ларьки ты погорячился. Сразу всех так подобосрал малёхо

А чё погорячился? С большими объёмами данных-то кирдык получается... Да и объёмы особо большими не назовёшь (это только приходы, причём не все). Если добавить остальные доки (приём на комиссию, продажи, переоценки) - объём базы можно будет умножить на 10. Тогда точно кирдык. Не знаю, может на самописках и можно сделать, но УТ похоже не катит. Да и на самописках вопрос (можно ли при таких объёмах FIFO посчитать на 1С в принципе - бааальшой вопрос).

при небольшом объёме кода, при отказе от GUID идентификаторов - 1С не будет отличаться от любой другой среды программирования. На крайняк можно и от штатной системы промежуточных итогов отказаться. так что если где-нибудь можно, то и в 1С можно - вопрос только в цене

Вопрос в применении типовых конфиг, прежде всего. Писать самописку для серьёзного торгового учёта - да, наверное, можно... Но это дороговато и уходит много преимуществ (цена разработки и внедрения + подсаживание на иглу разработчика, т.е. всё получается как обычно с другими программами, и нет большого смысла выбирать 1С). А типовые конфиги - всё же для ларьков, получается.