nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CUB Constituent lookup not loading extension data

Willem Vandenberg

Hi all,

I made several extensions for CUB – Multiple Ethnicities, Religion Code, and a DNE Reason Code for the Email Addresses collection. The add, edit, and commit functionality works fine for all of them.

However, when I create a new batch with these extensions and search/select a Constituent in a row, all the fields in that row will pre-load with the appropriate data, except the extension fields.

Is this by design, or am I missing something?

Does the Constituent lookup and preload not include extensions?

Cheers!

-Willem

Find more posts tagged with

Comments

Nick McGinnis

I think the solution would be to add an EditRow to the CommitRow section below the add row. With an Upsert batch like the CUB when you enter a constituent it actually switches to another form. This can be seen if you go to the CUB batch type page and look at the XML. The CUB will pass a PRIMARYRECORDID guid to the load/save implementations that you can use to load the existing extended data. This section of the documentation shows some more detail on batches like the CUB with some of the properties that make it different than a normal batch. Hope this helps!

Willem Vandenberg

All of the batch pieces are in place and functioning.

This is not related to the commit, though.

When a new batch is created, the UI opens the batch for row addition.

The moment you click on a row to add data, that row is created but not present in the batch table yet. When you search/select a Constituent, the row is populated with data for that constituent (just not the extension fields).

This all happens long before the commit state.

The edit function of the commit section handles rows from the batch for which the constituent already exists in the database – hence the database record is updated instead of having a new constituent inserted.

All the code for the batch extension I made can be found here, in an answer to a question about how to add a Do Not Email Reason Code to CUB:

But I will look into the possible solution you propose anyway. You never know.

Cheers!

-Willem

PS; This is the EditRow section with its LoadImplementation. So it is in place, but no data is loaded on a constituent lookup.

<EditRow EditLoadField="PRIMARYRECORDID" DataFormInstanceID="480f8309-de26-46c9-96c2-e2c46270a0c6" DataFormTemplateID="717934c2-d509-4668-a98f-ddfa5159e8a1">
<LoadImplementation SPName="USP_SMU_DATAFORMTEMPLATE_COMMITEDITLOAD_CUBEXTENSION">
<c:CreateProcedureSQL>
<![CDATA[
create procedure dbo.USP_SMU_DATAFORMTEMPLATE_COMMITEDITLOAD_CUBEXTENSION(
@ID uniqueidentifier, -- ConstituentID = PRIMARYRECORDID
@TSLONG bigint = 0 output,
@DATALOADED bit = 0 output,
@USR_ETHNICITIES xml = null output,
@USR_EMAILADDRESSES xml = null output,
@USR_RELIGIONCODEID uniqueidentifier = null output
)
as
begin

set nocount on;

set @DATALOADED = 0;
set @TSLONG = 0;

-- populate the output parameters, which correspond to fields on the form. Note that
-- we set @DATALOADED = 1 to indicate that the load was successful. Otherwise, the system
-- will display a "no data loaded" message. Also note that we fetch the TSLONG so that concurrency
-- can be considered.
select
@DATALOADED = 1,
@USR_ETHNICITIES = dbo.UFN_SMU_CONSTITUENTUPDATEBATCH_GETETHNICITIES_TOITEMLISTXML(@ID),
@USR_EMAILADDRESSES = dbo.UFN_SMU_CONSTITUENTUPDATEBATCH_GETEMAILADDRESSES_TOITEMLISTXML(@ID);

select
@USR_RELIGIONCODEID = RELIGIONCODEID
from dbo.USR_SMU_BATCHCONSTITUENTUPDATERELIGION
where ID = @ID;

return 0;

end
]]>
</c:CreateProcedureSQL>
</LoadImplementation>

Willem Vandenberg

Ha! I did notice, as I pasted the code, that I am trying to pull from the batch table, instead of pulling from the database record… If the constituent lookup indeed switches to the edit load from the commit section, that may indeed solve the issue. I'll get back to this.

Thanks.

-Willem

Willem Vandenberg

Yeah, that's a no-go.

Also, the Upsert docs make it clear that the PRIMARYRECORDID is used to load the data that is applied to updating an existing record. Comparing new data with existing data is actually done in the save implementation of the EditRow. So it does need to pull from the staging table.