Monday, December 21, 2009

Slow Going

As you know, it's the end of the year.  Holidays are only days away.  So is vacation time.  I'm frantically finishing up 2009 work so that I can take some time off and return fresh in the new year.

So here's to a good start in 2009 on this blog.  I'm aiming to make 2010 even better.  Perhaps I'll even get a new URL to boot.

I have lots of things planned, just need to implement the plan now.  I'll be posting my learning experiences here.

As always, I look forward to your feedback.

Friday, December 18, 2009

Strange Column Names

In SharePoint 2007, you can have a column named "!".

I'm sure there are other characters you can use, as well, but this one surprised me. I suppose it is because I'm a C# developer…the "!" (or "bang") is an operator, not an identifier.

But in SharePoint (at least the 2007 version) it is a valid column name.

[Update: It appears that the column named "!" appears in SharePoint Designer as "_". I haven't tried including this column in any of my workflows, so I'm not sure how it would behave. If you have the opportunity to do so, please leave a note letting me know how it works for you. -sj]

Thursday, December 17, 2009

SharePoint “Lookup” Columns

As you may know, you can include a “Lookup” column in your SharePoint 2007 lists which, in effect, creates a reference to another SharePoint list.  This can be used, for example, if you have an address list and want to ensure that your states or provinces are all spelled correctly—just create a “StatesProvinces” list, fill it with the properly-named states and provinces, then add a reference to it in your address list. The user experience is a combo box containing the items in the “StatesProvinces” list, and they can select the one they want without having to type it themselves. [Note that you can configure SharePoint to allow multiple items from the referenced list to be selected, but that’s not what I’m focusing on in this post.]

In order to add a lookup column to your list, you first must have created the other list that you are going to reference.  You don’t actually need data in it, yet, but it does need to be created.  Fair enough.

Next, after choosing the list, you must choose which column in that other list you want to display to the user.  So in this example, you may want to have the “Title” column display to the user.

Once you save everything and add data to the “StatesProvinces” list, you have a workable solution.

But what if you want to have a workflow run against this address list which has the reference to the “StatesProvinces” list?  This is where you need to know a little bit about the inner workings of lookup columns in SharePoint.

If you know anything about database development, you probably know about the concept of a “foreign key”. In short, a foreign key resides in a table that is related to another table.  Let’s call the first table the “Child” table, and the second table the “Parent” table.  So the Child table would hold the foreign key to the Parent table.

What does a foreign key look like? Simple: it is the primary key of the Parent. [A primary key uniquely identifies a row in the database table.] It is usually a numeric type.

The same concept applies to a lookup column in SharePoint, but the execution is slightly different. You see, the actual value stored in the lookup column is the ID of the referenced list, but what is displayed to the user is the configured column from that list.

Back to my workflow scenario: if you want to manipulate lookup columns from a SharePoint workflow, and I’m talking specifically about using SharePoint Designer to create the workflows, you need to keep the foreign key concept in mind. As a test of this, do the following:

  1. Create a workflow and attach it to a SharePoint list which contains a lookup column.
  2. Create two variables in the workflow, one of type “String” and one of type “List Item ID”.
  3. Set both variables to the value of the lookup column

If you examine the contents of each variable (by logging it to the workflow history) you will see that the String variable contains the value of the configured column to display (in our example, the “Title” column), and the List Item ID variable would have a number (which corresponds to the ID column of the referenced list).

If you are going to change the value in the Lookup column via a workflow, you must set its List Item ID (number), not the displayed value(text).  You will wonder why your workflow isn’t working correctly if you don’t follow this advice, especially if you are new to creating SharePoint workflows using SharePoint Designer.

I hope I have helped someone out there with this advice.

Wednesday, December 16, 2009

Mentoring

I got my start in programming from typing lines of BASIC in the backs of magazines into my Commodore 64.  I didn’t really understand what each line did at first, but I dutifully typed in the lines, just to see the finished product in action.

