One thing that’s been a bit exciting as we work with clients implementing our Raiser’s Edge importing tool is seeing email addresses becoming an almost-defacto ID. Yes it’s possible (even likely) for a constituent to have multiple email addresses or to change addresses, but at least 1) they are globally unique and 2) the constituent is likely to remember at least one of them. As online giving continues to grow, the fact that Import-O-Matic can use email addresses for matching constituents has been huge in helping organizations reduce duplicate constituent records. I am surprised that they have not updated RE7 to offer “email address” as a duplicate criteria.

I wonder if RE8 will include a tie-in for OpenID?

Jeff

Thanks for your suggestions. I will definitely give it a go. One workaround would be to copy an existing batch and change the values. The problem is that no two batches are alike. The number of gifts in a batch vary so while I could copy a previous batch, or even set up a batch template in the GUI in order to copy that batch over, I would have to ensure that there were a large number of gifts present to cover the number that I may require in a later batch. I would have to loop through it and then change the values from the template batch to the new batch. Of course this could work but it is really long winded workaround which really should not be necessary.

Heather, I have, unfortunately, not tried to write the check number to a batch. It does sound like a similar case. Are you able to populate it through the GUI?

David

When I try to populate GIFT_fld_Check_Number it doesn’t seem to actually populate (no errors, it just never shows up in RE despite definitely being populated in my debug checks). When I try to populate GIFT_fld_Description, it throws what to me appears to be an entirely unrelated error about a column that I’m not attempting to access. BATCHAPI_fld_DESCRIPTION, on the other hand, works beautifully.

Have you tried using these fields at all? Any thoughts? I wish there were more documentation on this stuff.

Thanks much

-Heather

It seems to me that the biggest issue with the RE API is that it is not really ready for the .NET framework as a whole whatever language you use, you have to jump through hoops to make it work the way you expect and even then it chews you up and spits you out for being a nice .NET developer simply because you talk C or some other .NET pre dated technology.

Between you and me, the problem is that updating the API doesn’t make money, and that’s all that Blackbaud are interested in, if someone could “sell the monetary advantages of .NET” to Blackbaud they would likely jump on it in an instant !!!

I guess the other way to look at it is that the sort of customer base they have know of no other strong competitor at the moment that can deliver this type of thing effectively for a reasonable price so they have their little market cornered so to speak, introduce some competition and this whole issue could simply go away as a gimmick sold to developers in order to keep the administration and maintenance teams on side.

It’s likely just a matter of time as I see it, these things ultimately always are

Private Sub CreateBackupBatch(ByVal sSrcBatchNbr As String)
Dim oSrcBatch As CBatchAPI = New CBatchAPI
Dim oBkpBatch As CBatchAPI = New CBatchAPI
Dim oBkpTempRecords As CTempRecords

‘ Create a new, empty batch based on the design of an existing batch
CreateBatchFromTemplate(sSrcBatchNbr, sSrcBatchNbr & ” BKP”)

oSrcBatch.Init(coSC)
Try
oSrcBatch.LoadByNumber(sSrcBatchNbr)
Catch ex As Exception
Throw ex
End Try

oBkpBatch.Init(coSC)
Try
oBkpBatch.LoadByNumber(sSrcBatchNbr & ” BKP”)
Catch ex As Exception
Throw ex
End Try
oBkpTempRecords = oBkpBatch.TempRecords

oBkpBatch.Fields(EBatchAPIFields.BATCHAPI_fld_BATCH_NUMER) &= ” ” & Now.ToString
oBkpBatch.Save()

Dim oSrcBatchFields As CBatchFields = oSrcBatch.BatchFields

‘ Copy all batch rows except the template row from source to target
For Each oSrcTempRec As CTempRecord In oSrcBatch.TempRecords
If oSrcTempRec.Fields(oSrcBatchFields.Count + 2) “0″ Then
‘ BD (below) is an import alias for Blackbaud.PIA.RE7.BatchData,
‘ all other Batch API classes are referenced from Blackbaud.PIA.RE7.BBREAPI
Dim oBkpTempRec As BD.CTempRecord = oBkpTempRecords.Add()
oBkpTempRec.DataObject = oSrcTempRec.DataObject
For Each oSrcBatchField As CBatchField In oSrcBatchFields
Dim i As Integer = oSrcBatchField.Fields(EBatchFieldFields.BatchField_fld_Sequence)
If oBkpTempRec.Fields(i) oSrcTempRec.Fields(i) Then
oBkpTempRec.Fields(i) = oSrcTempRec.Fields(i)
End If
Next
End If
oBkpTempRecords.Save()
Next

oBkpBatch.Save()

oBkpTempRecords = Nothing

oSrcBatch.CloseDown()
FinalReleaseComObject(oSrcBatch)

oBkpBatch.CloseDown()
FinalReleaseComObject(oBkpBatch)
End Sub

Specifically referring to the RE API however, I think that VB does have an easier time. RE was written in a different era. There was no such thing as .NET when probably 95% of the API was written and as such they could not have foreseen where the technology would take the industry. COM technology was the big thing of the time and as such as long as the API worked with a COM language that was fine.

Given that, even though VB.NET was rewritten, much of the syntax remains, it is obvious that VB.NET is going to be better suited to what was primarily intended to be used with VB6. The optional parameters is a good example.

The example of collections is an interesting case. You are right this is nothing like the .NET syntax but then why should it be. This was not written for .NET. It is closer to the VB6 Collections class but even then it is more “advanced”.