This is your problem....and there is no way around it due to the SQL Server limitations.  The FillByParent is going to create a lot of parameters due to the nature of the relationship.  In this example, FillByparentPrimaryKey is going to retrieve the exact same record set but will only have 1 parameter which will be much faster anyway since there is not nearly as much TDS (SQL Server Tabular Data Stream) data that will go over the network.  Whether you are using SF or anything else, this is still not a good idea and you are going to have the same problems.

However, at least using SF you can call the FillByParentPrimarykey and your current problem should go away.

After looking at your previous post again, the relationship may not support the FillByParentPrimary key, but in any case, you are going to have to reduce the record size of the parent table....otherwise you are going to continue to have this problem....and there isn;t anything we can do about it....it isn't our limitation, it is SQL Servers....which honestly makes sense.  The record set is too large.

Forget it.  I think I found my answer in one of the overloaded methods of FillByParentKey!

On the addresshistory business object the ParentRelationship is:

NameLocaBO, (PersBuss,NameNo) <--> (PersBuss,NameNo)

If I change my method call to:

Me.AddrHistBO1.FillByParentPrimaryKey(NameLocaBO1.PersBuss, NameLocaBO1.NameNo)

All is well!  Thank you for such stellar support!

Ben

Good to hear you're going

Wen you mentioned "multi-key" I presume you were referring to Compound Primary Keys....in this case, SF auto-detects and has full support for compound primary keys, which you discovered.