DmT

Доброго всем времени суток!

Есть поле "Контрагент" тип DialogList c формулой отбора @DbColumn("":"NoCache";"C2257054:0022BD69";"Contr";1).
Т.е. у меня есть общая БД "Контагенты" из которой происходит выбор.

Вчера начались грабли, при попытке выбора выдается: "The specified database lookup generated more than 65,000 bytes of results, which is too large for Notes to handle in thys context."
Документов в представлении "Contr" - 2130 шт., каждый объемом в среднем 100 байт.

Как разрулить? Надеюсь что у вас были в практике такие случаи

@morphyus

1. NoCache - может не использовать?
2. хранить вложения отдельно

0

DmT

вложений в документах контрагентов нет. Там всего-то два поля текстовых. А NoCache щаз проверим...

UPD: удаление NoCache не повлияло на результат

@morphyus

эти текстовые поля где то в видах отображаються? есил нет, то поставить им флаг суммари - фальш

0

@Xotyt

а это разве не больше 65к? Что там в первом столбике у вас. На 65к средняя длинна не должна 30 символов превышать. Заменить дайлоглист на кнопочку с пиклистом каким и будет счастье.

0

DmT

ух ты! получилось! удалил пару длинючих названий - заработало. Про 30 символов слышу первый раз, это откуда?

@Xotyt

это 6500 / 2130



решение временное... добавится еще несколько доков и опять поломается.

0

DmT

добавил новый вид в котором первый столбец это количество символов в названии. Просуммировал его и получил 29 153 символа, если следовать вашей логике то это 29 153 байт. До 65000 как-бы далеко .... Или считать нужно не только первый столбец? А и второе поле? Тогда действительно цифра подкрадывается к 65000.

@Mydyvys

Если названия русские, то символ весит 2 байта.

0

DmT

спс. я туплю. СПАСИБО

@dushom

"Прямых" решений нет. Ограничение в лотусах существует и это неизбежное зло. Мало того это ограничение осталось даже в xPages на JSовском @Dbcolumnе \@Dblookupe (вот я был в шоке :ithx: ).
Cпособы решения в данной ситуации зависят от задачи и контекста, можно дать только общие рекомендации.
вот несколько наиболее распространенных:
1. не использовать в "поле "Контрагент" тип DialogList". делается просто поле, а значения выбираются по кнопке через PickList.
2. список из 2130 позиций мягко говоря бессмыленен, искать в нем сложно, листать долго, нужно точно помнить как контрагент определен в базе, что бы можно было по первым буквам хотя бы хоть как-то облегчить себе жисть. так что обычно контрагентов как-то делят на "категории" и перед выбором контрагента опрежеляется эта категория, а далее делается @DBLookup c учетом категории - выборка будет гораздо короче.
3. список состоит из усеченного названия, например "Рога и копы...", а далее через вертикальную черту "код документа" (например UNID) (cписок формируйте в колонке вида). в итоге, в поле контрагент будет "идентификатор" контрагента, а уже по этому идентификатору "лукапить" всю остальную необходимую информацию.

0

DmT

Спасибо за развернутый ответ! Теперь мне понятны рамки и перспективы.
БД Контрагенты у меня ведется ответственными пользователями уже несколько лет, и сейчас предстоит увеличение думаю на 25% за этот год. Поэтому надо думать .... Мне кажется второй вариант самое гибкое решение - трудность лишь в том, что сейчас "разбить" 2000 записей на группы это геморрой для пользователей, никто этим заниматься не будет.
Наверно буду писать агента: проходим по всем БД где используются контрагенты + по всем документам где есть привязка к категории (а таких большинство) и тянем эту категорию в контрагента.... как-то так, в общем есть чем заняться. Еще раз СПАСИБО!