2010-05-17 2 views
0

Я начал эту задачу, считая ее довольно тривиальной. Однако, идя в глубины, я нахожу, что это либо не так просто, либо, может быть, я использую неправильный подход здесь. В моем случае у меня есть несколько документов, которые не находятся в одном каталоге, но они имеют одинаковые имена/названия. Я хочу, чтобы выполнить поиск на сайте и разрешить документ с наименьшим количеством необработанных результатов.Поиск элемента на основе нестандартного свойства

Таким образом, я решил создать DocumentID (мой пользовательский идентификатор), который является уникальным для каждого документа, и, сохраняя документ, используя хранилище свойств SPFile, я сохранил это новое настраиваемое свойство DocumentID вместе со своим значением для каждого элемента. Теперь, когда я пытаюсь найти документ на основе его значения DocumentID, которое я сохранил, я не получаю никаких результатов.

Чтение проблемы в Интернете дал мне понять, что я должен создать управляемое свойство, чтобы иметь возможность искать в пользовательских свойствах. По мере необходимости я сделал то же самое, но не смог найти подходящее свойство обхода для моего пользовательского свойства (DocumentID). Теперь, если я не найду правильное обходное свойство, которое, я считаю, не под моим контролем, я не смогу использовать силу поиска управляемой недвижимости.

Кто-нибудь имеет лучшую идею или решение точки, в которой я застрял? Любая помощь будет высоко оценен.

Спасибо и наилучшими пожеланиями, Raghu

+0

Каков запрос, который вы выполняете для поиска? Проблема может варьироваться от тривиальной опечатки до полного заблуждения. – 2010-05-17 16:33:29

+0

Спасибо, Rich и Moron за быстрые ответы. Moron, Я создал ManagedProperty и попытался сопоставить это управляемое свойство с соответствующим свойством обхода. После этого я использую функцию поиска точки OOTB с использованием синтаксиса folloiwng: - ManagedPropertyName: SearchText (например, DocumentID: 238120-39ASDA-SD12321) – Raghu

ответ

0

на основе тега, это выглядит, как вы используете SharePoint 2010. Если да, то почему бы не использовать OOTB Document ID Feature вместо создания собственных? Поле «Идентификатор документа» будет частью элемента списка и должно быть доступно для поиска.

+0

Rich, Я должен был упомянуть об этом и раньше. DocumentID - это не единственное свойство, которое у меня есть как пользовательское свойство. Есть еще несколько других свойств. И я ищу подобную свободу для поиска всех этих свойств. – Raghu

+0

Что я могу найти в разных интернет-источниках, создавая новый столбец site/doclib, убедитесь, что мое свойство успешно сканируется с помощью ows_, добавленного в его имя. Это решает мою проблему, но я не удовлетворен этим решением. Вот почему. Эти 3 свойства относятся к типам документов, т. Е. Не все документы в библиотеке документов должны иметь 3 пользовательских свойства, так как метаданные аналогично не все библиотеки документов имеют документы, которые имеют эти дополнительные метаданные. – Raghu

+0

Итак, я искал способ прикрепить эти свойства только к требуемым документам, а также принести их под уведомление искателя. После этого создается управляемое свойство из обходного эквивалента моих пользовательских свойств и выполнения поиска sharepoint OOTB с использованием (ManagedPropertyName: SearchText) синтаксиса. – Raghu

Смежные вопросы