Tuesday, December 08, 2009

"There was an error retrieving data to display in this Web Part." with CQWP

I'm back with a new error... I knew it wouldn't be long.

This one is tricky because the error: "There was an error retrieving data to display in this Web Part" doesn't really tell me much of anything.  I also went into the 12 HIVE/LOGS and found little success in there as well.  We have things output as Verbose, and running Sharepoint on 3 domains makes it tough to find what you need.

So I went back to google and searched a bit more and finally came across: http://blogs.msdn.com/ecm/archive/2006/10/25/configuring-and-customizing-the-content-query-web-part.aspx

I went through the comments and found a clue to what might be the problem: "Most likely the error is caused because the lookup column allows multi choices.  Multi choices is not supported by the Cross List Query [XLQ] which is the data source of the Content Query Web Part" - Adri

Thanks Adri, I saw this on another page as well but I really didn't know where to look with an excess of 1000 sites being in existence.  I also noted, this error was hit or miss.  I would get it on certain page, or when I was filtering/grouping on certain criteria.  Most notably, filtering by 'Assigned to = Current User'.

Then another comment on that page (actually it was preceding): "I have just found that by grouping the items by another lookup column on that content type, the Portfolio lookup is displayed. As soon as I take this grouping off I get the error message as above. How strange." - Sam

That pretty much solved it for me.  Obviously, group on the filtered item that is causing the issue. And.... BOOM it worked.  Also to note, if you're displaying that field, 'assigned to' in my case, then you won't have an issue and won't have to group on it.  This can be a problem in some SQL code too, which makes sense because Sharepoint [lists] is an abstraction of SQL (more or less right?).

This error was fairly hard to solve because you don't have much info to work with.  I'm hoping someone else who happens to be blessed with this error can stumble across my blog!

One thing to note: My case is a more rare case.  The most typical cause of this error is that your XSL or outputted HTML is malformed and needs some debugging.  I knew that this had been working perfectly at one point, so there was something else going on. Definitely check the XSL first, though.

Wednesday, December 02, 2009

Branding and Sharepoint Permissions

Hello again!  I'm going to share with you a tricky little situation I got into today.  Maybe not a huge issue for a Sharepoint pro, but was very frightening for me. I'm going to preface this post with a little story to set the mood.  I'm not looking for a ton of sympathy but I just want to put the project I'm working on into perspective for my readers:

First off, I'm working in a LARGE corporate environment that is migrating all business practices to Sharepoint.  WOOHOO!  Easy right?  Well I guess that is why I have a job right now... no one else wants to do it, and we've had two people quit leading up to my hire (within months of eachother none the less).

This project is almost two years over due now, so no rush... we'll be careful this time and try not to fall into the same holes as we have in the last two years.  I've only been here a few months but I can see the wreckage and leftovers from various consultants and ex employees...

Did I mention we don't have a test environment?

Or that I'm the ONLY developer, .NET and/or Web?

So I'm working on Branding, which is how I spend most my days here.  That is, when I'm not being a Sharepoint admin, or publishing content, or running training seminars.  Not bad for a Junior C# developer.  And I'm branding still.  On 3 different MOSS web apps, with 3 different themes of branding.  Javascript running in masterpages doing god knows what?  Look at that!! I take it out and the page runs faster and smoother.  And I dont have any weird disappearing text.  Wonder why that was there in the first place?  I'll never know though, because the amount of original developers still on the project is ZILCH.

Ok enough rambling.  Here is the educational portion of my post.

Everything I've been working on is fairly stable, looks a little better than myself with a hangover, and runs a little smoother than the original implementation of webparts, css, html, etc...

I'm pretty happy and proud of my work thus far.  We're getting ready to permission about 2-3000 users when I get the bright idea to test these permissions with a view only permissioned account.  Brilliant! So I create the account in active directly, permission it up, and go to a landing page on one of our domains. EPIC FAIL.  My "Zone Tabs" web part is all F'd up.  My custom Content Query Web Parts are erroring out. Hmmm...  Wheres the nearest cliff in Manhattan?  Well I guess theres the A train.

I double check my permission 20 times.  Experiment readding webparts, pointing the CQWPs to lists directly.  Tweaking some other crap.

Then it hits me: Don't you have to Publish Master pages in the Master Page Gallery, then Approve them before regular users can see the changes?  Well yea.  So I double check that, and among the 3 domains I missed approving one.  Well turns out that isn't the problem anyway.  Turns out, my custom .XSL files for my CQWPs need to published as well.  As do a few CSS files I had laying around in my Styles Libraries.  GRRR

So after lots of frustration and near suicidal moments, I was able to remedy this.  (Note to readers:  I am not suicidal, but I am a binge eater, drinker, and sleeper.  So there may have been a bit of that.  I am fairly stable overall.)  Lastly, be sure to PUBLISH and then APPROVE everything in your base Galleries, ie MasterPage, CSS, XSL... It will save you a lot in the end!