CUB Constituent lookup not loading extension data

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>

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.