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.
Related
I have this list with some Grouped columns and with some non grouped columns as well as some List Header and Footer.
I also have some automatic created TOTALS for some of the metrics as well as some manually created totals for some metrics.
QUESTION : I now simply need to REPLACE a metric on the report by another metric. Problem is that the list displays automatic totals for some of the metrics including the one i need to replace so i want to know if it will break (destroy) the structure of my list and will i need to recreate its structure or is there a way to replace the metric without affecting my list sttucture, therefore no need to recreate my totals
Regards !
I believe you can go to the query for the list
In the query, find the data item
Change the expression definition to the new thing you want
Change the property for the name & label too
This way you do not have to adjust the layout
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?
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).
I am building a web site that has a wish list. I want to store the wish list(s) in azure table storage, but also want the user to be able to sort their wish list, when viewing it, a number of different ways - date added, date added reversed, item name etc. I also want to implement paging which I believe I can implement by making use of the continuation token.
As I understand it, "order by" isn't implemented and the order that results are returned from table storage is based on the partition key and row key. Therefore if I want to implement the paging and sorting that I describe, is the best way to implement this by storing the wish list multiple times with different partition key / row key?
In this simple case, it is likely that the wish list won't be that large and I could in fact restrict the maximum number of items that can appear in the list, then get rid of paging and sort in memory. However, I have more complex cases that I also need to implement paging and sorting for.
On today’ s hardware having 1000’s of rows to hold, in a list, in memory and sort is easily supportable. What the real issue is, how possible is it for you to access the rows in table storage using the Keys and not having to do a table scan. Duplicating rows across multiple tables could get quite cumbersome to maintain.
An alternate solution, would be to temporarily stage your rows into SQL Azure and apply an order by there. This may be effective if your result set is too large to work in memory. For best results the temporary table would need to have the necessary indexes.
Azure Storage keeps entities in lexicographical order, indexed by Partition Key as primary index and Row Key as secondary index. In general for your scenario it sounds like UserId would be a good fit for a partition key, so you have the Row Key to optimize for per each query.
If you want the user to see the wish lists latest on top, then you can use the log tail pattern where your row key will be the inverted Date Time Ticks of the DateTime when the wish list was entered by the user.
https://learn.microsoft.com/azure/storage/tables/table-storage-design-patterns#log-tail-pattern
If you want user to see their wish lists ordered by the item name you could have your item name as your row key, and so the entities will naturally sorted by azure.
When you are writing the data you may want to denormalize the data and do multiple writes with these different row key schemas. Since you will have the same partition key as user id, you can at that stage do a batch insert operation and not worry about consistency since azure table batch operations are atomic.
To differentiate the different rowkey schemas, you may want to prepend each with a const string value. Like your inverted ticks row key value for instance woul dbe something like "InvertedTicks_[InvertedDateTimeTicksOfTheWishList]" and your item names row key value would be "ItemName_[ItemNameOfTheWishList]"
Why not do all of this in .net using a List.
For this type of application I would have thought SQL Azure would have been more appropriate.
Something like this worked just fine for me:
List<TableEntityType> rawData =
(from c in ctx.CreateQuery<TableEntityType>("insysdata")
where ((c.PartitionKey == "PartitionKey") && (c.Field == fieldvalue))
select c).AsTableServiceQuery().ToList();
List<TableEntityType> sortedData = rawData.OrderBy(c => c.DateTime).ToList();
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).