Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
25.04.2018, 22:16
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Уважаемые единомышленники, всем привет! Предстоит небольшой проект, где необходимо будет на уровне табличной формы тащить итоговые значения из подчинённой вложенной табличной формы. На уровне главной формы должно быть порядка 9-10 расчетных полей. Как организовать при помощи DlookUp ,DCount и прочих вбашных агрегатных функций я естественно знаю, это легко. Но по прошлым проектам вижу, что при большом количестве записей в основной табличной форме,и при наличии агрегатных функции форма начинает подтупливаить. В год вижу на уровне главной табличной формы порядка 5000 записей при 30 полях (все типы,в основном текст, дробные числа и даты),из них 9-10 расчетных. (Источником данных будет запрос.) Подскажите пожалуйста, есть ли более быстрые и менее требовательные к ресурсам замены агрегатным функциям vba? Запросы с группировкой с выводом в расчетное поле прошу не предлагать, так как при этом теряется возможность редактировать инфо на уровне главной табличной формы. Я пробовал ухищряться и писал отдельными функциями vba выражения ,куда пихал текст запросов с группировкой и только потом выводил в расчетные поля в виде значения функции ,но это тоже приводило к существенным замедлениям при большом количестве строк. Есть ли возможность обойти этот порочный круг?) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
25.04.2018, 22:32
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Сергей ЛаловDlookUpopenrecordset ? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
25.04.2018, 22:37
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Прогер_самоучкаСергей ЛаловDlookUpopenrecordset ? Пробовал, такая же глюконавтика) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
25.04.2018, 22:49
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Сергей Лалов, Мне кажется мало чего выкроишь, но рыться возможно придется таки там где не хочется... Сергей ЛаловЗапросы с группировкой с выводом в расчетное поле прошу не предлагать, так как при этом теряется возможность редактировать инфо на уровне главной табличной формы. ничто не мешает сделать или в заголовке этой формы или во всплывающей форме или в еще главней форме отвязанные поля, в которых и можно будет делать корректировку... смотря конечно какие масштабы корректировки.... так-то вполне нормально когда в этих полях отображаются значения текущей записи и есть возможность изменения этих значений, ну и реквери потом соответственно с возвратом указателя на прежнее место... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.04.2018, 07:53
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Если не требуется постоянный пересчет итоговых данных на главной форме, то можно агрегатными запросами вытаскивать данные в промежуточную таблицу и ее уже использовать в главной форме, сохраняя ее редактируемость. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.04.2018, 09:38
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Сергей Лаловна уровне табличной формы тащить итоговые значения из подчинённой вложенной табличной формы. Т.е. у вашей формы есть субформа? Тогда что вам мешает создать в ней расчетные итоговые поля (с Sum(), Count() и т.п.) и обращаться к ним из главной? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
02.05.2018, 19:26
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Кривцов Анатолий, Нет, так будет тормозить. У меня опыт показа на подформе нарастающего итога по 2м полям + итоговые поля из подчиненной формы для итогов по столбцам для главной. Как раз и спасся DSum() и DLast()-ми. Начало работать в разы быстрее... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.05.2018, 15:18
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Кривцов АнатолийСергей Лаловна уровне табличной формы тащить итоговые значения из подчинённой вложенной табличной формы. Т.е. у вашей формы есть субформа? Тогда что вам мешает создать в ней расчетные итоговые поля (с Sum(), Count() и т.п.) и обращаться к ним из главной? Это все одно, одно раздвоенное копытце из костылей) Игортан уже ответил. Такой вариант как ваш я также использовал. Прошу учесть, что главная форма - табличная. Есть выход, он стандартный, но эстетически и расово неудобный, на уровне главной табличной формы создать не расчетные, а обычные поля, и на действия в подчиненной выполнять добавление /изменение данных (к примеру запросом на обновление) в главную в эти поля. Действий больше конечно. Но в главной зато будут хранится статичные обычные данные в обычных полях, и постоянные вычисления Dsum(),DCount не будут грузить форму. Наверное так и сделаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.05.2018, 09:55
|
|||
---|---|---|---|
|
|||
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Удивительная весчь, на работе 2016 офис, прилепил порядка 7 расчетных полей с агрегатными функциями (DlookUp и пр..), при ~ 10000 строках, нормально все пошло. Не глючит. Видимо пересчитывается это на загрузку формы один раз, хранится в кэше, и потом при изменении данных в подчиненной форме меняется в определенной строке главной. Разница почему то между MS A2007 и MS 2016 чувствуется сильная при использовании этих функций. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.05.2018, 13:03
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Сергей Лалов, Мое мнение:dlookup("ctl","tbl","ctlN=3) ничем не отличается от "SELECT ctl FROM tbl WHERE ctlN=3" разве что dlookup возвращает первое найденное значение,а SELECT набор записей(при соответствии критерию единственной записи полная идентичность) а вот если в третьем аргументе применяется одна или несколько агрегатных функций то скорость значительно падает и морщить лоб надо по поводу структуры БД а не быстродействия функции (ну а в новых версиях ACCESS наверно увеличено общее быстродействие) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.05.2018, 13:20
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
sdkudlookup("ctl","tbl","ctlN=3) ничем не отличается от "SELECT ctl FROM tbl WHERE ctlN=3" разве чтоДля DLookup запрос выполняется каждый раз, когда требуется значение. На любой чих. А запрос вернул набор записей, закэшился - и успокоился до следующего явного или цепного обновления. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
11.05.2018, 14:42
|
|||
---|---|---|---|
DlookUp, DCount, Dmin итд, замена более быстрыми и менее требовательными аналогами |
|||
#18+
Akina, Я говорю о довольно простых случаях (например выбор цены из таблицы цен с использованием для дальнейших вычислений - больше "чихов" до следующих критериев,которые в запросе надо сменить и выполнить его, не предвидится) В подобных случаях измерение скорости выполнения процедуры с использованием Dlookup показывает предпочтительность функции (т.к выполнение до первого совпадения,а запрос перебирает все записи) + простота её использования в процедуре. Вообще все сильно зависит от конкретных целей и условий, а выбирать разработчику ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/moderation_log.php?user_name=%26lt%3Bfukfyl%26gt%3Bpth]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 440ms |
total: | 606ms |
0 / 0 |