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.

Good to hear you're going

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

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.

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.

This is the only code I have which could be causing the issue I assume:

Private Sub NameLocaBO1_Navigated(ByVal e As MicroFour.StrataFrame.Business.NavigatedEventArgs) Handles NameLocaBO1.Navigated
 If NameLocaBO1.Count > 0 Then
    Me.AddrHistBO1.FillByParent()
    Me.ugAddressHistory.Refresh()
 End If
End Sub

So  If I do FillByParentPrimaryKey how do I do it with a relationship that is multi-component?

NameLoca
     PersBuss (1st component of primary key)
     NameNo (2nd component of primary key)

AddrHist
     PersBuss (1st component of primary key)
     NameNo (2nd component of primary key)
     HistDT (3rd component of primary key)

AddrHist.PersBuss = NameLoca.PersBuss
AddrHist.NameNo = NameLoca.NameNo

Ben

Do you have code to load up the child records automatically (i.e. Navigated event, BusinessLayerLinkManager, etc.)?  In other words when you click the OK button?  If so, this is the problem because the 4096 parameter limit is being hit.  THere is nothing we can do about this....it is just how SQL Server is.

You will have to reduce your recordset size.

The problem you are running into isn't the 10000 return results, if you look at the second SELECT statement, there is a query with more than 4096 parameters....this is a limitation of SQL Server.  This table is selecting from AddrHist, I am not sure where this query is being generated, but it is definitely going to produce an SqlException because you have too many parameters being passed.

Well, I am confident that it is not within the framework but more than likely the stop-gap between the data access layer and the ADO.NET data table.  Deductive reasoning on this one will point to a size or memory issue.  If you debug the 1000 statment and the 10000 statement, you will see one character different (a zero).  We are just filling a data table with an adapter....and over time, when we have stopped and debugged this type of error thinking it may be something in the framework, we have found...everytime thus far....it is a memory issue because too much data is coming back.

Hope this helps.

Take a close look at the debug log.  It is the child table that is causing the problem!

NameLoca --->  AddrHist

Shouldn't it just be selecting the child records for the "current" NameLoca record and not ALL based on the filtered return from the BrowseDialog form???

Ben