I am trying to read some columns from my CRM database in SharePoint 2010 list using external content type via SharePoint Designer 2010. But the GUID fields are refusing to be imported. By this, what I mean is, when I create an External List based on the External Content Type created in SPD, the list doesnt show the fields that are of GUID type. There is no error messages, warnings, or log file entries that explains this. Any ideas as to why this may be happening?
I am not trying to edit or write back to the database, simply read. I can read/see other fields fine in the destination list.
I have the exact same issue. For me I was hoping to Edit the GUID or add it, but since the External List does not show the GUID at all I can't do any of that. You stated you just need to read it though. You can get the GUID type columns to show up by creating a new PAGE and adding a Web part of type 'business data list' which connects to your External Content Type. Look at the link below...specifically the part half way down entitled "Deploy the solution and create new page to see the associated data lists". It is very useful to link up data between tables too using Business Data Related Lists.
http://blogs.msdn.com/b/vssharepointtoolsblog/archive/2010/08/02/walkthrough-of-creating-association-between-sharepoint-bdc-entities-using-visual-studio-2010.aspx
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.
Is there a tool that allows querying (and aggregating data from) a library of infopath forms in MOSS? I can't use promoted fields, since some of the items I want to query are in repeating groups which (AFAIK) cannot be promoted. So I have to query the underlying XML.
I realize I can write custom code that iterates through the forms and perfoms a xpath query on each, I just wonder if there is an existing tool or functionality for this?
You can use the lists.asmx web service to retrieve the XML and work with it within reporting services or even within Excel.
Look at using XML as a data source in SQL reporting services
if you export the list to a spreadsheet you should also be able to work as you would any other spreadsheet. It all depends on what you want to do with the information and where it will end ultimately.
You could also look at tying the data into dundas charts web parts
We have an issue with rolling out content types with features. How does one roll them out to the SharePoint farm and update the database at the same time. Right now, we cannot figure it out. Is there something that has to be done custom?
By "update the database" I would assume that you mean your custom database, not any of the SharePoint databases?
Deign your database so that you will have some sort of mechanism to store the version. In its most simple form, a configuration table with a version row/column would be sufficient.
You can in the feature activated event, place code that checks the version of your database and, if necessary, performs any custom T-SQL scripts that updates your database.
Content types can be confusing to deploy. Once you deployed the content type by a feature and someone is using this content type (I.e a Sharepoint list, document, page layout etc) you CANNOT update the content type by redeploying the feature. This is by design. When a list adds a content type it makes a copy of the content type in the site collection.
There are two ways to solve this:
Update the content type in GUI and check "update all child content types"
Create a new feature "update content type x feature". Add a event handler to the feature activation and update the content type in the site collection by applying the contentType.update(true) method. To verify that all the child content types are updated create a SPQuery object with an beginswith parameter to the content type id.
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.