There are a lot of misconceptions about what the Raiser’s Edge API is and what it can be used for. A lot of organisations are put off by the fact that the API is expensive to purchase on top of the fact that they may have to cover the cost of development too.
Tag Archives: API
Working with Attributes
Attributes are a common tool within The Raiser’s Edge. I know of no organisation that does not have any constituent attributes. Yet the API treats them rather peculiarly. Unlike an import where you specify the category and description the Attribute record doesn’t store the category in plain text. This would be OK if you regularly referred to attributes with their code table id but you do not. They are referred to using the category text.
Sometimes the API is just not enough
Sometimes I cannot quite get want I want from Raiser’s Edge using the API. Or if I can it is very slow to get the information. For example when you get a collection of top level records, say constituents, there are filter objects which work well, you can also use the custom where clause which works when there is not a filter parameter. However what do you do when you want a combination of different areas of The Raiser’s Edge all combined into one selection.
A Non-production database
There has been some discussion on the Blackbaud forums and on the Blackbus forum about using a second non-production database. This article will highlight some ways of doing this.
Before I begin I want to categorically state that if you believe what I am writing in this post breaks your Blackbaud contract then do not do it. A long time ago I was told by Blackbaud that it was perfectly acceptable and I hold by that but I know that others who have been told otherwise (including various support people at Blackbaud who will give you a different ruling depending on who you speak to!) Just to reiterate I am in no way encouraging you to break the law!
Continue reading A Non-production database
Checking security
With the API it is very common that you will want to make a change to an object. Say you have some code that adds a pledge to a constituent when an event registrant is added. The user running the code may well have the rights to add an event registrant (participant) but they may not have the rights to add gifts.
Continue reading Checking security
C++ and the API
I am not sure how many people out there would even dream of using C++ together with the API but considering there really is no documentation out there for this type of project I thought that I would try to put together some notes on how it is possible. The API is COM based and there is no reason why you cannot use C++ (just possibly more of a question of why you would ever want to). This posting assumes a basic knowledge of C++.
Firstly why would you every want to use C++. Sometimes this is a necessity. You may be using old C or C++ legacy code that you want to integrate directly with the API. In which case here are a few tips to get you started.
Continue reading C++ and the API
Close down or crash
One of the basic principles that you need to learn when you start programming the API is that for top level object (constituents, gifts, funds, participants, etc) whenever you initialize the object you need to close it down. This is not too difficult to remember to do and you are swiftly reminded when you close the plug-in or the application (it crashes).
However there are some exceptions to this. When you loop a collection of top level records e.g. CGifts, using the for each construct you also have to close down the individual item. This goes against the above logic as you did not initialize it.
Continue reading Close down or crash
Filtering on Gifts
One common complaint about the API is that it is poorly documented. I found that out myself when I went to use the gift filter object. This is a powerful object that allows you to filter a collection of gifts by its properties. The filter object has very many properties but very few of them are documented. There is one knowledgebase article and one FAQ entry showing how to use it.
Continue reading Filtering on Gifts
The case of the disappearing form
One of my most long standing problems that I have had with RE:VBA is showing a form modally. This in itself is not difficult but as soon as you move away from Raiser’s Edge, bring up another window in front of the modal form and then go back to Raiser’s Edge, the modal form has disappeared. Because the form is modal you are not able to access the underlying window (let’s call this the parent window). This is a pain as the only way to bring it back is to place another window over the parent window and then minimize it. This is not hard to do but it is harder to explain to users and not very intuitive.
Six ways to name a record
One thing that can make the API confusing is its inconsistencies. Take for example the task of referencing the constituent object’s system id from another data object. The constituent system ID is used uniformally throughout to connect a constituent to its child objects such as, gifts, actions, aliases, solicit codes, etc. The naming convention however is not uniform. The objects have fields which are referenced in the following format:
OBJECTNAME_fld_FIELDNAME
so that an action references the constituent that is tied to it by the following:
oAction.Fields(ACTION_fld_RECORDS_ID)