I know that is is possible to query a specific site collection using the SPSiteDataQuery but I would like to perform the same operation within a whole web application. In fact, I would like to query a specific list template in a whole web application.
I could loop over the site collections of the web application but it is really too much time consuming.
Does anybody have an idea ?
You might like to try doing it via a search solution instead?
This depends on whether you have a content type or other property to search on, but it will scope to web applications much better.
Related
We have a special situation at our office where we "close" off a site collection when a project is complete. Our architecture is setup such that each project in play is it's own site collection. When the project is complete we close the project in SP by setting the site collection to read-only.
Part of our business would like to still view the closed site collections, but doesn't want to go through a list of them (I mean excel spreadsheet or some other external form of tracking), but instead wants to do it from a page in SP. Our solution is to modify one of our other solutions (search query web part that finds all site collections they belong to) and only search on closed site collections.
I know how to determine if a site is ReadOnly or not in Powershell (#spSite.IsReadOnly), but that isn't going to work here and going through the properties in search I couldn't find anything that jumped out at me to do this. Does anyone know how to return ReadOnly site collections in a Search Query Web Part?
Thank you.
I know of a managed property called: SiteClosed but I haven't got the slightest idea what it does. Looking at the name this might be the one to start with.
If this doesn't work I'm afraid the only other option is to create a custom Web Part...
I don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
This is quite a simple question to ask, hopefully the answer is as straight forward! Can you use a Content Query Webpart on Site Collection A to read data from Site Collection B?
If it's not supports right out of the box, are there some configuration options which you can use to make it happen?
Thanks.
No configuration option will enable you to have a cross site content query webpart.
You can either create a custom web part that will do it or buy one (several options out there, here is one
If you decide to create your own web part, you will easily find code online that will help you. Here is an example.
No, it must be within the same site collection as it uses the SPSiteData query, which works within the site collection
I have a piece of data, a simple string containing the server name that the SharePoint solution is deployed to, that I retrieve from a configuration store in a helper method in a common DLL used throughout my solution. This helper method is used throughout my custom pages and web parts, to build a number of URLs, etc.
I would like to persist this string, and prevent it being repeatedly retrieved from the configuration store. My Sharepoint installation is currently on a single server, but will be migrated to a SharePoint server farm in the near future, so simply determining the server name of the current request, etc isn't an option. I have looked at caching as described in the best practices for SharePoint, but unless I use a coherent cache like NCache or Velocity/AppFrabric, I will again have issues when the move to server farm occurs. Given that this is a single string, adding a full caching solution such as Velocity seems like overkill.
Does anyone have any suggestions on the best way to persist this data? Am I missing something obvious here?
Thanks, MagicAndi
Look into using the Property bag that is exposed by all major SharePoint objects to persist information. i.e.
SPFarm.Properties
SPWebApplication.Properties
SPSite.Properties
You could:
Store the string in web.config. You can programatically change the web.config on all the farm's webservers using a SPWebConfigModification
Store the string in a SharePoint list and read from it. I usually use this solution because I have more to store than a single string. The list is 'available' on all web servers and I cache its values in an ASP.NET cache object. Someone made this concept into a solution you can download and install: SPConfigStore
This article may be of use to those looking at storing configuration data in SharePoint:
Six ways to store settings in SharePoint
You can use SPPersisted to do such kind of operations.
I've built a web part for Sharepoint that retrieves data from an external service. I'd like to display the items in a way that's UI-compatible with Sharepoint (fits in with its surroundings.)
I'm aware of the "DataFormWebPart" but was unable to get one working properly. It requires a valid DataSource and I was unable to build one from the results of a web service call... Part of the problem is that my web service wrappers don't expose the XML return info, rather I have a bunch of deserialized objects. There doesn't seem to be an easy way to turn actual objects into a datasource, or populate a "generic" datasource from object data.
I could use an SPGridView to get the same UI, but the grid control doesn't have much in the way of smarts -and- it forces every field into its own column. I'd prefer to render each list item as a single cell with complex rendering (for instance the way that StackOverflow shows its lists of questions.) I'd also like to get as much of the Sharepoint-standard UI as possible, such as the sorting, filtering, and paging controls.
So, first: Has anyone here written a Sharepoint control that does this, and if so do you have sample code to share? If not: am I overlooking some useful control, whether MS-supplied or available in an external library?
Thanks!
Steve
Sharepoint: Best way to display lists
of non-Sharepoint content with
“compatible” UI?
Take a look at the built in sharepoint web controls:
Microsoft.SharePoint.WebControls Namespace
It contains all the controls used in sharepoint. I'd tell you more, but the documentation is very thorough.
Problem with SharePoint is that there are a bunch of different ways to do this. If your data is not changing too often and is not overly large it may be worth considering entering it into a list for display.
If you have the Enterprise licence it may be worth getting your data into the BDC and using it there.
you may have to convert the objects into xml or use the serialised objects with the XML webpart for display. This still has the issue of custom rendering using XSLT.
Here's a great article that explains how to configure BDC connections to web services using the BDC Definition Editor:
Creating a Web Service Connection by Using the Business Data Catalog Definition Editor
http://msdn.microsoft.com/en-us/library/bb737887.aspx
The best way to do this IMO is to make a Web Part. As a Web Part the UI will be automatically rendered to be the same as the theme the site is using (unless you override it) and it will be able to be placed anywhere by anyone with admin privileges.
Tutorial on making a Web Part
Tutorial on packaging and deploying a Web Part
Example Web Part Source Code
You could create a custom web part and use an SPGridView. You say you don't like it, because it forces every field into its own column, but that's not true. You can create a template (ITemplate) for every column and fully customize what's shown inside it, just like you would using a normal ASP.Net GridView. Using this approach I've added the little "New" images right next to a list item's Title, just like SharePoint does itself.