New answers tagged fast-search
1
As you have seen, the limit for the Query is actually 2048 characters. So any more than that will throw this exception.
http://stackoverflow.com/questions/8061330/how-to-overcome-fast-search-char-limitation-2048 is a possible duplicate of your question, but sadly it never recieved any attention.
Also this from Technet ...
1
Solved it myself. Use "Path" in search query.
Path:"https://site1/sites/Blog/Lists/Posts/ViewPost.aspx?ID=2" OR Path:"https://site2/sites/sBlog/Lists/Posts/ViewPost.aspx?ID=5"
0
In addition to using fedration, you can publish the Search Server Application from 2013 and consume it in another 2010 or 2013 farm. Then queries all queries would be served from 2013.
0
Yes, indeed the protocols have not really changed from that respect. You are still looking at either Federating Search Results (http://blogs.3sharp.com/2013/01/04/build-a-federated-result-source-for-sharepoint-2013-search-part-1/) or rely on the Search Connector Framework - pretty much the same as with SPS 2010 to connect to external data-sources via BDC ...
0
Some points to consider:
Using iFilter solutions searches within the PDF documents, while using a unlimited multiline text field does not need iFilter installed.
Also search syntax differs: when using iFilter, OOTB you can simply type in the words you are looking for in a search field present on many pages e.g. word1 OR word2 versus multilinefield:word1 ...
1
Your best approach is to get titles on those weird formats into a separate managed property. Then you can do word searches on that property in FQL with less chance of the query bombing.
It's all about term expansion in the search engine core and how many terms would match and how big(slow) will the end query be.
The other approach is to create a full text ...
Top 50 recent answers are included
