As a feed from external system we get a Catalog items (They are product info) as part of feed once a day. We need to take this feed and store in Sharepoint. Following are things we want to achive with this.
Need to search those items and show as part of standard search resutls.
There will be Insert (New Items) , updates and deletes to the items. In addtion to that catalog item will have metadata associated with it.
We would not be modifing any of that data in our system. it is just the display only.
I would like to know from the group what is the best way to store this in sharepoint and search on them.
I would agree with the suggestion of a timer job to do a perhaps nightly batch import and update of the sharepoint catalog. The catalog would be stored in a sharepoint list using a content type (set of fields) that you specify which will hold all the product related data for the catalog.
The BDC may well be your answer if it's compatible with the type of data you want to display and would be the easier cleaner option. However if it doesn't meet all your requirements, the above solution would be the most flexible route.
Give BDC (Business Data Catalog) a try. MOSS required.
If you don't have MOSS Enterprise, creating your own TimerJob that imports the Catalog info from this once a day into a list is also an option.
Related
We are reviewing in term of storing a business data into Sharepoint List againts tradional SQL database. We noticed that there is limitation on the view (5000 records) in Sharepoint List within Sharepoint itself.
My question is there any tools that we can view/edit/delete records for Sharepoint List as if like SQL Server Management Studio where you can filter the data and then delete/edit the data in bulk ?
I'm appreciated your input.
If Microsoft Access can access the list (as per above) and I assume that the SQL Management can access this also then? Is that correct?
Yes, you can increase the list view Threshold limit beyond 5000 but it is not a best practice and it is recommended that you should not alter this value, as it may degrade the performance.
Instead there are many ways to handle this like :
Create Indexed columns
Limit items on display
Create folders to organize items
Create filtered views (as suggested/commented by vinayak hegde)
Please refer these links :
https://support.office.com/en-us/article/Manage-lists-and-libraries-with-many-items-11ecc804-2284-4978-8273-4842471fafb7
https://blogs.technet.microsoft.com/quentin/2014/07/15/the-list-view-threshold-stop-dont-change-it/
https://technet.microsoft.com/en-us/library/cc262813.aspx?f=255&MSPPError=-2147217396#Throttling
SQL Management Studio cannot access list in SharePoint!
(Well, actually... you can access items with SQLMS directly in the tables in the database, but that is strictly forbidden by Microsoft and doing so breaks the support of the product and can cause unexpected behaviour and errors. Just don't do it!)
You can safely use the lists own Quick Edit mode, where you can do bulk editing similar to editing an Excel sheet.
Quick Edit can be done in a list with more than 5000 items.
Enable Quick Edit by going to
List settings > Advanced Settings > Quick Edit and tick "Yes" to allow items in list to be edited using Quick Edit.
I have a custom page type for employees, and one of the fields is Location. I want to show/filter only employees in "San Jose" or "San Francisco" and used this WHERE condition below but it didn't work. Apparently, I missed something very basic. Could you help?
Location LIKE '%San%';
I did another test, where instead of page type, I used custom table with the exact field names and was able to filter using the same statement. On a related note, I'm new to Kentico and exploring which is more suitable for creating/maintaining a list of about 100 employees - Page Types or Custom Tables - with the ability to filter by department, location etc. Appreciated your input here as well. Best!
If you're adding the WHERE condition into a standard Kentico repeater or other data source, the syntax looks right except you do not need the semicolon ";".
You'll also want to double check the field name, and if you are limiting your query to certain columns (as is best practice especially for larger data sets) and be sure the field you are filtering on is being selected.
Regarding the management of your employee list, either method you've described will work. In that scenario it typically depends on who will be editing the content, and how frequently. It is more editor-friendly, in my opinion, to add those documents into the content tree. This also gives you quicker control over the order, and keeps it similar to how other content on the site is maintained. I also like to set up folders or other parent page types as categories if needed, so the documents can be dragged and dropped between them and it sets up a visual taxonomy that isn't possible if it's all stored in a table. Storing items in the tree also allows for workflow and versioning, as well as more granular control over permissions/access, if this is important to you.
It's awesome that you are thinking about how to best store your data in advance. There many factors to consider such as overall number of records, number of columns, the fact whether you need to use workflow, versioning, preview etc..
The best source of information regarding this would be this article which summarizes all options you have and gives clear explanations of which to use in which scenario.
And to your original question - What components are you using to display the data? Is the repeater? If so, can you make sure to set the Page types property to match the page type you are displaying? If the page types is not configured, Kentico will not load any custom fields because it doesn't know from which table it should load the data from.
Additionally make sure to either include the "Location" field in the Columns property or leave the columns blank (not recommended because then Kentico loads all columns which is like 200. when you count all from CMS_Document, CMS_Tree etc..)
Below is the framework that I use to debug whenever I wish to add a repeater and is facing some problem.
First get all the columns instead of accessing limited columns. Fetching all columns will make sure that I don't have any problem retrieving data.
If I am missing any particular column information name, then I would double check the column name.
I verify this by firing up SQL server management studio and access data from page type table or custom table.
If access to SQL server is not available(generally in Azure hosted solutions with restrictive access to DB), I would enable SQL debug from the settings and see what query repeater is generating to see if it is correct.
I am having a page with documents loaded in SharePoint 2010. I have three buttons below each documents in the page and they are 'Like','Unlike' and 'Comment'. So whenever people go there and see the documents they can click on any buttons of their wish.
My question is how to take the hit count of these buttons seperately and display it for each document. Is it possible to create a list with having these three columns and handle it using Client-Side scripting. Any suggestions or help is much appreciated.
Each item in SharePoint has a property bag that can contain ad-hoc data like this. You could certainly add additional columns to store this data and update those columns but that does mean that users could easily manipulate the values via the UI. Since the property bag is only accessible via the various API's, you wouldn't have this issue.
For an example of accessing the property bag via CSOM (which would be your best option since I'm assuming you want your users to be able to like, unlike and comment without refreshing the page each time), see this post reading and writing property bag values using CSOM
Another thing to consider for comments is the existing notes functionality that exists in SharePoint 2010 and SharePoint 2013. These comments are ties into the social functionality and may give you a bit more bang for your buck. To show the comments page for a particular list item see this post SharePoint Social Data using Javascript
I want to create a new view for the activities entity. My aim was to show only the activities that were related to a record of a certain type eg account. But when i was creating it i saw that aside from saying if it contains data or not, and for specific records, there isnt an option for entity type.
I can understand why this isnt an option in the list, as its not really something people would need to do, but is this possible at all?
Thanks
Create an Advanced Find and specify the following criteria:
Look for: Activities
Related > Regarding (Account)
This will get you all activities which are related to an account.
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.