Коллеги, столкнулся с проблемой при использовании функции "суммпроизв" - комп виснет намертво минут на 10 при перерасчёте (комп слабый, массив данных большой, да ещё и в сети расположенный). Маленький кусочек печали в приложении, суть которого в целом сводится к следующему.
Дано: 1. мой файл с неменяющимся перечнем позиций. 2. Постоянно обновляющаяся база данных, содержащая бесчисленное множество различных позиций в различной кондиции и статусе Нужно: 1. подсчитать к-во вышедших из строя позиций (колонка UNSERV, в бд соотв-ет кондиции U/S) и количество исправных (колонка серв SERV, в бд соотв-ет кондиции FN, NEW, NS и тд.), причем только имеющихся на складе (т.е. статусы IN-STOCK и RETURNED) Итог: Формула "суммпроизв", вешающая комп намертво в виду слабых ТТХ. Помогите понять, можно её как-либо оптимизировать или найти ей какую-либо альтернативу, которая не вешала бы ПК так сильно? Спасибо.
Коллеги, столкнулся с проблемой при использовании функции "суммпроизв" - комп виснет намертво минут на 10 при перерасчёте (комп слабый, массив данных большой, да ещё и в сети расположенный). Маленький кусочек печали в приложении, суть которого в целом сводится к следующему.
Дано: 1. мой файл с неменяющимся перечнем позиций. 2. Постоянно обновляющаяся база данных, содержащая бесчисленное множество различных позиций в различной кондиции и статусе Нужно: 1. подсчитать к-во вышедших из строя позиций (колонка UNSERV, в бд соотв-ет кондиции U/S) и количество исправных (колонка серв SERV, в бд соотв-ет кондиции FN, NEW, NS и тд.), причем только имеющихся на складе (т.е. статусы IN-STOCK и RETURNED) Итог: Формула "суммпроизв", вешающая комп намертво в виду слабых ТТХ. Помогите понять, можно её как-либо оптимизировать или найти ей какую-либо альтернативу, которая не вешала бы ПК так сильно? Спасибо.Denny
Вот ёлки ж палки - всё гениальное просто! И как сам не додумался... ) Спасибо за идею! Единственное - будет ли диапазон исходных данных ( в файле с БД) расширяться автомоматом? Туда ж практически ежедневно-часно-минутно добавляются новые строки. Просто доселе сводные обычно делал статичным массивам, а тут он динмаический, какбе, получается.
Вот ёлки ж палки - всё гениальное просто! И как сам не додумался... ) Спасибо за идею! Единственное - будет ли диапазон исходных данных ( в файле с БД) расширяться автомоматом? Туда ж практически ежедневно-часно-минутно добавляются новые строки. Просто доселе сводные обычно делал статичным массивам, а тут он динмаический, какбе, получается.Denny
Сообщение отредактировал Denny - Четверг, 17.10.2013, 19:46
Ешчо раз глянул, покумекал, попробовал переварить идею со сводными. В бд в столбце part_number уникальных позиций - под пару тысяч, из которых в отчёте мне нужны только 150 (в примере в отчёте только 2 позиции для упрощения, третья, та что 15-1350-H40 в бд - в отчёте лишняя)...Т.е., если прибегнуть к варианту со сводной таблицей, по логике, придётся фильтровать 150 нужных для отчёта позиций из 2000 уникальных, содержащихся в бд.
Т.е. изначально предполагалось, что формула должна по столбцу p/n отчёта сверяться со столбцом part_number в бд, и считать кол-во строк в бд, удовлетворяющих 2-м условиям - статус (Returned ИЛИ in-stock из стобца status в бд) И состояние (для 1-й колонки отчёта - только "U/S" из стобца condition в бд, для 2-й колонки отчёта - "FN" либо "NEW" либо "NS" либо др. помеченные зеленым в списке всех возможных значений данной колонки бд).
Ешчо раз глянул, покумекал, попробовал переварить идею со сводными. В бд в столбце part_number уникальных позиций - под пару тысяч, из которых в отчёте мне нужны только 150 (в примере в отчёте только 2 позиции для упрощения, третья, та что 15-1350-H40 в бд - в отчёте лишняя)...Т.е., если прибегнуть к варианту со сводной таблицей, по логике, придётся фильтровать 150 нужных для отчёта позиций из 2000 уникальных, содержащихся в бд.
Т.е. изначально предполагалось, что формула должна по столбцу p/n отчёта сверяться со столбцом part_number в бд, и считать кол-во строк в бд, удовлетворяющих 2-м условиям - статус (Returned ИЛИ in-stock из стобца status в бд) И состояние (для 1-й колонки отчёта - только "U/S" из стобца condition в бд, для 2-й колонки отчёта - "FN" либо "NEW" либо "NS" либо др. помеченные зеленым в списке всех возможных значений данной колонки бд).Denny