I got my professional start in programming when I was a student at Georgia Tech.  When I enrolled at Tech, I indicated that I wanted to be part of the cooperative education plan, which meant that I would attend classes for one quarter, then work at a  company for one quarter, then repeat.  It took me a little over a year to find a company that would hire me as a “co-op student”, but once I did I stayed with that company until I graduated from college.  In fact, that company hired me when I graduated, and I went to work for them full-time.

But while I was still a co-op student, I often felt that I learned more while I was on the job rather than when I was in school.  I think the reason for this is that I was very fortunate to have found a job where there were many people eager to share their knowledge of programming with me.

In a nutshell, I was surrounded by mentors.

I have very fond memories of those days—people smarter than myself showing me how things got done in the “real world”.  As a result, I often take the time to teach others things that I have learned, now that I’ve been a professional developer for nearly 20 years.

I guess that’s where this blog is coming from.

In my current role as a consultant, my coworkers are all very knowledgeable about software development, so I don’t often get to mentor them.  But on the rare occasion that I get to explain something, or show something that I know, it really gives me a sense of satisfaction when I can see that I’ve made a difference—when the other person has that “a-ha” moment and has learned something.

I think we can all learn from each other, and I think that there is great value in continually learning new things.  My company doesn’t currently have a mentoring program, but I’m considering suggesting that they start one.

What about your company?  Do you have a mentoring program of sorts?  If so, what’s it like?  Can you quantify the value of it?  Is it company-supported?

I’d be willing to collaborate with you (Google Wave, anyone?) on a “Mentoring Charter” of sorts if you want to start a similar program at your company.

Tuesday, December 15, 2009

What Do You Want From Me, Anyway?

I started this blog a week or so ago, and I have filled the first few entries with mainly SharePoint-related information.  Mostly from my current project.

But I know lots more than just SharePoint.

I can write about patterns.  .NET, C# in particular.  Middle-tier development.  Consulting.  Project management.

But I don’t want to just spout things out without some feedback from you, my dear reader.  [And, yes, at this point I may be the only reader!]

Please leave me a comment to let me know what you’re interested in reading about.  I know that this blog will take shape over time, and will most likely track what I’ve been working on, but there’s nothing stopping me from deviating from that pattern and posting something that you’re actually interested in.

Like how I got laid off twice within one year and each time landed a new job within 1 1/2 weeks.

Or perhaps you’d like to know how to make money by blogging?  [Sorry, but I haven’t figured that one out, yet.]

In any case, do leave a comment, no matter when you are reading this.  Meaning, if the year is now 2012 and you’ve stumbled upon this post because you’re preparing for the world to end on December 21st, please leave me a message.  Note that I don’t think it will end, but the crustal displacement theory sounds plausible.

You won’t find what you’re looking for here unless you ask!  So ask away!

Monday, December 14, 2009

Let Me Introduce Myself

I’ve been considering starting a technical blog for some time—the technical posts on my personal blog just felt out of place.

And so “SwearPoint” was formed.

My plan for this blog is to share some knowledge I’ve gained about developing software professionally for over 20 years.  I am a web developer who got his start way back in the ‘80s on my Commodore 64.  I actually still have that computer down in the basement.  Haven’t turned it on it several years.  Perhaps a decade or more!  Not sure if it still works, even…

I would spend hours typing in BASIC programs in the back of magazines such as Home Computing (at least I think that’s the name…it’s been quite a while!), only to find that they didn’t work.  Then the next month they would publish the corrections to the code. Anyone else remember doing that?

I didn’t necessarily learn “good programming skills”, but I at least fostered my love for programming.

After graduating from high school, I attended the Georgia Institute of Technology, lovingly referred to as Georgia Tech.  I pursued a bachelor’s degree in Information and Computer Science, which I obtained in 1992.  During that time, I was involved with the cooperative education plan, in which I would attend classes for a  quarter and then go to work at a company for a quarter.  In hind sight, this was a very smart thing to do.  Not only did it introduce me to what working at a company is like, but I met many people who had a profound influence on my professional life.

