Often with the applications we build on sharepoint it would be much easier to analyse the data if we could do a straightforward SQL join between two lists, just as you would with two tables in SQL, but, alas, this is not catered for out of the box. I have managed to do it with a DVWP and data sources in SharePoint Designer but this was only really useful on simple and small amounts of data. So I was quite ecited by this project I have stumbled across on CodePlex yesterday - SLAM. It looks to take the list data in sharepoint and copy it out to SQL so that you can then run standard SQL queries against it. There seems to be some management built in as well, so very promising. I haven't had a chance to try it out yet, but will certainly give it a go next time we need to do some reporting on SharePoint list data.

Quote from their site:

Most developers who have used SharePoint as an application development framework have run into the realization that SharePoint is NOT a relational database. In fact, the accepted wisdom is if you need relational tables, use ASP.NET/SQL straight-up, not SharePoint.

Enter SharePoint List Association Manager (SLAM). In short it allows you to define relationships (one to one, one to many, many to many) between SharePoint lists (or Content Types) and then leverage those relationships in webparts or custom field types using familiar and straight forward SQL queries.

Find it on Codeplex at http://www.codeplex.com/SLAM.

A question I've been asked a couple of times recently is 'how to hide menu items on the list toolbars'

The problem faced by the clients was to hide the 'Edit in DataSheet' and 'Open in Explorer' commands.

The first attempt was to use a HideCustomAction element in a feature, this didnt work, so we had to look for an alternative solution.

Looking on the web provided two approached. Scott Hillier has a web part that can be placed on the page whcih will achieve the trick, but this would require modifying each existing library with the web part, plus ensuring that future library templates had the webpart definition applied.

Dipper Park has an alternative approach usig a custom control to hide complete sections of the menu. This was closer as it allowed all lists / libraries to be controlled.

In the end, we took the second option and created a custom control. The control contains a section of javascript to inspect the page objects & remove the individual menu items.

The script block was relatively simple & could be improved in future....

[code:js]

window.onload = HideMenuItem; 
function HideMenuItem()
{

var menuNodes = document.getElementsByTagName("menu");
var targetNode;
var targetViewNode;
var viewExplorerNode;
var dataSheetNode;
var explorerNode;
for (var i = 0; i < menuNodes.length; i++)
{
 
 var menuNode = menuNodes[i];
 if (menuNode.childNodes.length > 3)
 {
  if (menuNode.childNodes[0].id.indexOf("EditInGridButton") != -1)
  {
    targetNode = menuNode;
    dataSheetNode = menuNode.childNodes[0]; //is always node 0
    explorerNode = menuNode.childNodes[2]; //is always node 2
  }
  if (menuNode.childNodes[0].id.indexOf("DefaultView") != -1)
  {
   targetViewNode = menuNode;
   viewExplorerNode = menuNode.childNodes[2];
  }
 }
}
targetNode.removeChild(explorerNode);
targetNode.removeChild(dataSheetNode);

targetViewNode.removeChild(viewExplorerNode);

[/code]

After the script has run, the menus would look as per the following two images

It's important to note that in the above example, we are removing childNodes 0 & 2, really we should probably be checking for the location, rather than assuming they are 0 & 2

This could be taken a step further and wrapped into a feature. If a feature were to add some HTML onto the page (e.g. another menu item such as 'Print List') then the script could check for the existance of this menu item, then remove the childNodes.

The complete .ascx control is in the attachment

HideToolbars.zip (1.06 kb)