Ok, I've been reading about CMR stuff, and just given posts in the last month I realize that there's probably no clean answer to my question. So let me restate the issue:

We resolved a CMR bug together back in April or May that came up in the context of a CMR relationships with compound primary keys. It appears to be back. I've got a sample of the default.log from a database that has this application running:

INSERT INTO ADDRESSEJB VALUES(6,'123 Anwhere Street','','Somewhere','OR','39483',NULL,NULL)
INSERT INTO ADDRESSEJB VALUES(7,'123 Anwhere Street','','Somewhere','OR','39483',NULL,NULL)
INSERT INTO ACCOUNTHOLDEREJB VALUES(2,1028156955243,'Sam','Spade','email@address.com','sspade','123',6)
INSERT INTO ACCOUNTHOLDEREJB VALUES(1,1028156954947,'Jim','Dandy','email@address.com','jdandy','123',7)
INSERT INTO ACCOUNTEJB VALUES(3,1028156955384,3000.5,'Primary Checking',NULL,NULL)
INSERT INTO ACCOUNTEJB VALUES(4,1028156955665,500.0,'Primary Savings',NULL,NULL)
INSERT INTO ACCOUNTEJB VALUES(5,1028156955806,3000.5,'Primary Savings',NULL,NULL)

Note all the NULL entries, those should point back to the first two columns in ACCOUNTHOLDEREJB. So, it appears that the issue that was once resolved is not back, although I'm not sure the reason. I haven't modified my sample application since the Beta2 release, and it was working at Beta2.

Do you know if there are changes that would cause this problem to arise now, or is this an open issue that I should be investigating further?

Thanks for your help,

Mac