Now here's something truly useful - from Nick, a SQL query to get all documents in the DB. I can't tell you how many times I've needed this!
SELECT UserData.nvarchar7 AS Title, DirName AS Directory, LeafName AS DocName, Docs.Size AS Size
FROM Docs, UserData
WHERE (DoclibRowId > 0) AND Docs.ListID = UserData.tp_ListID AND Docs.DoclibRowId = UserData.tp_IDORDER BY Directory
Thursday, July 14, 2005
Sharepoint Performance Enhancements
Here's a tip on improving performance in Sharepoint. I haven't tried it yet so I would caution you to be sure that reducing Kernel virtual memory to 1GB won't negatively affect any critical system operations before you implement it. You might also want to check out Nick's post on HTTP compression.
Tuesday, July 12, 2005
Ghosting and Data View Web Parts
While Data View Web Parts may be the coolest thing since...well, Sharepoint...the only way to implement them non-programmatically is with Frontpage. Despite how you may feel about the tool itself, using it to edit pages has the major drawback of sending one immediately into Ghosting hell. The more you edit the worse it gets. What to do?
Fortunately, the answer is simple. When deploying DVWP's, set up a test area or site that is removed from portal navigation (you can always delete it later). Once you've created your web parts page/area/site with Frontpage, you can simply export them to disk, then import them into the correct page. This prevents ghosted pages from running amok in SPS/WSS while still allowing the use of those wonderful DVWP's.
Fortunately, the answer is simple. When deploying DVWP's, set up a test area or site that is removed from portal navigation (you can always delete it later). Once you've created your web parts page/area/site with Frontpage, you can simply export them to disk, then import them into the correct page. This prevents ghosted pages from running amok in SPS/WSS while still allowing the use of those wonderful DVWP's.
Saturday, July 09, 2005
Some Constructive Criticism
It seems that Mike Drip's article is stirring up all kinds of controversy. I dare say he's not much liked by the SharePoint community at this point. On the upside, it has brought out a few constructive criticisms that are worth mentioning. Two good responses are from Andrew Connell and Paul Schaeflein. And if you don't mind a bit of shameless self-promotion, check out my posts from June 13th (June archive here) and July 8th.
Update: Here's an excellent post from Steven Collier on this topic.
Update: Here's an excellent post from Steven Collier on this topic.
Friday, July 08, 2005
A Different View on Document Libraries
The doc library permissions issue is being discussed again in the Sharepoint blogosphere (here and here, with an older post here). Although I generally agree with my fellow Sharepointers, I have to step out and call "Bull!" on this issue. Every "solution" which provides an alternative to item-level permissions in Sharepoint is simply a workaround for a severe deficiency in the application. Microsoft SHOULD have included this functionality in the original release and we all know it - can we please stop dancing around the issue and demand the MS fix it in v.next (or, even better, an upcoming service pack)?
Only if their customers make enough noise will MS relent and solve this problem which affects EVERY SHAREPOINT IMPLEMENTATION. Stop listening to experts who act like they are imparting some mystical wisdom with talk of "metadata" and "views" and "subareas" and demand the following:
1. Item-level permissions for all list types
2. Folder-level permissions (or, as an alternative, nested document libraries)
3. The ability to move docs from library to library AND retain the metadata
4. A Windows Explorer style view for all libraries (that means a complete folder hierarchy not just a single-level view)
Only if you - the customer - make this an important issue will it get resolved. 'nuff said.
Only if their customers make enough noise will MS relent and solve this problem which affects EVERY SHAREPOINT IMPLEMENTATION. Stop listening to experts who act like they are imparting some mystical wisdom with talk of "metadata" and "views" and "subareas" and demand the following:
1. Item-level permissions for all list types
2. Folder-level permissions (or, as an alternative, nested document libraries)
3. The ability to move docs from library to library AND retain the metadata
4. A Windows Explorer style view for all libraries (that means a complete folder hierarchy not just a single-level view)
Only if you - the customer - make this an important issue will it get resolved. 'nuff said.
Tuesday, June 28, 2005
Sharepoint Utilities List
Via JOPX, a nice list of Sharepoint tools and utilities (some free, some not), including a few I've never heard of (is that really possible?).
I would definitely add Knowledgelake and Advis to this list (SiteNavigator users should check Advis' site for the v2 release in a week or so).
I would definitely add Knowledgelake and Advis to this list (SiteNavigator users should check Advis' site for the v2 release in a week or so).
Thursday, June 16, 2005
SPS Anonymous Authentication and Sign-In Button
If you've been having difficulties configuring Sharepoint for anonymous users, welcome to the club. Let's face it - good as it is, SPS was just not designed for extranet environments which require anonymous access. That being said, there is a way to work around this restriction - if you're willing to make a few trade-offs.
The first stumbling block is deceptively complex - giving autenticated users the ability to login and administrators access to administrative functions. The Sharepoint Administrators Guide suggests using separate virtual directories - one for anonymous users and another for everyone else. Am I the only one that thinks this is completely ridiculous? How are we supposed to administer the anonymous site, add content, manage lists, etc. without the ability to login? And why on earth would we want to maintain two sets of separate content? Nonsense, if you ask me.
There should be a button in SPS that permits authenticated users to login, just like there is in WSS. In fact, after many hours of trying every other possible method (including writing my own web parts, which is NEVER a good idea - I shouldn't even be allowed to install Visual Studio on my machine), WSS provided the answer. Although I couldn't find any evidence of this actually being supported by Microsoft (big disclaimer implied), I simply copied the code from the STS site template into my SPS template pages - VOILA! Instant 'Sign-In' button.
If you don't want to go digging around in template files for it (which, I'll admit, you probably should avoid), here's the code:
WebPartPages:AuthenticationButton runat="server"
[Remember to insert opening and closing tags - my HTML editor won't let me paste them in]
There are a few caveats to this approach:
1) It won't prevent the "My Site", "Site Settings", and "Help" links from being displayed, even though anonymous users can't actually get anywhere by clicking on them. If you don't mind remembering a few URL's, you can remove the SPSWC:PageHeader web part entirely.
Tip: The Site Settings link is /_layouts/1033/default.aspx">http:///_layouts/1033/default.aspx
2) The 'Action' links don't immediately show up when you login. You'll need to view the page in edit mode using the following URL: /default.aspx?mode=edit&pageview=shared">http:///default.aspx?mode=edit&pageview=shared .
3) There is no corresponding 'Sign-Out' button.
I'm sure there are other limitations to this approach, I just haven't found them yet. Post a comment if you find any others.
The first stumbling block is deceptively complex - giving autenticated users the ability to login and administrators access to administrative functions. The Sharepoint Administrators Guide suggests using separate virtual directories - one for anonymous users and another for everyone else. Am I the only one that thinks this is completely ridiculous? How are we supposed to administer the anonymous site, add content, manage lists, etc. without the ability to login? And why on earth would we want to maintain two sets of separate content? Nonsense, if you ask me.
There should be a button in SPS that permits authenticated users to login, just like there is in WSS. In fact, after many hours of trying every other possible method (including writing my own web parts, which is NEVER a good idea - I shouldn't even be allowed to install Visual Studio on my machine), WSS provided the answer. Although I couldn't find any evidence of this actually being supported by Microsoft (big disclaimer implied), I simply copied the code from the STS site template into my SPS template pages - VOILA! Instant 'Sign-In' button.
If you don't want to go digging around in template files for it (which, I'll admit, you probably should avoid), here's the code:
WebPartPages:AuthenticationButton runat="server"
[Remember to insert opening and closing tags - my HTML editor won't let me paste them in]
There are a few caveats to this approach:
1) It won't prevent the "My Site", "Site Settings", and "Help" links from being displayed, even though anonymous users can't actually get anywhere by clicking on them. If you don't mind remembering a few URL's, you can remove the SPSWC:PageHeader web part entirely.
Tip: The Site Settings link is /_layouts/1033/default.aspx">http://
2) The 'Action' links don't immediately show up when you login. You'll need to view the page in edit mode using the following URL: /default.aspx?mode=edit&pageview=shared">http://
3) There is no corresponding 'Sign-Out' button.
I'm sure there are other limitations to this approach, I just haven't found them yet. Post a comment if you find any others.
Wednesday, June 15, 2005
Sharepoint Blog Links
Here's a great post summarizing current Sharepoint blogs. Hmmm...The SharingPoint isn't on there...was it something I said? :-)
Monday, June 13, 2005
Forms Pages and Web Parts
After struggling with the strange behavior of Forms pages (viewlist, allitems, etc.) when adding web parts, I came across this post, in which Microsoft is essentially telling us to leave well enough alone:
http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=176
If you decide to modify these pages anyway, which I will most surely do as this functionality should have been included to begin with, the best tip I can provide is not to remove the list web part from the default web part zone. Instead, simply close the part, add a new zone and place your web parts in the new zone. Be aware that this is officially unsupported so tech support won't be able to help you out if you do this.
If anybody out there is listening, how about posting some comments on features that Microsoft should be addressing in v.next? We'll pass those on and see if we get any traction.
Here are a few of my pet peeves:
* Adding web parts to forms pages (obviously)
* Nested document libraries with per-folder and per-item permissions
* Restoration of the workflow from SPS2001 (I mean, c'mon, can we please move up in versions without losing functionality?)
* Doc library permissions in SPS the same as WSS
* Removal of the WSS/SPS barrier
* Integrated recycle bin and explorer treeview for doc libraries
Any other ideas?
UPDATE: Patrick Tisseghem points out an even easier way to add web parts to list pages. Just append ?ToolPaneView=2 to the list URL. Doesn't get much easier than that!
http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=176
If you decide to modify these pages anyway, which I will most surely do as this functionality should have been included to begin with, the best tip I can provide is not to remove the list web part from the default web part zone. Instead, simply close the part, add a new zone and place your web parts in the new zone. Be aware that this is officially unsupported so tech support won't be able to help you out if you do this.
If anybody out there is listening, how about posting some comments on features that Microsoft should be addressing in v.next? We'll pass those on and see if we get any traction.
Here are a few of my pet peeves:
* Adding web parts to forms pages (obviously)
* Nested document libraries with per-folder and per-item permissions
* Restoration of the workflow from SPS2001 (I mean, c'mon, can we please move up in versions without losing functionality?)
* Doc library permissions in SPS the same as WSS
* Removal of the WSS/SPS barrier
* Integrated recycle bin and explorer treeview for doc libraries
Any other ideas?
UPDATE: Patrick Tisseghem points out an even easier way to add web parts to list pages. Just append ?ToolPaneView=2 to the list URL. Doesn't get much easier than that!
Sharepoint Search
We all know that Sharepoint search, based as it is on FreeText, can be confusing for the uninitiated or Boolean-obsessed (the latter group includes me, I must admit). Here's a great post from Fitz about Search questions during TechEd and the Ontolica product. Worth looking into if you want to replace the default search with something more user (and boolean) friendly.
Subscribe to:
Posts (Atom)