Getallentriesbykey криво ищет по составному ключу

  • Автор темы Автор темы nvyush
  • Дата начала Дата начала
N

nvyush

Здравствуйте, все!
Столкнулся с проблемой: есть представление, первый сортированный столбец типа дата, второй сортированный столбец вычисляется по формуле типа @If(SomeField = "SomeValue"; "0"; "1") (пробовал также формулу типа @If(SomeField = "SomeValue"; 0; 1) — без разницы). Выполняю скрипт
Код: 
	Redim key(1) As Variant
Set key(0) = dateRange
key(1) = "0"
Set entries = view.GetAllEntriesByKey(key, True)
и получаю нужные записи, выполняю
Код: 
	Redim key(1) As Variant
Set key(0) = dateRange
key(1) = "1"
Set entries = view.GetAllEntriesByKey(key, True)
и получаю ноль записей, хотя документы, удовлетворяющие условию поиска точно есть. Более того, меняю формулу столбца на @If(SomeField = "SomeValue"; "1"; "0") и в обоих случаях получаю адекватный результат! Представление перед запуском скриптов индексировал. Кто подскажет, где собака порылась?
 
я имею в виду - что False нужен
 
lmike сказал(а):
я имею в виду - что False нужен
Нажмите, чтобы раскрыть...
Пробовал и так. Если exactMatch = False или опущен (что, в принципе, одно и то же), то при перестановке значений в формуле столбца "пропадают" противоположные документы. Сейчас попытался переставить столбцы местами, но получил ошибку Invalid key value type. Похоже, придётся отбирать записи только по диапазону дат, а значение второго столбца анализировать "в ручную".
 
nvy как-то пробовала, похожая проблема была из-за того, что дата была мультивальная, закономерности не отследила, переделала вообще без вьюхи. Что-то в хелпе было насчет глючности поиска по составным ключам.
 
По моему, бегать по уже отобранной коллекции, перебирая её - изврат.
Не проще ли собрать формулу для db.Search?
 
lmike сказал(а):
не всегда..., если это индекс (вьюшки), но (разумеется) луче найти первый элемент и от него бежать по навигатору (если сами доки не нужны)
Нажмите, чтобы раскрыть...
Это само собой :)
Я имел ввиду решение конкретно данной проблемы. "Бежать" может быть много и долго, а Search сразу вернёт нужную коллекцию.
 
Быть может, что дело в том, что ключи должны быть однородными? У вас массив - ассорти из DateRange и String
 
lmike сказал(а):
если сами доки не нужны
Нажмите, чтобы раскрыть...
Конкретно в данной задаче вся необходимая информация отобрана в entry, сами документы не нужны.
VladSh сказал(а):
"Бежать" может быть много и долго, а Search сразу вернёт нужную коллекцию
Нажмите, чтобы раскрыть...
К сожалению, Search не самый быстрый способ получить информацию из БД. К тому же бежать в любом случае придётся — задача собрать из энтрисов отчёт в Ёкселе.
Darker сказал(а):
Быть может, что дело в том, что ключи должны быть однородными? У вас массив - ассорти из DateRange и String
Нажмите, чтобы раскрыть...
Если верить справке, то:
Parameters
keyArray
String (variable-length only), integer, long or double value, or array of string, number, DateTime, or DateRange objects. Each element in the array is compared to a sorted column in the view. The first element in the array is compared to the first sorted column in the view; the second element is compared to the second sorted column; and so on.
Нажмите, чтобы раскрыть...
"Достоинство — простота, недостаток — не работает" (с)пёрто.
Изменил формулу столбца на @If(SomeField = "SomeValue"; 1; 2), а в код добавил проверку условия:
Код: 
	Set entry = entries.GetFirstEntry
Do Until entry Is Nothing
If entry.ColumnValues(1) And typeMask Then Call addReportRow(entry.ColumnValues)
Set entry = entries.GetNextEntry(entry)
Loop
При typeMask = 1 отбираются документы первого типа, при typeMask = 2 — второго, при при typeMask = -1 — все.
 