Plus, that was the only job offer I received when graduating from college.  If you’ll recall, that was right before the .com boom, and programming jobs weren’t quite as easy to come by, so I felt blessed to have landed a job at that time.

Fast forward a few years.  One of the managers at that company contacted me a couple years after I left. He told me that he was starting a company and asked if I would be interested in working for him again.  I said, “Yes”, and thus started my 5 years at an upstart company (or “start-up”, if you prefer).  We weren’t exactly doing “web stuff”, which was the big focus at the time (1995), but we had good funding, and I had the chance to work with some very smart people again (most of the staff came from my first job).

Since then, I have mainly been a consultant working with Microsoft technologies such as (you guessed it) SharePoint.  I’ve also worked with BizTalk Server, Content Management Server (anyone remember that one?), and SQL Server.  I am quite proficient with .NET and the C# language (and to a lesser degree VB.NET).  My current passion is Silverlight 3.  I attended a “Firestarter Event” back in August for Silverlight 3, and there was definitely a fire started.

I’m only working on Silverlight in my spare time, thus the lack of blog posts about it so far.  Most of my time these days are spent dealing with SharePoint.

I foresee this blog being a reflection of my current experiences mostly, with occasional forays into software development practices in general, consulting tips, and possibly some plain ol’ nostalgia (especially after I get that Commodore 64 hooked up again—I’ll be interested to see if any of the 5 1/4” floppies are still readable).

So there we are—that’s my introduction.  If you happen across this post, please let me a comment.  Please click the advertising links!  :-)  After all, I have 4 kids to feed (and to put through college some day!).

Thank you for reading.

Friday, December 11, 2009

SharePoint Exception Occurred 0x80020009 (DISP_E_EXCEPTION)

My, oh my, will wonders never cease?

Have I mentioned how much I love SharePoint recently? Let me count the ways. And believe me, there are not 0x80020009 ways. In fact, I can count the ways on one hand. Sometimes no hands! :-)

For some reason, one of my SharePoint lists will not display in the customized Datasheet view that I created. The others custom Datasheet views on my other lists are working perfectly.

So I “Googled with Bing” for a solution and found that, lo and behold, I am not alone in the universe. Many, many more people share my woes with this error.

Some people mention that all that needs to happen is an IIS reset. Well that won’t work for me, since I’m at a very large corporation and I don’t know who the admins are nor do I even know where they are.

Some people mentioned problems with their custom web parts. No, no web parts here. The SharePoint site I’m working on does not allow custom code to be deployed to it. All I have to work with is SharePoint Designer.

Other people mentioned that it was the load balancer which was not configured properly.

Are you kidding me? One error has so many different causes? Do you think someone on the SharePoint team would think to provide us, the lowly end-users, with more of an explanation of where to look for the problem? (Before you mention reading log files or anything similar, keep in mind what I mentioned above: I don’t have access to the servers. I don’t even know where they are!)

Nice. Even though I initially found comfort in knowing that other people have encountered this error and have, in fact, found solutions, it seems that I may be all alone in this particular case.

I tried re-creating the view, just in case something mucked it up. You know, like those stray gamma rays that knock various electrons out of their paths inside your PC’s CPU which cause programs to run amuck. As you probably guessed, it didn’t work.

In fact, as of this writing, I still do not have a solution for this problem. I apologize if you have read this far expecting a solution. Or perhaps my prose caused you to skip ahead, which is good for you. The prose was good for me—it allowed me to vent some steam.

[I ended up deleting all items from the list, and the view started working. Or at least I no longer get the exception. Of course, there were no items in the list for it to display! Once I loaded it with data again, I started getting the same error. Other similar views don't give me this error. Perhaps it's a data issue.]

Thursday, December 10, 2009

How Can You Tell if You Found a Valid List ID?

I’m currently working with several different custom SharePoint lists.  Some of the lists have references to other lists, via a “Lookup” column.  For example, a book might have a reference back to the library it came from.

Sometimes I only know the name of the library, and I want to be able to set a reference to it on the book’s list.  So I retrieve the library’s ID using the name of the library.  SharePoint Designer dutifully warns me that I’m not looking up the value using a unique ID, and that it will just give me the first one it finds.  I’m OK with that, since I control the names and I know that they’re all unique.

But I’m only human, and sometimes I don’t have a library name that exists in my library list.

In those cases, when I log the contents of the list ID variable into which I placed the data, it shows me “0”.  [That’s the number zero, not to be confused with a lower-case “o”.  I’m considering changing the font for this blog… -sj]

As it turns out, this is the way you can tell if you have a valid list ID.  Valid IDs start at 1, I presume, and invalid IDs are all zero.

[It’s easy to tell if you have a bad reference to another list when you retrieve string values, since they show up in log messages as “????”.]

Wednesday, December 9, 2009

Workflow Comparisons Aren’t Always Accurate

I have a SharePoint workflow, developed with SharePoint Designer, which is supposed to compare values in the list it is attached to against values in another list, and copy the other list’s values if they are different.  I kept noticing, via a workflow history log message, that the workflow was copying values every time it ran, even though in another log message for the same workflow instance it showed me that all the values were the same.

As it turned out, I was comparing a string value to a list ID.  Even though they both printed in the log message exactly the same (and so were “equal” in my eyes), SharePoint saw them as different values.

The fix was to copy the list ID value to a string variable, and then compare the two values as strings.

[As a side note, what made this worse was that I had a second workflow which would run when anything was changed on the list.  It would then update a value in the list, which would then cause the buggy workflow described above to run again.  For the astute readers, this meant that the two workflows attached to the same list would cause each other to run infinitely.  It pretty much brought the site to a halt!]

Tuesday, December 8, 2009

Creating a Custom SharePoint Permission Level

In yesterday’s post, I mentioned custom SharePoint permission levels.  Here is how to create one.

From the landing page of your site (default.aspx), click on “People and Groups”, then click on “Site Permissions” under “All People”. Click on the “Settings” menu, then select “Permission Levels”.

Now click “Add a Permission Level”.  Give your custom permission level a name, an optional description (I find it useful to describe the permissions that this permission level grants, and possibly which assumed permissions that this level does not grant).

Now is the fun part.  You get to choose which permissions to grant, and which to exclude, for this permission level.  There are many different permissions you can choose from.  They are described in this Office Online page.

Monday, December 7, 2009

SharePoint Permission Tip

If you use the “Collect Information from User” action in a SharePoint Designer workflow, and you have your default site permissions set only to “read” for the user you’re planning on collecting information from, you probably won’t get very far.

You’ll want to grant at least “Edit” permission to the user (or group that the user is in—that would be a better practice) on the Task list.  This allows the user to access the task that gets assigned to her so that she can complete her work.

Here’s how to accomplish this:

  1. Click on the “Tasks” list on the Quick Launch pane if it is available.  Otherwise, click on “Lists” first, and then click on the “Tasks” list.
  2. Click on “Settings | List Settings”
  3. Click on “Permissions for this list”
  4. Click on “Actions | Edit Permissions”
  5. Click “OK” on the resulting dialog box (“You are about to create unique permissions for this list…”)

Now you can modify the permissions for the users and groups listed.  If you don’t see the users or groups you want to configure for the Tasks list, you can add them here.

I must note that I created more granular permission levels on the site I’m currently working on, so I can choose to grant “Read” access or “Edit” access individually.  If you only have the out of the box permission levels, you’ll want to ensure that your users have at least “Contribute” access to the list. Of course, if you only have the out-of-the-box permission levels and you haven’t created custom levels then you wouldn’t have the problem I had which prompted me to write this post.

