отбор значений при помощи @dbcolumn

DNT

Постоялец форума
Lotus team
12.10.2005
590
7
#1
Доброго всем времени суток!

Есть поле "Контрагент" тип 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 this context."
Документов в представлении "Contr" - 2130 шт., каждый объемом в среднем 100 байт.

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

morpheus

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

DNT

Постоялец форума
Lotus team
12.10.2005
590
7
#3
вложений в документах контрагентов нет. Там всего-то два поля текстовых. А NoCache щаз проверим...

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

morpheus

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

Xalet

Well-Known Member
08.08.2008
410
0
#5
Документов в представлении "Contr" - 2130 шт., каждый объемом в среднем 100 байт.
а это разве не больше 65к? Что там в первом столбике у вас. На 65к средняя длинна не должна 30 символов превышать. Заменить дайлоглист на кнопочку с пиклистом каким и будет счастье.
 

DNT

Постоялец форума
Lotus team
12.10.2005
590
7
#6
а это разве не больше 65к? Что там в первом столбике у вас. На 65к средняя длинна не должна 30 символов превышать. Заменить дайлоглист на кнопочку с пиклистом каким и будет счастье.


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

Xalet

Well-Known Member
08.08.2008
410
0
#7
Про 30 символов слышу первый раз, это откуда?
это 6500 / 2130

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

DNT

Постоялец форума
Lotus team
12.10.2005
590
7
#8

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
2
#9
Если названия русские, то символ весит 2 байта.
 

duchan

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

DNT

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