nvy сказал(а):
Конкретно в данной задаче вся необходимая информация отобрана в entry, сами документы не нужны.
Нажмите, чтобы раскрыть...
Я всего лишь предложил вариант обхода. Чтобы не тра..мучаться с багами лотусни.

nvy сказал(а):
К сожалению, Search не самый быстрый способ получить информацию из БД.
Нажмите, чтобы раскрыть...
На форуме интертраста когда-то давно кто-то выкладывал свои наблюдения... не так всё было и плохо. А если ещё и учесть то, что не придётся ещё раз бежать по докам, то даже не сомневаюсь, что скорость у сёрча не будет меньше.

nvy сказал(а):
К тому же бежать в любом случае придётся — задача собрать из энтрисов отчёт в Ёкселе.
Нажмите, чтобы раскрыть...
В энтрисах я вижу 3 основный достоинства:
- не нужно что-то сортировать;
- получить нужные данные сразу (без второго прохода), с щадящим и равномерным использованием памяти;
- сложные формулы, которые могут быть уже рассчитаны в колонках.
Если какое-то условие не выполняется, то я бы заюзал сёрч, чем использовать энтрисы ради энтрисов..
 
Чтобы пользователь не очень скучал, вывожу в статус-бар "чч:мм:сс: Отбор документов...", "чч:мм:сс: Экспорт в Excel", "чч:мм:сс: Экспорт завершён". Второе время от первого не отличается ни на секунду, третье от второго — десятки секунд. Так что если что и оптимизировать, то это экспорт, но где у комы педаль газа, я что-то не нашёл.

Да, кстати, Search возвращает коллекцию документов. То есть при переборе коллекции нужно будет открывать документы, а они "весят" существенно больше энтрисов. Конкретно в данном случае документов обоих типов примерно поровну, т.е. энтрисов я перебираю в ~два раза больше, чем нужно, но тяну с сервера ~100 байт/энтрис вместо ~3,5 кбайт/документ.
 
nvy сказал(а):
существенно больше энтрисов
Нажмите, чтобы раскрыть...
а зачем? я ж описывал метод - получаем первый! энтрис, а далее- анализируем втрой столбец (в цикле), пробегая по нафигатору (ведь второй отсортирован)...
ластэнтрис - тоже есть (со значениями)
есть у нафигатора два интересных св-ва - GotoPos и GetPos
исходя из этих данных - могем методом половинного деления (или другими ;) ) искать "начало" второго ключа
др. словами - быстрее найдем второй ключ не перебирая каждый энтрис (в общем случае)
 
Имеем представление, сортированное по двум первым столбцам:
Дата |Тип |Нужные значения
-------------------------------------------
01.01.2010|2 |***
02.01.2010|2 |***
03.01.2010|1 |***
03.01.2010|2 |***
04.01.2010|1 |***

Нужно отобрать документы 1-го типа за период с 01.01.2010 по 04.01.2010. Как тут применить метод половинного деления?
 
я уже выше сказал...
в приведённом куске - не отображена сортировка 2-го в протяжённом диапозоне одной! даты
вот для "таких" случаев
01.01.2010|2 |***
02.01.2010|2 |***
03.01.2010|1 |***
03.01.2010|1 |***
..... 777 раз
03.01.2010|1 |***
03.01.2010|2 |***
.... 555 раз
03.01.2010|2 |***
04.01.2010|1 |***
 
А если не париться и объединить два столбца, поменять формат даты на yyyy/mm/dd, превратить в @text

2010.01.01,2 |***
2010.01.02,2 |***
2010.01.03,1 |***
2010.01.04,2 |***
2010.01.05,1 |***
 
Darker
тогда получим два неприятных эффекта:
-невозможность обора по диапазону дат
-убиение специфики дат - траблы при различных региональных настройках и таймзонах
 
Если я правильно понял, то вообще отказаться от Getallentriesbykey, взять навигатор от представления, колонки категоризовать и "прыгать" по категориям? Надо будет устроить "сравнительный забег" на досуге...
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

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

Верх Низ