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

  • Автор темы Автор темы alexstudent
  • Дата начала Дата начала
alexstudent сказал(а):
Тотал в колонке показывает - 937 536. Да, прости ошибся... не лукап, а колумн!
Формула колумна: FIELD DivisionTitle := @Unique(@DbColumn("":"NoCache"; ""; "StaffByPeriodName"; 3)). По поводу 68 unid-ов с разделителями ты прав, колумн возвращает их и записывает в поле, вот здесь как раз и ошибка в 7 версии (ОШИБКА: Неверный тип данных для оператора или @-функции: ожидался текстовый))! Документов в виде - 29 299!!!
Нажмите, чтобы раскрыть...
Вывалились по лимиту - что и требовалось доказать. Причина найдена.
Теперь собсна к решению проблемы: даже если бы мы не имели ограничения на размер возвращаемых данных - тянуть мегабайт данных на клиента - не комильфо. Проход скриптом по viewentry - тот же мегабайт в итоге придеца перелопатить.
У вида есть интересная фича "generate unique key in index"( предпоследняя закладка свойств вида ). Почитайте хелп - может она вам поможет. Тоже правда не безглючное решение - помница были проблемы с таким индексом при наличии в бд конфликтных документов.
И кстати, каков ожидаемый объем возвращаемых данных(с учетом @unique)? Они в поле-то влезут?
 
turumbay сказал(а):
У вида есть интересная фича "generate unique key in index"( предпоследняя закладка свойств вида ). Почитайте хелп - может она вам поможет. Тоже правда не безглючное решение - помница были проблемы с таким индексом при наличии в бд конфликтных документов.
Нажмите, чтобы раскрыть...
Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.
 
nvy сказал(а):
Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.
Нажмите, чтобы раскрыть...
Вот не уверен что все так просто в этом случае. Деталей не помню, но помню что грабли были и было мучительно больно :-)
 
nvy сказал(а):
Лечится добавлением !@IsAvailable($Conflict) в формуле отбора представлениия.
Нажмите, чтобы раскрыть...
Работает.
Я с некоторых пор избегаю таких видов, из-за печального опыта их использования. Похоже, однако, что просто не умею их готовить.
 
TIA сказал(а):
P.S. Вы уверены, что под 8ой @DbColumn вернул ВСЕ значения?
Нажмите, чтобы раскрыть...

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

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

Вроде уже писал про это, в 8 версии проверял, возвращает 2243 байта.
 
alexstudent сказал(а):
Да уверен! 68 подразделений (т.е. унидов), в 8 версии все ок!!!!!!!
Нажмите, чтобы раскрыть...
Гы. А я вот уверен в обратном. Цитата из хелпа 8.5: "@DbColumn can return no more than 64K bytes of data"
Вам просто повезло, что в первых 64к находились все нужные вам значения. Рассчитывать ли на такое везение на протяжение всей жизни вашего приложения - решать вам. сгенерите unique index и будет вам щастье ( на всех клиентах ). дополнительная вьюха будет копеечной по размеру и по обслуживанию.
 
alexstudent сказал(а):
Не совсем понял идею, можно подробней? Спасибо.
Нажмите, чтобы раскрыть...
Создать представление специально для данного @DBColumn с взведённой галкой "generate unique keys in index" (предпоследняя закладка свойств вида), в формуле отбора обязательно добавить !@IsAvailable($Conflict). В любом случае лучше получать сразу уникальный набор значений, чем потом его обрабатывать @unique — будет существенно быстрее.
 
я предлагал не поднимать эту галку, а просто категоризировать
и бежать по навигатору!
 
lmike сказал(а):
я предлагал не поднимать эту галку, а просто категоризировать
и бежать по навигатору!
Нажмите, чтобы раскрыть...
тоже хорошо, но только при условии, что подходящая категоризованная вьюха уже есть
но если ее нет и собираемся строить спец. вид под эту задачу - то лучше строить именно unique index а не категоризованную. они существенно проще в обслуживании, нежели категоризованные. Тем более, что эта колонка - третья в исходном представлении, и из имени вида ( "...byPeriod" ) очевидно, что задешево ее не категоризуешь.
to alexstudent:
создаем новую вьюху с одним столбцом. формулу отбора берем из вида "StaffByPeriodName" + !@IsAvailable($Conflict). формулу столбца берем из соотв. столбца той же вьюхи. не забыть сделать столбец сортированным. у вида взвести пресловутую галку. @DbColumn выполнять по первому столбцу новой вьюхи.
 
Есть одна идея с использованием API. Старожилы, только не бейте меня за методы через "****")))
Можно значение 3-го столбца получить с помощью PickListStrings метода NotesUIWorkspace.
Во вьюхе "StaffByPeriodName" в Postopene прописать функцию keybd_event (имитируем нажатие Ctrl+A+Enter).

P.S. Пробовал - работает))
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