We have indexed a couple of columns in SharePoint 2013 lists and these columns are used in $filter in REST api. The query stops working when the list crosses its threshold limit. Isn't the index meant to have columns queried and filtered no matter what the data size is in the list? Can someone throw any light on this?
Related
I am working on PowerApp, I got the below error when i added few columns in the sharepoint list.
The query cannot be completed because the number of lookup columns it contains exceeds the lookup column threshold
I have read some article those says that sharepoint online 2013 supports only 12 lookup columns Here the link.
My List contains almost 15 People picker fields which causes this issue.
How should I removed this error. Any solution will be appreciated.
You can consider reworking this solution. Could you lower the number of people pickers - maybe make some of them multi people pickers. You could also split the list into two lists of data.
I have a large SharePoint 0365 list of over 15,000 items. I have already used all 20 indexed columns. I now need to filter by a different column. Is it safe for me to remove an indexed column and changed to a different field? Do you have to reindex the list, if I do that?
I'm afraid you'll find that creating or removing column indexes are among the operations that are restricted upon surpassing SharePoint's list view threshold, as documented here.
In an on-premises SharePoint farm (or an otherwise traditional SharePoint farm using cloud-hosted infrastructure), you'd have access to central administration where you could temporarily increase the threshold, set a time window during which the threshold won't apply, or even use Powershell to temporarily set the EnableThrottling property of the list to false, allowing you to make your indexed column changes. But with Office 365 you won't have any of those options.
Depending on the circumstances, you can still circumvent the list view threshold when filtering by first filtering the list by one or more of your indexed columns such that less than 5000 items are returned; you should then be able to filter that subset of results using your unindexed column.
Another alternative would be to use SharePoint's search services to access results in your list that match the given metadata. Since the search crawl index is generated ahead of time (rather than a live query), it is not beholden to the list view threshold. Only problem there is that the results might be stale depending on the frequency of search crawls.
Since you already have 20 indexed columns, it is possible that you might be able to query the list using an already-indexed column to return a response that obeys the list-view threshold ('Date Created' range, or 'Created By' might be useful columns)
Once you return your initial response, you can then filter on the unindexed column of interest.
Are there any limits to the amount of data that can be stored in an individual SharePoint field? If there are, what are they?
Is there a limit in terms of the number of bytes or string length, say, that can be stored as a value of an individual field?
SharePoint stores the list items in a SQL Server table called AllUserData, so the maximum values are determined by the data types of the columns.
You can find the complete structure here. However, I cannot find any resource discussing the mapping between the SharePoint field types and SQL Server columns types; probably because accessing the SharePoint tables directly is strongly discouraged. That's not a big problem though - query the table, look at the results and you will be able to match the fields and the columns (e.g. nvarchar1 correspond to the 1st 'Single line of text' field).
Is there a way to create a SharePoint calculated column that returns a count of the number of entries in a list? So If I have 3 customers in my list with the company "Starbucks" I'd like the field to return "3"
(Edited some wording for clarity per suggestion from dariom).
You may be able to get what you want with another list using a not-so-well-known variation of a lookup column.
Let's say you have a list called Companies with values in the title column like "Starbucks", "Peets", etc. Now you also have the Customers list you refer to, but the "Company" column is a lookup column pointing to the title column in the Companies list.
You can add a count very similar to what you described to your Companies list. Go to your Companies list, add a column of type "Lookup" referring to the Customers list and you'll notice that in the drop-down area where you define the lookup if you point back to the Customers list, you'll have a new option called "Count Related". This is here automatically because it recognizes that the Customers list has a lookup pointing back to this one. Select that Count Related option and now your Companies list will have a column counting how many customers are associated with that company.
No coding, Javascript hacks, or anything. Just hidden SharePoint auto-magic.
No, I don't think there's a way to do this using the out-of-the-box calculated column.
Some other ways you could accomplish this are:
Create a view for your list that with a group by on the company field and include the total count. This is easiest, but might not be exactly what you're looking for.
Create a custom column type that executes a CAML query to find items that you're interested in. There is a learning curve if you've not done it before and if the list that you're adding this custom column to has lots of rows, you'll be executing a query for each row which is inefficient - it'll be OK for a small number of rows.
Use an event handler on the list that updates a column value each time a new item is added or removed from a list. This is easier, but can also be inefficient if you have a large number of items in your list.
As dariom said (damn my slow typing skills, +1!), only the current row can be operated on with calculated columns by default in SharePoint. There are a couple of documented workarounds involving SharePoint Designer or jQuery, though.
You can get a Count of specific list items in an XSLT Data View
To do this you will need SharePoint Designer.
Right click on your SharePoint List view (ensure the list view contains the field you want to filter by) select convert to XSLT Data View. Then in the Data Source Windows select Data Source Tab and drag and drop the field you want to get a total on for the specific items into where you want it displayed in your XSLT Data View. Click on the numerical value that is showing you should get a lightening bolt icon, select the drop down and choose Count, then select again and choose Filter. Select "Click here to add a new clause" then choose your field name again and enter your unique value as Starbucks and click OK, you can repeat this process for other fields you want the totals on. You will now see the total number of Starbucks items in the list.
I got something similar to work in a way similar to Niall. Basically, I:
Based on the source list, created a Data View Web Part (DVWP) on a "test" web
part page.
Added the footer column, which gives a count.
Set the filter for my conditions (i.e., the items I want to count).
In the code, deleted the recurring items row.
I was left with just the footer, which displayed a filtered count for all the list items. I further customized the footer by taking out the shaded background. Finally, I exported this web part and imported it onto the page where I wanted users to see a total of items in the list (which met the criteria).
I'm using a FullTextSqlQuery in SharePoint 2007 (MOSS) and need to order the results by two columns:
SELECT WorkId FROM SCOPE() ORDER BY Author ASC, Rank DESC
However it seems that only the first column from ORDER BY is taken into account when returning results. In this case the results are ordered correctly by Author, but not by Rank. If I change the order the results will be ordered by Rank, but not by Author.
I had to resort to my own sorting of the results, which I don't like very much. Has anybody a solution to this?
Edit: Unfortunately it also doesn't accept expressions in the ORDER BY clause (SharePoint throws an exception). My guess is that even if the query looks like legitimate SQL it is parsed somehow before being served to the SQL server.
I tried to catch the query with SQL Profiler, but to no avail.
Edit 2: In the end I used ordering by a single column (Author in my case, since it's the most important) and did the second ordering in code on the TOP N of the results. Works good enough for the project, but leaves a bad feeling of kludgy code.
Microsoft finally posted a knowledge base article about this issue.
"When using RANK in the ORDER BY clause of a SharePoint Search query, no other properties should be used"
http://support.microsoft.com/kb/970830
Symptom: When using RANK in the ORDER BY clause of a SharePoint Search query only the first ORDER BY column is used in the results.
Cause: RANK is a special property that is ranked in the full text index and hence cannot be used with other managed properties.
Resolution: Do not use multiple properties in conjunction with the RANK property.
Rank is a special column in MOSS FullTextSqlQuery that give a numeric value to the rank of each result. That value will be different for each query, and is relative to the other results for that particular query. Because of this rank should have a unique value for each result, and sorting by rank then author would be the same as just sorting by rank. I would try sorting on another column instead of rank to see if results come back as you expect, if so your trouble could be related to the way MOSS is ranking the results, which will vary for each unique query.
Also you are right, the query looks like SQL, but it is not the query actually passed to the SQL server, it is special Microsoft Enterprise Search SQL Query syntax.
I, too, am experiencing the same problem with FullTextSqlQuery and MOSS 2007 where only the first column in a multi-column "ORDER BY" is respected.
I entered this topic in the MSDN Forums for SharePoint Search, but have not received any replies:
http://social.msdn.microsoft.com/Forums/en-US/sharepointsearch/thread/489b4f29-4155-4c3b-b493-b2fad687ee56
I have no experience in SharePoint, but if it is the case where only one ORDER BY clause is being honored I would change it to an expression rather than a column. Assuming "Rank" is a numeric column with a maximum value of 10 the following may work:
SELECT WorkId FROM SCOPE() ORDER BY AUTHOR + (10 - Rank) ASC