Добрый день коллеги!
Есть розничная аптека, платформа 1С: Предприятие 8.1 (8.1.15.14), Розница 8. Аптека, редакция 1.0 (1.0.14.3). База данных распределенная, 5 аптек.
Они делают поступление товаров из программки под названием СКЛИТ через DBF файлик. Так вот сверка с номенклатурой идет по наименованию товара, так как того же артикула в dbf нет. За счет чего база постоянно растет и пухнет за два года уже 8 ГБ. Мой вариант постоянный, постепенный и регулярный поиск и замена элементов дублирующихся элементов справочника через стандартную обработку (их там 1950 позиций) да, это долго, но другого выхода я не вижу, и на просторах интернета не нашел.
Они от меня хотят, чтобы я нажал кнопочку и все заработало.
Кто и что может мне посоветовать? Так как у меня опыта еще не много, я обращаюсь за помощью к вам, более опытным товарищам. Буду рад любым советам и подсказкам.
Есть розничная аптека, платформа 1С: Предприятие 8.1 (8.1.15.14), Розница 8. Аптека, редакция 1.0 (1.0.14.3). База данных распределенная, 5 аптек.
Они делают поступление товаров из программки под названием СКЛИТ через DBF файлик. Так вот сверка с номенклатурой идет по наименованию товара, так как того же артикула в dbf нет. За счет чего база постоянно растет и пухнет за два года уже 8 ГБ. Мой вариант постоянный, постепенный и регулярный поиск и замена элементов дублирующихся элементов справочника через стандартную обработку (их там 1950 позиций) да, это долго, но другого выхода я не вижу, и на просторах интернета не нашел.
Они от меня хотят, чтобы я нажал кнопочку и все заработало.
Кто и что может мне посоветовать? Так как у меня опыта еще не много, я обращаюсь за помощью к вам, более опытным товарищам. Буду рад любым советам и подсказкам.
По теме из базы знаний
- Видеокурс "Легкий и быстрый способ обучиться работе с 1С:Управление Торговлей (ред 11.3)"
- hsИнтегратор - технология онлайнового обмена данными между базами на платформе 1С:Предприятие. Использование технологии в виде расширения, без изменения конфигураций баз данных, участвующих в обмене
- Базы данных. Несколько шагов до серьезного обслуживания
- Как система обмена данными помогает решить нетривиальные задачи, характерные для терабайтных баз: обрезка, обслуживание, балансировка нагрузки и другие
- Методология логирования промежуточного этапа, или Ну давайте перестанем хранить уже логи в 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) shutniksasha, если в ДБФ файле есть колонка артикул, или штрихкод, то можно попробовать сделать сопоставление номенклауры при загрузке данных по этому артикулу или штрихкоду. у нас в базе было сделано именно так, чтобы не разростался справочник номенклатуры. Загрузчик проверяет есть ли номенклатура с подобным ШК в базе, и если есть не создаёт новую, а использует уже имеющуюся. Весь вопрос заключается в том будут ли корректные данные в исходном ДБФ файле, из которого происходит загрузка в базу.
Не очень понятно, за счет чего пухнет база. Если поиск идет по наименованию товара, то обработка ищет товар с таким наименованием и успокаивается. Если наименования нет, то очевидно, она создает его. Но это создание происходит один раз.
(7) peterxx, Документы / Поступление / Поступление товаров / Новый / Сервис / Заполнить из файла / Выбираем настройку / Далее / Сверяет по наименованию... Вот скрин самой настройки:
Из вариантов искать по:
Наименование
Код
Артикул
Единый государственный классификатор лекарственных средств
ШтрихКод...
Из вариантов искать по:
Наименование
Код
Артикул
Единый государственный классификатор лекарственных средств
ШтрихКод...
Есть одно предположение, которое нуждается в проверке:
Сначала данные из внешнего источника загружаются в табличный документ. Далее этот табличный документ обходится и для поиска номенклатуры формируется запрос (строка 1379 модуля объекта):
В вашем случае СтрокаПоиска.ИмяРеквизита - это "Наименование", МетаданныеИсточника.Имя - "Номенклатура"
Далее (строка 1446) появляется строка установки параметров:
И, как мне кажется, здесь засада: если в табличном документе считанное из файла наименование: "Аспирин ", а в справочнике "Номенклатура" - "Аспирин", то результат запроса будет пустой. Я бы попробовал заменить строку на следующую:
Сначала данные из внешнего источника загружаются в табличный документ. Далее этот табличный документ обходится и для поиска номенклатуры формируется запрос (строка 1379 модуля объекта):
ТекстЗапроса =
"Выбрать Первые 1
|Справочник.Ссылка КАК Ссылка
|Из Справочник."+МетаданныеИсточника.Имя+" КАК Справочник
|Где";
Для каждого СтрокаПоиска Из СтрокиПоиска Цикл
ТекстЗапроса = ТекстЗапроса +"
|Справочник."+СтрокаПоиска.ИмяРеквизита+" = &" + СтрокаПоиска.ИмяРеквизита + "
|И";
КонецЦикла;
ТекстЗапроса = Лев(ТекстЗапроса,СтрДлина(ТекстЗапроса) - 2);
Запрос = Новый Запрос (ТекстЗапроса);
ПоказатьВ вашем случае СтрокаПоиска.ИмяРеквизита - это "Наименование", МетаданныеИсточника.Имя - "Номенклатура"
Далее (строка 1446) появляется строка установки параметров:
Запрос.УстановитьПараметр(СтрокаПоиска.ИмяРеквизита,ТекущаяСтрока[СтрокаПоиска.ИмяРеквизита]);
И, как мне кажется, здесь засада: если в табличном документе считанное из файла наименование: "Аспирин ", а в справочнике "Номенклатура" - "Аспирин", то результат запроса будет пустой. Я бы попробовал заменить строку на следующую:
Если ТипЗнч(ТекущаяСтрока[СтрокаПоиска.ИмяРеквизита]) = Тип("Строка") Тогда
Запрос.УстановитьПараметр(СтрокаПоиска.ИмяРеквизита,СокрП(ТекущаяСтрока[СтрокаПоиска.ИмяРеквизита]));
Иначе
Запрос.УстановитьПараметр(СтрокаПоиска.ИмяРеквизита,ТекущаяСтрока[СтрокаПоиска.ИмяРеквизита]);
КонецЕсли;
(20) peterxx, благодарю!!! Проверка соответствия стала работать значительно лучше.
Еще один вопрос. Как можно более эффективно уменьшить размер базы данных. Стандартной обработкой поиска и замены очень долго. Возможно Вам встречались более эффективные варианты?
Еще один вопрос. Как можно более эффективно уменьшить размер базы данных. Стандартной обработкой поиска и замены очень долго. Возможно Вам встречались более эффективные варианты?
(21) shutniksasha, прошу прощения за долгое молчание, отсутствовал.
Как бы я стал действовать в вашем случае: модифицировал бы обработку "ПоискИЗаменаЗначений", написал бы процедуру программного заполнения табличной части "ЗаменяемыеЗначения" (если речь идет об устранении дубликатов номенклатуры), перенес бы в модуль объекта процедуры поиска ссылок и замены значений и процедурой верхнего уровня запустил бы всё скажем на ночь или на выходные.
Как бы я стал действовать в вашем случае: модифицировал бы обработку "ПоискИЗаменаЗначений", написал бы процедуру программного заполнения табличной части "ЗаменяемыеЗначения" (если речь идет об устранении дубликатов номенклатуры), перенес бы в модуль объекта процедуры поиска ссылок и замены значений и процедурой верхнего уровня запустил бы всё скажем на ночь или на выходные.
(23) peterxx, (22) mixa4, благодарю за советы, все выходные с ней мучился, вот что получается...
Протестировав базу данных наткнулся на следующее:
При тестировании и исправлении (ТИИ) база резко начинала расти и в итоге выбивала ошибку "не достаточно памяти" на следующих независимых регистрах сведений: ПрайсЛистыКонтрагентов, СоответствиеОбъектовДляОбмена.
Вычистив их процесс исправления пошел дальше, но споткнулся на регистре накопления РазмещениеЗаказов
(В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2622_TYPE'
по причине:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2622_TYPE')
, но с ним дело уже посложнее, так как он регистрирует движения по нескольким документам:
ВнутреннийЗаказ
ЗаказПоставщику
ЗакрытиеЗаказовПокупателей
ПеремещениеТоваров
ПоступлениеТоваров
В этом направлении копаю сейчас.
Тестирую утилиткой chdbfl...
Протестировав базу данных наткнулся на следующее:
При тестировании и исправлении (ТИИ) база резко начинала расти и в итоге выбивала ошибку "не достаточно памяти" на следующих независимых регистрах сведений: ПрайсЛистыКонтрагентов, СоответствиеОбъектовДляОбмена.
Вычистив их процесс исправления пошел дальше, но споткнулся на регистре накопления РазмещениеЗаказов
(В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2622_TYPE'
по причине:
Ошибка SQL: Запись значения NULL в поле, не допускающее NULL '_FLD2622_TYPE')
, но с ним дело уже посложнее, так как он регистрирует движения по нескольким документам:
ВнутреннийЗаказ
ЗаказПоставщику
ЗакрытиеЗаказовПокупателей
ПеремещениеТоваров
ПоступлениеТоваров
В этом направлении копаю сейчас.
Тестирую утилиткой chdbfl...
1950 номенклатуры это не много, так что для начала надо все же по-точнее выяснить от чего пухнет база.
Выяснять это путем анализа кода - пожалуй, не самый оптимальный вариант. Есть база, гляньте что в ней нанимает основной объем, например, с помощью Tool_1CD, или посмотрев размер выгрузки отдельных объектов, или хотя бы кодом - пройтись по метаданным и вывести количество объектов каждого вида.
Выяснять это путем анализа кода - пожалуй, не самый оптимальный вариант. Есть база, гляньте что в ней нанимает основной объем, например, с помощью Tool_1CD, или посмотрев размер выгрузки отдельных объектов, или хотя бы кодом - пройтись по метаданным и вывести количество объектов каждого вида.
В общем проблема с нереальным размером базы данных решилась при помощи стандартной утилитки chdbfl и чистки независимых реестров ПрайсЛистыКонтрагентов и СоответствиеОбъектовДляОбмена. Тестирование и исправление через конфигуратор в разных вариантах не помогло. База только увеличивала свой размер.
Итог: база весом в 3.1 Гб.
Итог: база весом в 3.1 Гб.
Если у тебя был заполнен регистр СоответствиеОбъектовДляОбмена значит кроме распределенной базы у тебя есть обмен с "другой конфигурацией" (возможно это управляющая система на конфигурации Управление Торговлей или выгрзка данных в "Бухгалтерию"). Лучше сначала узнать с какой конфигурацией идет обмен, а потом удаляй данные.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот