The other day I was trawling the knowledgebase for some code to quickly look up the primary organization record for a constituent. It is the sort of thing that I could have worked out myself very easily but sometimes it is just convenient to see if Blackbaud already have the code available.

I found exactly what I was looking for, or so I thought. KB BB54132: How to write code to find the Record ID for the Primary Organization relationship. Seeing the solution reminded me of the time I first took over the reigns of RE customisation developer at my first position in San Francisco.

I had to develop some code to do something similar. I thought that I would just copy some existing code that worked fine so that I could loop around all the relationships on the constituent record.

For Each oOrg In oConstit.Relations.Organizations

This is what I wanted to write but when I type in:

For Each oOrg In oConstit.

There was no Relations to be found in the intellisense dropdown. I thought that this was strange as everything worked fine with the existing code. I spent several days trying to work out what I was doing wrong. I found similar examples in the knowledgebase but to know avail. It was only after consulting with Blackbaud support did I found out about COrganization and the new COrganization2 and that they work very differently.

The new functionality was introduced, I believe around 7.5 (we did an upgrade to 7.5 soon after I started). At that point the collection of relationships on the constituent was made obsolete. It could still be used for backwards compatibility but it would not appear in intellisense.

Let me just say that the equivalent code applies to individuals as it does to organizations so they can be used interchangeably in this context.

The relationship records were changed from being child objects, like constituent codes or notepads, to being top level objects like a cross between constituent objects and participant object. You could open up a COrganization2 object with just its system id. In the GUI however it would only ever reside as a child object. This is just the same way as the participant that only resides on a constituent or in an event. (This is apart from when open it from a query when it manages to stand alone). Unlike the participant you are not able to access the collection of organizations through code directly from the constituent.

Instead you have to initialize a collection of organizations giving the constituent id if you want to restrict them to the specific constituent.

I was told that this new method improves performance when dealing with larger numbers of relationships. It took some time to get used to especially when have to deal with spouses but there are a number of convenience methods available.

All this may not sound much of a deal but to somebody starting out looking at code being mixed from old and new methods it was really confusing. To find this knowledgebase solution still appear using the old method is bad considering this technique became obsolete so long ago now ever since the release of 7.5. You would have though that this may have been solved since 7.5 was released