Occasionally, SPD will get out-of-whack with reality. For example, it will report that a file is checked out when it's not. Or when you attempt to save a file, it will report that a newer file exists and fall into an endless loop of dialog boxes asking you what to do.
The fix is clearing out the local caches residing on your computer.
Here's a good explanation of how.
Wednesday, June 25, 2008
Tuesday, June 24, 2008
New U2U Caml Query Builder Release
I just noticed this new release.
http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=28
Sweetness!
http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=28
Sweetness!
Monday, June 23, 2008
Using Formulas in Calculated Fields
Every three or four months, I have to use a formula in a calculated field. And every three or four months, I spend 5 minutes searching for some common examples because I've totally forgotten the syntax.
At least now I won't have to search far for the link.
http://office.microsoft.com/en-us/sharepointtechnology/HA011609471033.aspx
At least now I won't have to search far for the link.
http://office.microsoft.com/en-us/sharepointtechnology/HA011609471033.aspx
Thursday, June 12, 2008
Publishing Page Settings Broken By Missing User ID
I recently tripped across an issue with MOSS publishing that caused considerable head scratching. Because the scenario that gave rise to this is (probably) quite rare, I doubt many people will encounter this in “real life”. So with that in mind, here’s what happened.
My current assignment is on a project where the previous consultants were let go. When the previous firm left, the only deliverable they gave to my client was a content database detached from the consultant’s MOSS development environment. No features. No solutions. Just a database.
This method of delivery had the unfortunate downside of leaving occasional “loose ends” in the database such as broken page layout links and references to user ids that don’t exist in the client’s environment.
Now the problem of broken page layout links arising in certain circumstances is well-known. Someone has even written a STSADM extension to deal with the problem: (http://stsadm.blogspot.com/2007_08_01_archive.html)
However, the user ids that no longer exist in the target environment can cause considerable consternation if they are removed from the MOSS “people and groups”. For example, if a “bogus” user id is deleted from the system, you’ll no longer be able to view the “page settings” for each publishing page that was originally created by the now deleted user id. (The MOSS stack trace clearly indicates that it’s looking for the now missing user id.) As far as I know, there is no “easy code fix” like there is for broken page layout URLs because the “created by” field associated with each page appears to be read only.
So, what to do about it? The only solution I found was to follow the following steps:
-- create a new page
-- copy the content in the various page layout fields from the old “broken” page to the new page
-- save the new page
-- delete the old
-- rename the new page to use the old name.
All this can be done via the browser (no need for SharePoint Designer). The process could also be automated with C#, but given the low number of “legacy” pages that we had, we just decided to stick with the manual process.
My current assignment is on a project where the previous consultants were let go. When the previous firm left, the only deliverable they gave to my client was a content database detached from the consultant’s MOSS development environment. No features. No solutions. Just a database.
This method of delivery had the unfortunate downside of leaving occasional “loose ends” in the database such as broken page layout links and references to user ids that don’t exist in the client’s environment.
Now the problem of broken page layout links arising in certain circumstances is well-known. Someone has even written a STSADM extension to deal with the problem: (http://stsadm.blogspot.com/2007_08_01_archive.html)
However, the user ids that no longer exist in the target environment can cause considerable consternation if they are removed from the MOSS “people and groups”. For example, if a “bogus” user id is deleted from the system, you’ll no longer be able to view the “page settings” for each publishing page that was originally created by the now deleted user id. (The MOSS stack trace clearly indicates that it’s looking for the now missing user id.) As far as I know, there is no “easy code fix” like there is for broken page layout URLs because the “created by” field associated with each page appears to be read only.
So, what to do about it? The only solution I found was to follow the following steps:
-- create a new page
-- copy the content in the various page layout fields from the old “broken” page to the new page
-- save the new page
-- delete the old
-- rename the new page to use the old name.
All this can be done via the browser (no need for SharePoint Designer). The process could also be automated with C#, but given the low number of “legacy” pages that we had, we just decided to stick with the manual process.
Thursday, June 5, 2008
Recursion in Business Programs
Lately I've been listening to the podcasts at stackoverflow and have been really enjoying them. But, I chuckled a bit while listening to podcast #3. During that episode they get into a discussion of Computer Science vs. Software Engineering and it's during that discussion that Jeff and Joel come to the consensus that outside of systems-level programs like (for example) writing a compiler, recursion is basically useless in garden-variety business apps.
I laughed because just that day I had written a recursive method to traverse a tree containing pages of a medical encylopedia in order to import the pages into an equivalent tree of SharePoint publishing sites. I mean, you don't get much more "business-y" than SharePoint!
So while I agree that recursion is a rare bird in business apps, it does come in handy every now and then.
I laughed because just that day I had written a recursive method to traverse a tree containing pages of a medical encylopedia in order to import the pages into an equivalent tree of SharePoint publishing sites. I mean, you don't get much more "business-y" than SharePoint!
So while I agree that recursion is a rare bird in business apps, it does come in handy every now and then.
Subscribe to:
Posts (Atom)