I’ll cover creating custom permission levels in a future post.

Friday, December 4, 2009

SharePoint? No, SwearPoint!

[Cross posted from my personal blog. -sj]

del.icio.us Tags: ,,

Product-SharePoint2007 I’ve been working on a SharePoint project for work for the past few months, and I’m getting close to the “go-live” date.  Actually, it’ll go live whenever I’m “done” (whenever that will be…).

But that’s beside the point.

The point is that I’m becoming less and less impressed with SharePoint as a development platform.  And I didn’t start out with a great love for it in the first place.

Perhaps it’s because I’m constrained to only using SharePoint Designer.  No .NET code allowed on the site I’m working on.  That bums me out right there, since I consider myself a great .NET developer.

Most of my work has revolved around customizing SharePoint lists, and using SharePoint Designer to create custom workflows to support the operations of the team I’m developing this for.  Not necessarily hard, but the requirements have been challenging to implement, to put it nicely.

One main requirement, as it turns out, isn’t really possible to implement fully in SharePoint, at least in a nice way.  There are two groups of people who are responsible for different items (a.k.a. “fields” or “columns”) in a list.  One group, let’s call them “Group A”,  doesn’t want the other group (“Group B”) to be able to modify Group A’s fields.

Now let me stop right there!  I understand that SharePoint is a “collaboration” tool, so preventing users from collaborating just doesn’t jibe with the core of SharePoint.  That’s pretty much the crux of the problem.

If it were possible to set permissions on the field level, this blog entry would not be needed.  But it is not possible to restrict access to only certain fields in a list to a certain group of people, so I had to think of ways to enable this functionality, and the way I came up with is sub-par at best.

I ended up creating 3 lists: one for Group A, one for Group B, and one which shadows Group B’s list.  Then there are workflows which copy Group A’s fields in Group A’s list to Group B’s list, and Group B’s fields in Group B’s list to Group A’s list.  The “shadow copy” list is there to prevent the workflows from running in an infinite loop—the items are only copied back to Group A’s list if they are different between Group B’s list and the shadow copy list.

As it turns out, this is not without problems, since if someone in Group A modifies one of Group B’s fields in Group A’s list (did you follow that?) then it will remain out of sync with Group B’s list, since Group B’s fields aren’t copied from Group A’s list to Group B’s list.

As it turned out, thankfully, this wasn’t as big of an issue for this particular solution (whew!).

It was my intent to set permissions on the lists such that people in Group A only had read access to Group B’s list, and vice versa.  However, as it turns out, the workflows will fail to copy data since they run as the user who initiates the change to the list.  So when a Group A person changes an item in Group A’s list, the workflow tries to copy that change to Group B’s list but can’t because Group A only has read-only access to Group B’s list.

So I thought I could change the permission to allow Group A to edit Group B’s list, but then just set the “Hide from browsers” property on Group B’s list so that Group A couldn’t find it when browsing the site.  So instead of preventing a modification of Group B’s list through the use of SharePoint Permissions, I would be preventing the modification of Group B’s list by making it very hard to find the list.  Problem solved!

Not.

Once again SwearPoint, er, SharePoint worked against me, and here’s how:

If you set the “Hide from browsers” property on the list, it does, in fact, hide the list from site when you click on the “Lists” or “All Site Content” links in SharePoint.  HOWEVER, it also hides the list from workflows!

[UPDATE: The list’s name is the only thing hidden from the workflow.  The error I was seeing which led me to the previous conclusion was due to a user-error (and, no, I wasn’t the user!).  The workflow continues to operate successfully if the referenced list is hidden.]

So my final solution still has three lists, one for each group and a third to ensure that the workflows eventually stop, and each group can see the other group’s lists.  Not at all what I set out to accomplish!

It’ll just have to be a training issue to keep each group out of the other’s list.

So much for collaboration (at least in this project).