Showing posts with label fql. Show all posts
Showing posts with label fql. Show all posts

Monday, September 10, 2018

An approach to search for a URL within a page or document in SharePoint

image

The Search Explained Yammer network is a great place to ask the weird and quirky search questions. Unfortunately it’s not indexed by Google, so answers there will not benefit everyone – which is why I’m writing this post.

A couple of days ago someone posted a question if it was possible to find pages in SharePoint which contain a specific link. The need was to identify broken links. Use-case can be if you rename a file, and want to find all pages linking to that file before renaming – to make sure they still point correctly.

This post will show you one approach which works, and if you have a better suggestion, please let me know.

Question is; how can you go about finding a page with the link https://contoso.sharepoint.com/sites/collection/site/library/document.docx as part of the content?

Wednesday, December 17, 2014

S15E11: FAST Query Language (FQL) – The Unwanted Step Son

Want the book? Go get it!

This is the eleventh episode in my series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.

In the first two episodes of the series I covered KQL and a couple of the new operators introduced with SharePoint 2013 which came from FQL - XRANK, NEAR and ONEAR.
In addition FQL has even more operators, some of them listed below:
  • starts-with
  • ends-width
  • count
  • andnot
  • range
There are also other operators which gives you great control over how a query is being sent over and parsed, and I recommend reading over the samples at FAST Query Language (FQL) syntax reference.

The post title plays at the fact that FQL is sort of hidden away, and no one really talks about it while the underlying search engine (and the refiner UI) in SharePoint (still) uses FQL.

This means KQL statements are translated to FQL before being executed. If this will hold true forever no one knows, but probably until that part of the search engine is being rewritten at some point – and this is good news as FQL has some tricks up it sleeve compared to the polished KQL counterpart.

Thursday, July 18, 2013

Limiting search results by exact time in SharePoint 2013–and how to do FQL

[Update 2020-01-27]
KQL in SharePoint Online and SharePoint 2019 now support time portion as well. For SP2016 and SP2013 you still need to use FQL to accomplish this.

[Original post]
Often you might find the need to limit search results between two dates, or even more exact, between two exact time intervals. The issue is that property queries written in KQL will disregard the time portion of your query, limiting to full day results only (See this old post for an explanation).

FAST Search for SharePoint allowed queries with the time portion in Sharepoint 2010 by using FQL, and fortunately you can do this in 2013 and Office 365 as well.

Doing FQL in 2013 in theory involves setting a parameter either on your REST queries or on the KeywordQuery object telling it your query is written in FQL and not KQL. The reality is a bit more complex involving a custom result source, and to tell you the truth. I have yet to be able to get FQL to work using REST this way.

How then? you might ask. Use use the RefinementFilters property instead! This property actually uses FQL which is what we need and is our “Get out of jail free card”. And all though KQL has more of the FQL operators in 2013, FQL still has some tricks up it's sleeve. Worth taking a look at for sure.

To limit on dates you will use the FQL range operator. The default behavior is to use “greater than” and “equal and less than” if not specified in the query.

The granularity of date/time queries are down to 7 decimals, as long as the crawler has been able to set this level of granularity during indexing.