Помогите разобраться с проблемой....

[turumbay]

Тотал в колонке показывает - 937 536. Да, прости ошибся... не лукап, а колумн!
Формула колумна: FIELD DivisionTitle := @Unique(@DbColumn("":"NoCache"; ""; "StaffByPeriodName"; 3)). По поводу 68 unid-ов с разделителями ты прав, колумн возвращает их и записывает в поле, вот здесь как раз и ошибка в 7 версии (ОШИБКА: Неверный тип данных для оператора или @-функции: ожидался текстовый))! Документов в виде - 29 299!!!

Вывалились по лимиту - что и требовалось доказать. Причина найдена.
Теперь собсна к решению проблемы: даже если бы мы не имели ограничения на размер возвращаемых данных - тянуть мегабайт данных на клиента - не комильфо. Проход скриптом по viewentry - тот же мегабайт в итоге придеца перелопатить.
У вида есть интересная фича "generate unique key in index"( предпоследняя закладка свойств вида ). Почитайте хелп - может она вам поможет. Тоже правда не безглючное решение - помница были проблемы с таким индексом при наличии в бд конфликтных документов.
И кстати, каков ожидаемый объем возвращаемых данных(с учетом @unique)? Они в поле-то влезут?

 

[nvyush]

У вида есть интересная фича "generate unique key in index"( предпоследняя закладка свойств вида ). Почитайте хелп - может она вам поможет. Тоже правда не безглючное решение - помница были проблемы с таким индексом при наличии в бд конфликтных документов.

Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.

 

[turumbay]

Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.

Вот не уверен что все так просто в этом случае. Деталей не помню, но помню что грабли были и было мучительно больно

 

[nvyush]

Документов в виде - 29 299!!!

"@DbColumn can return no more than 64K bytes of data"
При 30К документов из каждого можно получить максимум по два байта, три — уже получим переполнение.

 

[turumbay]

Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.

Работает.
Я с некоторых пор избегаю таких видов, из-за печального опыта их использования. Похоже, однако, что просто не умею их готовить.

 

[alexstudent]

P.S. Вы уверены, что под 8ой @DbColumn вернул ВСЕ значения?

Да уверен! 68 подразделений (т.е. унидов), в 8 версии все ок!!!!!!!

Добавлено:

И кстати, каков ожидаемый объем возвращаемых данных(с учетом @unique)? Они в поле-то влезут?

Вроде уже писал про это, в 8 версии проверял, возвращает 2243 байта.

 

[turumbay]

Да уверен! 68 подразделений (т.е. унидов), в 8 версии все ок!!!!!!!

Гы. А я вот уверен в обратном. Цитата из хелпа 8.5: "@DbColumn can return no more than 64K bytes of data"
Вам просто повезло, что в первых 64к находились все нужные вам значения. Рассчитывать ли на такое везение на протяжение всей жизни вашего приложения - решать вам. сгенерите unique index и будет вам щастье ( на всех клиентах ). дополнительная вьюха будет копеечной по размеру и по обслуживанию.

 

[alexstudent]

Сгенерите unique index и будет вам щастье ( на всех клиентах ). дополнительная вьюха будет копеечной по размеру и по обслуживанию.

Не совсем понял идею, можно подробней? Спасибо.

 

[nvyush]

Не совсем понял идею, можно подробней? Спасибо.

Создать представление специально для данного @DBColumn с взведённой галкой "generate unique keys in index" (предпоследняя закладка свойств вида), в формуле отбора обязательно добавить !@IsAvailable($Conflict). В любом случае лучше получать сразу уникальный набор значений, чем потом его обрабатывать @unique — будет существенно быстрее.

 

[lmike]

я предлагал не поднимать эту галку, а просто категоризировать
и бежать по навигатору!

 

[turumbay]

я предлагал не поднимать эту галку, а просто категоризировать
и бежать по навигатору!

тоже хорошо, но только при условии, что подходящая категоризованная вьюха уже есть
но если ее нет и собираемся строить спец. вид под эту задачу - то лучше строить именно unique index а не категоризованную. они существенно проще в обслуживании, нежели категоризованные. Тем более, что эта колонка - третья в исходном представлении, и из имени вида ( "...byPeriod" ) очевидно, что задешево ее не категоризуешь.
to alexstudent:
создаем новую вьюху с одним столбцом. формулу отбора берем из вида "StaffByPeriodName" + !@IsAvailable($Conflict). формулу столбца берем из соотв. столбца той же вьюхи. не забыть сделать столбец сортированным. у вида взвести пресловутую галку. @DbColumn выполнять по первому столбцу новой вьюхи.

 

[Constantin A Chervonenko]

я предлагал не поднимать эту галку, а просто категоризировать
и бежать по навигатору!

Э!.. "Ту" вьюху можно ещё в DialogList-е открыть! (Для чего чаще всего @DBColumn и используется)

 

[Darker]

Есть одна идея с использованием API. Старожилы, только не бейте меня за методы через "****")))
Можно значение 3-го столбца получить с помощью PickListStrings метода NotesUIWorkspace.
Во вьюхе "StaffByPeriodName" в Postopene прописать функцию keybd_event (имитируем нажатие Ctrl+A+Enter).

P.S. Пробовал - работает))

 

[alexstudent]

ВСЕМ СПАСИБО ЗА ПОМОЩЬ! =)