Hi. I'm a noob. I did search for "CExport" and came up zippo, so apologies if this topic has already been posted.

I am developing in the RE API (Enterprise 7.9x).

I have a big export that writes to CSV and takes about one hour to run through RE/Export.

Running the same export through the RE API (in a Windows Form application built for release with all debugging off), the export takes about three times as long:

Through RE/Export: 300kb output written per minute.
Through API (Windows Forms) app: 110kb written per minute.

Does anyone know of a way to tweak the row-fetch characteristics of the CExport object or its callback (BBInterfaces.IBBSessionContext) to improve performance?

Here is some code, in case anyone might find it helpful:


'' This is a VB.NET wrapper that implements IBBProcessCallback (because it is a virtual class that does not have support for instantiation at compile time). The wrapper is called by another method that initializes the CExport object (below).
Public Class REExportWrapper

Implements BBInterfaces.IBBProcessCallback

Private iExportCount As Integer


Public Sub ItemProcessed(ByVal lItemNumber As Integer, ByRef bCancel As Boolean, Optional ByRef vData As Object = Nothing) Implements BBInterfaces.IBBProcessCallback.ItemProcessed
iExportCount += 1
End Sub

Public Function RunExport(ByVal export As REExportData7.CExport) As Integer
' The export object will be initialized and closed by whatever calls this.
' The sole purpose of this function is to facilitate weak binding of the callback through the Implements keyword.

iExportCount = 0
export.ExportData(Me)

Return iExportCount

End Function

End Class



// This is the method that launches the export by creating a CExport object and feeding
// it into the wrapper (above).
public static int gppConstituencyExport(BBInterfaces.IBBSessionContext sc, BBREAPI7.REAPI reapi)
{

int iRecs = 0;
string cExportFile = null; // as declared in the export record
string cOutFile = null; // the name as actually saved (could be different than cExportFile)

CExport x = new CExport();
x.Init((BBInterfaces.IBBSessionContext)sc);
x.LoadByField(xExportUniqueFields.uf_EXPORT_NAME, "My Ridiculously Long Export");
x.ReadOnlyMode = false;
cExportFile = x.get_Fields(EEXPORTFields.EXPORT_fld_FILNAME).ToString().Trim();

// The next line calls a cool method that uses System.IO to create a unique export file name, so that old output is overwritten and we can keep an archive.
cOutFile = getUniqueFileName(cExportFile, "reConstExport_", true);
if (cOutFile != cExportFile)
{
// We are dynamically changing the name of the output! Save the change in RE, so that
// RE's internal users will be able to see what happened.
// (This is why readOnly has been set to false.)
x.set_Fields(EEXPORTFields.EXPORT_fld_FILNAME, cOutFile);
x.Save();
}

// Here goes!!! Call the VB.NET wrapper (code shown above).
REExportWrapper rxw = new REExportWrapper();
iRecs = rxw.RunExport(x);
// Now close the CExport object.
try
{
x.Closedown();
x = null;
}
catch
{
;
}



return (iRecs>0?iRecs: -1);
}

Me again. Sorry the forum collapsed all my whitespace. (Would have previwed if there had been a preview button.) This is a test, for the future, to see if the "code" tag will perserve it:

<code>
spaces in front of this?

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;How about this???
</code>

I've noticed much lower performance when doing some things through the API compared to in the BB RE GUI. I've come to assume that BB have coded it a certain way that leads to this (possibly even using functionality unavailable to API users).

I would say that you are probably better off using a combination of VB and SQL. You use sql to retrieve the data you want and then use VB to output it into a CSV format. That would be much quicker than using the CExport object.

David

Kraeg wrote:


That is my suspicion, too. Most of the so-called "API" appears to have been auto-generated. It contains incredible gaps, and now I am beginning to suspect that the performance deficits could be as bad as the feature deficits.

I have submitted questions to Blackbaud along these lines. Still awaiting answers.

DavidZ wrote:


Yes, I could do it that way (substituting C# for VB in my case) and have tinkered along those lines...

But the thing is, my question falls into a project of much larger scope. We are building a scheduling system that runs RE Queries, Exports, Custom Reports, and Imports sequentially, using scripts and objects that users can declare from within Raisers Edge. For instance, they can design a query and export, feed it into a custom (Crystal) report, and then declare them to the scheduler. (Screen shots attached, in case anyone is interested).

If my export becomes a "custom job," it defeats the original purpose of empowering the users by letting them shift repetitive work to unattended tasks run by services.

The deeper point, and the point that troubles me, is that if my team has to use C#, .NET, and SQL to do one-offs, we don't need the RE API or VBA modules at all. And if someone had told us, either during courtship or during RE-API training, that the libraries run at 30% of standard speed, we would not have spent $30,000 for them. Pardon the rant. I will post a follow-up on this thread, when I learn something definitive from Blackbaud.